For the past few weeks a new malspam campaign has been observed delivering different kinds of malware via email messages. The malspam uses PDF attachments with embedded Word documents [1]. The Word documents themselves include malicious macros. Adobe Reader and Microsoft Word have built-in mechanisms to automatically prevent the attachments from dropping their payload. However, an attacker can easily lure a victim into bypassing those mechanisms. Once the malicious macro runs, it connects to a delivery domain in order to download the final payload. Examples of delivered malware include Locky ransomware [2], Jaff ransomware [3] and Dridex banking Trojan [4][5].
This threat advisory sheds some light on the delivery documents. It also discusses how to leverage the Hunting pack to detect their network behavior using NetWitness Logs and Packets.
Let’s take this delivery document as an example [6]. The usage of embedded Word documents in PDF attachments requires more user interaction providing the attacker an extra layer of sandbox evasion.
Upon opening the PDF attachment, Adobe Reader alerts the user that it may have content that can harm her computer:
If the user chooses to open the PDF attachment, a document will be extracted and launched in Microsoft Word if it is installed on the computer. Microsoft Word displays a warning that the document is opened in protected view:
If the user follows the instructions to enable content for this document, the embedded malicious code will execute and tries to connect to a delivery domain:
The infected machine receives an obfuscated payload in response:
The final step is to de-obfuscate the payload and to start the malware in a new process, in this case a Jaff ransomware variant [7]. This is the process tree from hybrid-analysis.com:
The Hunting pack is designed to allow you to quickly hunt for indicators of compromise or anomalous network activity by dissecting packet traffic within the NetWitness Suite and populating specific meta keys with natural language values for investigation. For more information on the hunting pack including how to deploy it in your environment, please refer to RSA documentation [8].
The screenshot below shows that the network behavior is shared among multiple delivery documents:
Below are some of the meta values registered by the Hunting pack for those sessions:
Here is a description of some of those meta values:
Meta Value | Description |
---|---|
http not good mozilla | A User-Agent without the Mozilla identifier |
http no referer | HTTP sessions with no referrer |
http mid length user-agent | User-agent header length between 56 and 74 characters |
http get no post | Sessions with only HTTP GET Methods |
http six or less headers | Six or less HTTP headers in a session |
tld not net com org | Less Common Top Level Domains |
not top 20 dst | org.dst is not one of the most common 20 destinations |
Let’s compare the network behavior we have seen so far to a normal browsing activity to try to understand why the Hunting pack is tagging those sessions with the meta values described above. The screenshot below shows an HTTP GET request to CNN website using a Mozilla Firefox browser on an Ubuntu machine:
Some differences to note here are:
All the IOC from those HTTP sessions were added to RSA FirstWatch Command and Control Domains feed on Live with the following meta values:
If you are interested in another Hunting pack use case, check this community post on RedLeaves malware.
References:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.