These articles are part of a basic incident response workshop. Therefore, there are things that could be done more efficiently and elegantly… but the idea was to do them in a simple way so that they were easy to understand. And like any good practical workshop, you can follow it step by step: you can download a Remnux virtual machine with everything you need for the workshop here (for VMWare) or here (.ova format)]
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 : 1.0.0.0 Product Version Number : 1.0.0.0 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 : 1.0.0.0 Internal Name : mndgrhsz.exe Legal Copyright : Copyright © 2018 Legal Trademarks : Original Filename : mndgrhsz.exe Product Name : Product Version : 1.0.0.0 Assembly Version : 1.0.0.0
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.
- vfggggg.exe (10/66 on VT), an unidentified malware a priori.
Since both files are public, now we are free to execute them in a sandbox like Hybrid-Analysis:
- Purchase Order 03EDG.doc.
- vfggggg.exe
If we look at the comments of VirusTotal, we have an additional analysis of VMRay, which also provides additional information:
https://www.vmray.com/analyses/1dd788c038b4/report/overview.html
From the information of all the previous sources we draw the following conclusions:
- The exploit used appears to be CVE-2017-0199.
- The document makes a TLS connection against the domain a.doko[.]moe (IP 185.83.215.16).
- The malware is packaged with the Morphine v1.2 packer.
- The malware does not make any connection with the outside world.
- The malware apparently has keylogger functions.
- The malware makes a TLS connection against the domain dankleo01.chickenkiller[.]com (IP 91.192.100.59).
- The malware makes a connection against the domain iptrackeronline.com.
- Before the vfggggg.exe file appears, another exec file appears: gabkrj.jpg.exe, which launches the explorer.exe and creates it.
- 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 www.iptrackeronline.com 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: newmasterchef@protonmail.com.
- 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. Block domains in the proxy or firewall to prevent any malware progression.
- 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 .doko.moe 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 doko.moe";classtype:trojan-activity; content:"doko.moe"; sid:666666667; rev:1; ) alert udp any any -> any 53 (msg:"Malware Cryptostealer DNS doko.moe"; 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 doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:59223 -> 192.168.25.2:53
04/07-04:43:45.886443 [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49168 -> 185.83.215.16:443
04/07-04:43:47.738537 [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49172 -> 185.83.215.16:443
04/07-04:43:53.321598 [**] [1:666666668:1] Malware Cryptostealer DNS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {UDP} 192.168.25.128:63047 -> 192.168.25.2:53
04/07-04:43:53.411079 [**] [1:666666667:1] Malware Cryptostealer HTTP/HTTPS doko.moe [**] [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.25.128:49173 -> 185.83.215.16:443
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 {
strings:
$header = "{\\rtff"
$objdata = "\\object\\objautlink\\objupdate\\objw5816\\objh6097{\\*\\objdata" nocase
condition:
$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.
