2/ Hunting for credentials in the PowerShell history is quickly done with @Velocidex Velociraptor.
We can get the file's entire content from the hosts or search specifically for keywords within the file.
3/ The content of this file (the PowerShell history), is not only interesting for searching stored credentials in it but also an excellent forensic artifact.
In the case of a CA, we can specifically search for (older) traces of TAs (Invoke-commands, downloading of tools/code..)
4/ In the case of an IR, we may find current traces of the attacker within the PowerShell history.
5/ If the command line of the hosts is recorded (with Sysmon or an EDR), one could possibly monitor for disabling of the PowerShell history, as @DissectMalware mentioned in a tweet:
If the Windows App sideloading feature is enabled, users can also install APPX packages not originating not from the Microsoft Store, ideal for distributing malware with these packages 🤯[1],[2]
#QuasarRAT is another RAT we see from time to time in our IR cases and was also used against NATO facilities in March. [1]
We can hunt for
1⃣ The default port within the FW logs
2⃣Mutexes
3⃣User-Agent
4⃣Persistence mechanisms
🧵
2/ @qualys has published an excellent paper ("Stealthy Quasar Evolving to Lead the RAT Race") about Quasar, where the whole builder and much more are described in detail. [2]
3/ In the client builder (which creates an executable which is used for the infection), the default port is pre-configured to 4782.
2/ For our tests, we use the hosted instance of MeshCentral.com, but the management software can also be run on a separate server, controlled by the TA.
After logging into the panel, we can download an agent for different operating systems (Windows, Mac, Linux).
3/ Before the installation or execution of the agent, the server URL is displayed under "Connection Details".
In our example, the agent connects to meshcentral.com, but another domain can be configured when the management server is self-hosted.
2/ After starting the ELF binary (a reduced version is publicly available on GitHub [2]), the login credentials are printed out (username: manjusaka, PW: b3e..), and the port (3200) on which the panel is accessible.
3/ The password is different for each instance of manjusaka.
This mechanism prevents the use of default passwords in case scanners would find the login panel.
A few thoughts on the topics mentioned in the talk 🧵:
1⃣MFA, Password Spraying, Common Passwords
2⃣RDP Shadowing
3⃣MFA spamming
4⃣Password in Shares
5⃣GPP
6⃣Sam the admin
2/ 1⃣ A popular initial vector they often use is Citrix without MFA.
This is also a classic from our IR cases, where either the password was found out with password spraying (the user used a weak password), or the user was phished beforehand.
3/ MFA is a MUST for any remote access.
If Azure AD is used, Azure Active Directory Password Protection could be used, which checks the password from the user against a global blocklist or a configurable blocklist [2] (this is done when the user changes the password).