What are LOLBAS tactics?
As I wrote on this previous article about mshta.exe, LOLBAS (Living Off The Land Binaries and Scripts) tactics are those that involve the use of legitimate Windows tools for malicious purposes. This is an old concept but a recent growing trend among threat actors because these types of techniques are very difficult to detect considering that the tools used are whitelisted most of the time. A good list of applications that can be used for these type of tactics can be found at LOLBAS (Windows) and GTFOBins (UNIX).
Intro
Although both Regasm and Regsvcs are versy similar and can both be leveraged for the same purpose, Regasm.exe (https://lolbas-project.github.io/lolbas/Binaries/Regasm/) will be studied on this demo. As we will see, adversaries can proxy execution of code through this trusted Windows utilities to perform malicious activities. Regsvcs and Regasm are Windows command-line utilities that are used to register .NET Component Object Model (COM) assemblies. Both are digitally signed by Microsoft (https://attack.mitre.org/techniques/T1218/009/) .
Scenario
The attackers build a phishing campaign where they mass-distribute emails with a MS Word attachment containing macro code which calls a remote malicious payload.
The document is disguised as an invoice:
the victim, curious about the invoice, opens the attachment:
the victim does not see any content therefore decides to click on "Enable Content" which will eventually trigger the payload.
The payload is a meterpreter DLL which resides on a remore HTTP/WebDav server and it is executed through Regasm.exe. Once it is executed the attackers receive a reverse meterpreter https session on the victim machine which becomes part of the attackers' C2:
As shown above, some meterpreter enumeration commands are launched: sysinfo, ipconfig, getuid, ps
Detection with Netwitness
The traditional approach has been for companies to focus mainly on preventive controls such as firewalls, IPSs, anti-virus, and the like. Malware is constantly evolving and is already able to get around these type of measures. This is why today is vital to adopt an Assume-Breach approach where you accept and plan for WHEN, not IF, an attack will happen on your environment.
Following this concept, the analyst starts his hunting session assuming the environment has been compromised. Specifically the analyst assumes the traffic generated by the attack in question is blending in with the HTTPS protocol.
Using Netwitness Network the analyst places the filter "service=443" and performs an investigation:
Since the payload is nearly all cipher text, the SSL CA and SSL Subject are the only places to go digging into SSL/TLS. Interesting metadata is observed within the Service Analysis and the Session Analysis meta keys, which could be sign of something fishy going on.
Details on these meta keys can be found on our hunting guide here: https://community.rsa.com/t5/rsa-netwitness-platform-threat/rsa-netwitness-hunting-guide/ta-p/564743.
Let's quickly review some of them:
- hostname consecutive consonants: A regex looking for five or more consecutive consonants or numerals, or two groups of four consecutive consonants or numerals, useful for discovering a DGA (domain generation algorithm).
- ssl certificate missing subject organizational name: Subject section of a certificate does not have an ON attribute. Could indicate presence of certificates programmatically generated by malware.
- tunnel service: may indicate tunnel services are being used.
- first carve not dns: indicates non-DNS sessions that had a payload, originated from within the organization, and whose destination was the internet.
Filtering on the above metadata the analyst reduces the traffic quite significantly:
the sessions obtained all look very similar, in that they have same source IP/hostname (192.168.16.179/WinEP1), same destination hostname (3fa2825bf3f0.ngrok.io), although the destination IP varies. Each session contains a big amount of Request/Response pairs indicating potential C2 communication. This is also backed by the fact that ngrok.io is a popular tunneling service often (ab)used within the hacking community.
Additionally, because the Netwitness endpoint agent is installed in the host that has initiated the communication (WinEP1), the analyst gets information about a process (RegAsm.exe) and a user name (user) being used within the same session.
Moving to the "Host" tab the analyst is able to get more information related to the endpoint:
and by clicking on the graph symbol next to the process the whole processes chain is shown:
It is clear from the above picture that winword.exe (MS word) was opened from outlook.exe (MS Outlook ) which triggered RegAsm.exe which in turn executed a DLL (regsvcs.dll) located remotely at simulation.pagekite.me
From the same page the event view section shows more details. The MS word document that triggered the DLL via RegAsm.exe is invoice-27899.doc:
Further investigating with Netwitness Endpoint on the same time frame the analyst notices the run rundll32 with http argument metadata is populated under the Behavior of Compromise meta key:
This explains that, when RegAsm.exe invoked regsvcs.dll, under the hood the WebClient service (svchost.exe -k LocalService -p -s WebClient) has created the davclnt.dll process which then executed the remote DLL.
The WebClient service is responsible for the communication with the remote location, that is a HTTP/WebDav server:
Digging into other Endpoint sessions the analyst confirms:
- svchost.exe making a connection to the site where the DLL resides from WinEP1
- RegAsm.exe making a connection to the ngrok site:
- svchost.exe writing the DLL on disk on a temp directory:
Although the analyst could not see the content of the communication, being encrypted, it is pretty clear that this is something out of place and the behavior looks similar to other C2 infections. The analyst then decides to isolate the affected host from the network:
Despite the fact that the run rundll32 with http argument metadata was populated under the Behavior of Compromise meta key and eventually pointed the analyst to right direction, the following App Rule would help detecting execution of remote DLLs via RegAsm faster:
This would be the result:
Post Detection Activities
The attachment file can be requested by the analyst for further investigation. Tools such as ViperMonkey can be used to extract and de-obfuscate macros from the word document:
The above picture shows an obfuscated macro which does not make lot of sense. However, below we see the final result with the de-obfuscated content:
Similarly the analyst can request the DLL and perform additional malware analysis where required:
Conclusion
To be able to identify anomalies, analysts must learn what regular traffic looks like within their environments. It is also imperative to properly understand how major protocols such as HTTP, SSL/TLS work in order to be able to establish the presence of programmatic and structured behavior typical of malware. The Netwitness Hunting Guide is a great starting point.
It is important to note the synergy of Netwitness Network & Endpoint when used together and the advantages they provide. Netwitness Network helped identifying the potential C2 communication but the integration with Endpoint allowed the analyst to instantly detect the LOLBAS tactic, drastically reducing the response time.
