Ahmed Sonbol

Hunting pack use case: Delivery documents

Blog Post created by Ahmed Sonbol Employee on May 17, 2017

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:

 

 

Detection using Hunting pack

 

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 ValueDescription
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 dstorg.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:

  • Unlike the fake user-agent string used by the malicious macro, the one above is typical of human-operated web browsers [9]. Malware authors can simply forge this field but anomalies can be easily spotted and might indicate malicious behavior.
  • The existence of more HTTP headers in this request, malware authors usually tend to ignore those headers in their code when they call the functions to connect to their delivery or C2 domains.
  • A referrer field that indicate the origin of the request. Although not present in every HTTP request but anomalies especially in a large number of sessions might indicate a mechanical behavior.
  • The Top-level domain is one of .com, .net or .org. Of course that doesn’t guarantee that the domain is a legitimate one but attackers tend to use other TLD in their operations and in particular the generic top-level domain [10]. It is important to understand what are the normal and most frequently visited TLD based on your environment, your business and geographic location.

All the IOC from those HTTP sessions were added to RSA FirstWatch Command and Control Domains feed on Live with the following meta values:

  • threat.source = 'rsa-firstwatch'
  • threat.category = 'malspam'
  • threat.description = 'delivery-domain'

 

If you are interested in another Hunting pack use case, check this community post on RedLeaves malware.

 

References:

  1. Malicious Documents: The Matryoshka Edition | Didier Stevens 
  2. Malware-Traffic-Analysis.net - 2017-04-21 - Dridex-style malspam pushes Locky ransomware instead 
  3. Malware-Traffic-Analysis.net - 2017-05-11 - Jumping on the Jaff ransomware bandwagon 
  4. Malware-Traffic-Analysis.net - 2017-04-19 - Dridex malspam with PDF attachments containing embedded Word docs 
  5. Bank on it with the Dridex Trojan 
  6. Antivirus scan for ff66670b0ab937f33842c0977c2396d25933a8da7e4fa1931e0a9055dfeac9e5 at2017-05-16 03:08:01 UTC - VirusTot… 
  7. Antivirus scan for 03363f9f6938f430a58f3f417829aa3e98875703eb4c2ae12feccc07fff6ba47 at2017-05-17 16:27:35 UTC - VirusTot… 
  8. RSA NetWitness Hunting Guide 
  9. User agent - Wikipedia 
  10. List of Internet top-level domains - Wikipedia 

Outcomes