Incident Response: The curious case of the domain in the night

Recently we had a call from a client who had received an extremely targeted malicious email, aimed at convincing the financial director to transfer a large amount of money to a designated bank account at the apparent request of someone else senior in the same company. I’ll save you the suspense and reveal they didn’t fall for it, but it was close. The perpetrator had either done very good research, or knew the company somehow.

What was notable, and the first time I have seen this, was the domain the malicious email was sent from. It was, as is not untypical in very targeted attacks, a domain extremely similar to the target companies legitimate domain. Now, most spam and phishing attacks just spoof the domain they are sent from (meaning an email that appears to be sent from info@yourbank.com actually originates somewhere else on the internet) – it’s trivial to do, and works well enough for a range of criminal and other nefarious, uses. There are some downsides though. For this malicious attack, the attacker wanted the email to appear to originate from someone at the same company. They could still do the same thing, and spoof the message source and send from a random location on the internet, but some mail servers will reject email that pretends to be internal, but clearly originates from out on the internet (top tip: make sure your mail server does this. Reject email that appears to come from an @myorg.com email address, but which originates externally).

The second problem with spoofing a source email address is that you, the attacker, do not get any replies that might be sent. Those go to the email address you have spoofed, as your target email system believes that to be the true origin. In the case we were investigating the attackers wanted to be able to communicate with the target, and reply to any questions they had in order to try and convince them that the request to transfer funds was genuine.

Back to what was notable about this domain – it was extremely similar to the legitimate domain of the targeted companies, with just a vowel swapped. A malicious email was sent in to the financial director, ostensibly from someone else in the company, asking if the financial director had received their previous email requesting a transfer of funds. The financial director had not, and replied saying so (not suspicious at this point). Whether or not a previous email had been sent is unknown – it is possible that this was a gambit to increase the apparent urgency of the subsequent request. The financial director quickly received a reply, with instructions for the transfer of a large sum of money to a named bank account. Although the social engineering was extremely good, and the request seemingly well timed as the person apparently making the request was in reality abroad on a business trip and out of contact, the financial director got suspicious and then noticed the misspelt domain name the email originated from. At this point the gig was up.

We were called shortly afterwards. I was forwarded the two emails, both with headers intact. I promptly used Centralops to query the domain name, and see the registration details (with no great hope of much being revealed – criminals are usual smart enough to use a privacy protection service, or fake info). However, I got nothing. No such domain. Odd I thought. And tried a different tool. Same result. Indeed it seemed the domain in question was available for purchase. I double checked the email headers. The domain I was looking up was correct – there was no trickery or special character, or ‘reply-to’ set. Very odd, I thought.

Some more thorough digging, and using (paid for) tools from Domain Tools led me to the answer. The domain had been registered, via Vistaprint, the day before the malicious email had been sent. The registration had been valid for one year, but clearly once realising they had failed the attackers deregistered the domain (something I hadn’t appreciated you could do).  So I had an answer, even if not a revealing one.

The rest of the email header was not especially helpful. The email had been sent from webmail provider, via an open proxy (a computer set up to allow others to obfuscate their true location).  At this point we advised our client to go to the police as the bank account details given were for a UK bank, and something law enforcement could fairly easily progress.

Some takeaways from this:

• Never trust email. If your organisation does sometimes legitimately need money transferring to another business promptly, ensure you build in an additional verification step (such as phoning the requestor). Criminals, be they trying to get you to install malicious software or transfer large sums of money, want you to believe time is of the essence, and that there will be repercussions if you do not act quickly. Build procedures that mean that can’t happen, and ensure your staff know taking time to verify a request is never bad.
• Review the amount of information you reveal about your company online (see our recent post on OSINT). This email was very targeted, but then a brief search revealed lots of information online about the senior managers.

Thanks for reading. Any questions, find us on twitter, or use the contact form.  Also if you liked this post why not share it on Twitter or LinkedIn using the link at the top?

Rob