#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.
4/ On ThreatFox by @abuse_ch, we see that a quarter of the samples kept this default port. [3]
The other samples use a different high port.
5/ We can create a "random" Mutex per client build, though random is not quite right. 🤔
6/ With a regex, we can find these random mutexes and thus efficiently find infected clients on the network:
9/ In networks were TLS is broken up on the proxy, the hard-coded user agent string could be used for hunting or setting up monitoring for this value. [6]
10/ Quasar uses the same persistence mechanisms as AsyncRAT, which we analyzed in a previous tweet [9].
A run-key entry is created when ran with an unprivileged user, or a new scheduled task is created when ran with administrative credentials.
11/ And although @pmelson pointed out in March of this year that the source code for Quasar is still available online on Github, nothing has not changed 🤷♂️. [7], [8]
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]
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).