Our network admin was made aware of a possible phishing email attack and at the same time reminded of the need for constant internal threat detection when an intrusion attempt was made via a word document attachment. After obtaining the Indicators of Compromise data, we used Scrutinizer to figure out if there was anyone on our network communicating with the suspicious IPs or domains.
Normally, something like this would be detected and stopped via our SPAM filter, but in this situation, the email in question passed through because the definitions was not listed in their Real-Time Virus Database. To be clear, the definition was updated in a short period of time after the incident but during that small window the email was delivered and now had the opportunity to deliver its payload.
As I mentioned before, the message got through before the virus definitions were updated. This is why it is so important to have multiple layers of security on your network and forensics tools that give you complete visibility into your network’s traffic. At this point, the email issue and accompanying information was brought to the attention of our Plixer’s Security Guru Tom Pore for a deeper inspection. He then ran it in a sandbox and discovered its behavior.
It all starts with a phishing email.
Innocently enough, the end user receives an email with a Word document attachment that appears to be legitimate. At some point, your local spam or email client might determine that this is a phishing email indicator because of the attachment, but a user might open the file anyways. Tom needed to download the payload and open the file, so he forwarded the email with the attachment to his test account. Next, he opened the attachment to analyze its behavior. Here is what was found.
The Word document, attached in this phishing email, contained embedded VBA macros that among other things:
- Contacts a domain
- Contacts a server
- Install hooks/patches
- Contains multiple C2 mechanisms
- Runs a shell command: “cmd /c C:\Users\PSPUBWS\AppData\Local\Temp\12527.bat”
Indicator of Compromise
After that, Tom found the IOC data and used Scrutinizer to determine if there was a breach and where it might have happened. To be completely honest with you, I didn’t know what Indicator of Compromise (IOC) was and why it was important. Thank goodness, there is a WIKI page for it! IOC data can help assist with malware forensics by giving you a better idea of what he was up against.
“Typical IOCs are virus signatures and IP addresses, MD5 hashes of malware files or URLs or domain names of botnet command and control servers. After IOCs have been identified in a process of incident response and computer forensics, they can be used for early detection of future attack attempts using intrusion detection systems and antivirus software.” – Wikipedia on IOC
Here is the Indicator of Compromise data he was able to obtain.
- oks/patches
- Contains multiple C2 mechanisms
- Runs a shell command “cmd /c C:\Users\PSPUBWS\AppData\Local\Temp\12527.bat”
Incident Response IOCs
Domains: themertailor[.]com, www.themertailor[.]com
IPs: 50.116.75.180 (TCP 80)
Compromised Domains include:
Themertailor[.]com
Mirai2000[.]com
HTTP Gets include:
“GET /admin/controller/777763172631572.txt
“GET /dmin/controller/rara.txt
Incident Response IOCs
Domains: themertailor[.]com, www.themertailor[.]com
IPs: 50.116.75.180 (TCP 80)
Two points of interest were the HTTP Gets and the IP /Domain sections. On the left, we have the contents of the HTTP Get
request. As you can see, the Rara.txt drops a file out of dropbox which comes back as Dridex sample – 7a40bde026e4a13f563c8f58
cb8ed2d6e32e9dfa1e5ee179115
bab6e6567069f
Dridex is a sophisticated Banking Trojan. Its core functionality is to steal credentials of online banking websites and allow a criminal to use those credentials to initiate transfers and steal funds.
He also pulled a pcap of traffic 66[.]240[.]183[.]19:843 and found the config associated to this also could also use 76[.]74[.]177[.]209:8443 and 87[.]254[.]45[.]100:
1443
So how do we monitor for this in Scrutinizer?
- Search all exporters for IP 50.116.75.180 and the presence/absence of communication.
- Save a report for a time frame of Last 5 minutes
- Add a threshold to email if communication is detected
- Contact Plixer to have domain added to malicious domains in FlowPro Defender
Flow ProDefender
Earlier this year at InfoSecurity Europe 2015, we introduced a tool that allowed Scrutinizer to incorporate DNS data and detect DNS Command and Control, DNS Leak, Botnet Detection, and more. This is important because, as Tom points out, communication was from specific IP address, but what if those IP’s hosted multiple domains? What if the other domains hosted on that IP weren’t bad? That is where FlowPro Defender picks up, because it can correlate conversation data with DNS records allowing you to identify who on you network was communicating with that specific domain. In this incident, Tom took the domain listed in IOC data and was able to verify that no one on our network reached out to those domains. The good news is that we weren’t compromised. Good job, Tom!
So as our Guru pointed out in his alert email to us at Plixer, please use caution when clicking on URLs or opening attachments. Make sure to always ask yourself . . .
- Were you expecting this email?
- Do you know who sent it?
- Does it look right?
and NEVER OPEN AN ATTACHMENT unless you were expecting one!
If you would like to learn more about how Scrutinizer can help you stay vigilant and asset in detecting incidents like this, give us a call and we will be more than happy to help.
