Phishing attacks are on the rise and no one is immune, not even an incident response team member. Yes, you got it, I was on a client call discussing methods for the automation of reporting phishing emails when, low and behold, I received a phishing email into my mailbox (you literally could not write this stuff). As if that was not enough, just a few hours later, I was hit with a second phishing email… clearly I have rubbed someone up the wrong tree!

I followed NTT Security protocol and reported the emails before swiftly deleting all traces from my mailbox. However, I may have also retained copies (don’t try this at home kids) to do some digging and see what information I could gather from a quick triage of the raw EML files.

The first email in question was very suspicious from the off, as depicted below. First of all, I have had no dealings from South Africa in terms of purchasing or invoicing (other than security incident engagements) and, second, the layout of the emails just raised flags - not to mention the recipient email address.

The good news is I did not click the link, however I may have hovered over it to see what the URL link was.

Let’s take another look at the email content, in ASCII, to see the true text.

As you can see, we have a delivery web URL and, following a quick check via VirusTotal, it appears to be flagged as malicious. By exploring the additional details, you’ll also uncover the serving IP address for the domain, which is linked to other malicious infrastructure.

So what now? Let’s review the email header and source IP.

Received: from za-smtp-delivery-200.mimecast.co.za (HELO za-smtp-delivery-200.mimecast.co.za) (41[dot]74[dot]201[dot]200)

The aforementioned header was extracted to extract the source IPv4 address for the email, however it resolves back to Mimecast, South Africa. What I should probably mention at this point is this email was originally sent to an old email address of mine (which I no longer use) and a mailbox forwarding rule sent it onto my new email. Digging deeper it was possible to uncover another IPv4 address from the true source.

Received: from mail6.bemta25.messagelabs.com (195[dot]245[dot]230[dot]46)

Now we are getting somewhere, we have some detections, courtesy of VirusTotal.

Additional IP addresses extracted from the email header depict additional links to a variety of malicious malspam campaigns and Trojans.

At this point, I created a sandbox environment to carry out some dynamic analysis to understand behavior. Low and behold, once the web URL link is clicked, IE is launched and attempts to communicate to several command and control (C2) servers. The additional IP addresses for the C2 servers were triaged and, again, the servers were found to host a wide variety of malicious payloads waiting to be deposited onto the system. One of the C2 servers was found to be:

Domain: web[dot]tresorit[dot]com

IPv4 address: 40[dot]112[dot]93[dot]201

To conclude, you can see how easy it is to uncover loads of valuable information - just by carrying out a small amount of triage. This has provided me with IOCs including, but not limited, to IP addresses of C2 servers, hash values for malware and other indicators of compromise. The primary malware family was found to be Emotet, which is a well-known banking Trojan designed to steal sensitive credentials. Emotet can be difficult to contain, due to its polymorphic nature allowing it to avoid detection via its signature.

As mentioned, having just recovered from this ordeal, a second email came through. This time from a Protonmail address. Protonmail is a secure end-to-end encrypted email system and, while designed to optimise users privacy, it is often used by threat actors to communicate with their victims. This email was, again, very suspicious from the off. First of all, the email titled ‘payment’ contained a single web URL link, to a PDF file, hosted online via Adobe Document Cloud. The same process was repeated to triage the content and it was identified this was also a viable threat.

There's no slowing down for phishing, as discussed in our latest Global Threat Intelligence Report, and it's vital employees stay alert when jumping around their inbox, to ensure they do not trigger the next security incident!