Case study: “Imminent RATs” (II)

Analysis (follow-up)

In the previous article, we had determined there was “something weird” in the computer, and we had downloaded both, a possibly malicious .doc and a user executable and mailbox. It’s time to get down to work to see what they may contain…

[Note: As a good security practice, malicious files should NEVER be shared without minimal protection. Therefore, you can download both files from here, but they are zipped with the password “infected”. Please, handle them with extreme care, you’ve been warned.]

To start with, we can open the user’s .pst to verify that the infection path is correct, something we can easily do from Windows with the Kernel Outlook PST Viewer:

We have already confirmed the entry path (and let’s not forget to write down the metadata of the email, which will be very useful in the contention phase), so we can focus on the two malicious files. The first thing we do is calculate the hashes (usually, it is advisable to calculate both MD5 and SHA256, the first one because it is still widely used and the second one to avoid collisions):

# md5sum vfggggg.exe Purchase\ Order\ 03EDG.doc 
b4f28747a0a9317123f0ef109c580844  vfggggg.exe
f48ca1a55120e5a5ff43962ccc8db1a2  Purchase Order 03EDG.doc

# sha256sum vfggggg.exe Purchase\ Order\ 03EDG.doc 
1dd788c038b4d8d2d3302d7a33162322d0896c7d17888e2fa34204b66c9aee50  vfggggg.exe
18ac90e921eac40200ec2b4508d3760149d4c9e931c96b5447a711ddf7d1b3e7 Purchase Order 03EDG.doc


And by the way, we get some additional information with file and exiftool:

#file Purchase\ Order\ 03EDG.doc vfggggg.exe 

Purchase Order 03EDG.doc: Rich Text Format data, unknown version
vfggggg.exe:              PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

exiftool Purchase\ Order\ 03EDG.doc vfggggg.exe 
======== Purchase Order 03EDG.doc
ExifTool Version Number         : 9.46
File Name                       : Purchase Order 03EDG.doc
Directory                       : .
File Size                       : 221 kB
File Modification Date/Time     : 2018:04:03 09:52:46-04:00
File Access Date/Time           : 2018:04:08 04:06:49-04:00
File Inode Change Date/Time     : 2018:04:08 04:05:26-04:00
File Permissions                : rw-r--r--
Error                           : File format error

======== vfggggg.exe
ExifTool Version Number         : 9.46
File Name                       : vfggggg.exe
Directory                       : .
File Size                       : 930 kB
File Modification Date/Time     : 2018:04:03 07:39:44-04:00
File Access Date/Time           : 2018:04:08 04:13:43-04:00
File Inode Change Date/Time     : 2018:04:08 04:05:26-04:00
File Permissions                : rw-r--r--
File Type                       : Win32 EXE
MIME Type                       : application/octet-stream
Machine Type                    : Intel 386 or later, and compatibles
Time Stamp                      : 2017:06:24 06:53:40-04:00
PE Type                         : PE32
Linker Version                  : 8.0
Code Size                       : 371712
Initialized Data Size           : 580096
Uninitialized Data Size         : 0
Entry Point                     : 0xf000a
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
Subsystem                       : Windows GUI
File Version Number             :
Product Version Number          :
File Flags Mask                 : 0x003f
File Flags                      : (none)
File OS                         : Win32
Object File Type                : Executable application
File Subtype                    : 0
Language Code                   : Neutral
Character Set                   : Unicode
Comments                        : 
Company Name                    : 
File Description                : 
File Version                    :
Internal Name                   : mndgrhsz.exe
Legal Copyright                 : Copyright ©  2018
Legal Trademarks                : 
Original Filename               : mndgrhsz.exe
Product Name                    : 
Product Version                 :
Assembly Version                :


Clearly, the second file is an exec file. However, the first file seems to be a .doc but it turns out to be an .rtf (common vector for several old and new exploits).

We look for hashes in VirusTotal to check whether the malware is public or not:

  • Purchase Order 03EDG.doc (9/57 on VT), looks like a malicious document that exploits CVE-2017-0199, a Word vulnerability.
  • VirusTotal Link

  •  vfggggg.exe (10/66 on VT), an unidentified malware a priori.
  • VirusTotal Link

Since both files are public, now we are free to execute them in a sandbox like Hybrid-Analysis:

If we look at the comments of VirusTotal, we have an additional analysis of VMRay, which also provides additional information:

From the information of all the previous sources we draw the following conclusions:

  1. The exploit used appears to be CVE-2017-0199.
  2. The document makes a TLS connection against the domain a.doko[.]moe (IP
  3. The malware is packaged with the Morphine v1.2 packer.
  4. The malware does not make any connection with the outside world.
  5. The malware apparently has keylogger functions.
  6. The malware makes a TLS connection against the domain dankleo01.chickenkiller[.]com (IP
  7. The malware makes a connection against the domain
  8. Before the vfggggg.exe file appears, another exec file appears: gabkrj.jpg.exe, which launches the explorer.exe and creates it.
  9. The directory c:\users\USER\appdata\roaming\imminent is created, with several files of interest.

We do not have the whole picture, but we have already obtained two contact domains of interest: a.doko[.]moe and dankleo01.chickenkiller[.]com (we discard because it is probably a malware connection test to verify the Internet connectivity, not being malicious in itself).

The fact that point 4 contrasts with points 6 and 7 is because the information comes from different sources (and possibly, in point 4 the malware recognized the sandbox and did not run correctly).

Containment, eradication and recovery

At this moment, the basic analysis is done, so we can move on to the phase of containment and eradication of the incident. From the detection and analysis phase we have the following IOCs of interest:

  • Email with subject: “Urgent invoice for kitchen material”.
  • Email with sender:
  • Email with the attachment: “Purchase Order 03EDG.doc”.
  • Contact with the domain: a.doko [.]moe.
  • Contact with the domain: dankleo01.chickenkiller [.]com.

Mail-related IOCs can be cross-referenced with mail gateway logs, and they indicate that 124 users of the Organization received the malicious mail. The IOCs related to the domains can be searched in the navigation proxy logs, revealing that 6 users opened the document. The security awareness of users has improved significantly (only 5% fell for it, a reasonable amount), but it still seems necessary to strengthen the basic knowledge of some of them, inviting them to another cybersecurity awareness training.

The containment measures to be implemented are simple:

  1. 1. Block domains in the proxy or firewall to prevent any malware progression.
  2. 2. Warn users not to open the malicious email and delete it from their mailboxes (in some cases the system administrators may even delete them from the mailboxes from the mail server itself).

If we carry out an analysis of the .moe TLD we find out with amazement that it is not a reference to the Simpsons but a Japanese jargon term related to anime and manga. And to make matters worse, the domain is a free Hawaiian file storage service, perfect for an attacker to leave their malicious payloads.

Since it seems unlikely that .moe domains are critical to the functioning of the Organization, we propose their complete blockage. Additionally, we can draw up some basic Snort / Suricata rules for their detection:

alert tcp any any -> any 80,443 (msg:"Malware Cryptostealer HTTP/HTTPS";classtype:trojan-activity; content:""; sid:666666667; rev:1; )
alert udp any any -> any 53 (msg:"Malware Cryptostealer DNS"; flow:to_server; content:"|04|doko|03|moe"; classtype:trojan-activity; sid:666666668; rev:1; )

We copy these rules in the file /etc/Snort/rules/rules/local.rules, and check for syntax errors by verifying the configuration with:

# snort -T -i eth0 -c /etc/snort/snort.conf

If there are no errors, we restart Snort to reapply the settings:

# service snort restart

And we pass on to Snort the .pcap we previously captured here:

# snort -i eth0 -c /etc/snort/snort.conf -r /home/remnux/sandbox/labo_dfir.pcapng -l /tmp -A fast

If everything went well, we would have to have these results in the file /tmp/alert :

04/07-04:43:45.764408  [**] [1:666666668:1] Malware Cryptostealer DNS [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} ->
04/07-04:43:45.886443  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} ->
04/07-04:43:47.738537  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} ->
04/07-04:43:53.321598  [**] [1:666666668:1] Malware Cryptostealer DNS [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} ->
04/07-04:43:53.411079  [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} ->

Aditionally, we can generate a YARA rule to detect new malicious attachments. If we edit the RTF, we can verify it has a fairly characteristic string (the one that identifies the malicious OLE object that the exploit usually has):

A very simple rule (which should be evaluated when it comes to false positives it might generate) could be this:

rule rtf_objdata_cve_2017_0199 {
 $header = "{\\rtff"
 $objdata = "\\object\\objautlink\\objupdate\\objw5816\\objh6097{\\*\\objdata" nocase
 $header at 0 and $objdata  

We save this file with the name “cve-2017-0199.yar” and we can check if we correctly detect the malware with our rule with the command:

# yara -smg cve-2017-0199.yar /home/remnux/malware/Purchase\ Order\ 03EDG.doc

Good practices regarding eradication in an incident are usually very simple: “Nuke it from orbit” (Lieutenant Ripley is ALWAYS right). Unless it is completely clear what type of malware is affecting the computers (and thus perform a surgical removal), the safest option is to format the computers and reinstall them.

In this case, recovery would be simple: reinstalling the computer + restoring the relevant backup copies.

However, we still have a few questions left to answer … which we will address in the next and final article.

See also in: