A recent example of wire transfer fraud

Published: 2016-01-07. Last Updated: 2016-01-07 02:40:47 UTC
by Brad Duncan (Version: 1)
14 comment(s)

Introduction

Do you know about any attempts of wire transfer fraud in your organization?  They often start with phishing emails.  These emails are used to trick an employee into wiring money to bank accounts established by the criminal.  It's an old scam, but 2015 apparently saw a resurgence in wire transfer fraud [1].  Last August, we saw reports that thieves stole $46.7 million from Ubiquity using this method [2].  Since then, at least one organization has shared its experience as the target of an (unsuccessful) attempt at wire transfer fraud [3].

During the first full week of 2016, I ran across such an attempt and thought I'd share.

Chain of events

In most cases I've seen, the general sequence of events runs as follows:

  • Criminal sends an email with a spoofed sending address to one or more targeted recipients.
  • A recipient replies to the Reply-To: address in the email headers.
  • Criminal continues the conversation and asks for a wire transfer.

The actor may spoof an executive from your organization, a business partner, or a customer.  If the actor is successful, someone in your organization will do the wire transfer   It may take a while before people know they've been tricked.  In Ubiquity's case, the criminals managed to steal millions of dollars before the company realized it [2].

Ubiquity is not unique in this regard.  According to the FBI, between October 2013 and August 2015, thieves stole nearly $750 million from more than 7,000 companies in the US using such scams [4].

How does a criminal decide who to target in your organization?  If your company has a website with biographies of your leadership, it's fairly easy to figure out who might be able to authorize a wire transfer.

Example from Monday 2016-01-04

In this example, 17 emails were sent in two waves.  The first wave went to the first two individuals, and the second wave happened almost 6 hours later and went to the last two individuals.  The criminal didn't have the email addresses of the actual recipients, so multiple messages were sent using different recipient emails.  We saw [firstname.lastname]@[company].com, [first initial + lastname]@[company].com, and variations on the domain, like [company].com.de or [company].com.br for those recipients not located in the United States.  A list follows:

  • 16:32:27 UTC - Subj: Please get back to me on this - From: [redacted] - To: [1st recipient]
  • 16:32:32 UTC - Subj: Please get back to me on this - From: [redacted] - To: [2d recipient]
  • 22:17:02 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]
  • 22:17:02 UTC - Subj: Please get back to me on this - From: [redacted] - To: [4th recipient]
  • 22:17:23 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]
  • 22:18:27 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]
  • 22:18:27 UTC - Subj: Please get back to me on this - From: [redacted] - To: [4th recipient]
  • 22:18:45 UTC - Subj: Please get back to me on this - From: [redacted] - To: [4th recipient]
  • 22:18:45 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]
  • 22:18:46 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]
  • 22:18:46 UTC - Subj: Please get back to me on this - From: [redacted] - To: [4th recipient]
  • 22:21:25 UTC - Subj: Please get back to me on this - From: [redacted] - To: [4th recipient]
  • 22:21:25 UTC - Subj: Please get back to me on this - From: [redacted] - To: [4th recipient]
  • 22:21:46 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]
  • 22:22:49 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]
  • 22:23:08 UTC - Subj: Please get back to me on this - From: [redacted] - To: [4th recipient]
  • 22:23:08 UTC - Subj: Please get back to me on this - From: [redacted] - To: [3d recipient]

An example of these emails follows:

Date: Mon, 4 Jan 2016 22:18:08 GMT
From: [spoofed executive's email address]
To: [each of the targeted recipients]
Subject: Please get back to me on this

Do you have a moment?  I am tied up in a meeting and there is something i need you to take care of.

We have a pending invoice from our Vendor. I have asked them to email me a copy of the invoice and i will appreciate it if you can handle it before the close of banking transactions for today.

I cant take calls now so an email will be fine.

Sent from my iPhone

Tracing the source of these emails

Reviewing the email headers, it appears this email came from a virtual private server (VPS) on an IP administered by myhosting.com (a hosting provider).  From what I understand, almost everything in the email headers can be spoofed.  The only certain information is the IP address listed in the "Received" line for your email server.


Shown above:  An example of the message with some of the email header lines.

If we can believe some of the other email header lines, these messages were sent using PHPMailer.

Final words

This diary shows an example of attempted wire transfer fraud seen during the first week of 2016.  It isn't the most sophisticated attempt I've looked into; however, this type of activity seems increasingly more common.

Although technical methods can ;combat these types of scams, the best defense is user education.  Make sure people with authority for wire transfers know to what expect.

Do you have a wire fraud transfer story?  Feel free to share in the comments!

---
Brad Duncan
Security Researcher at http://www.rackspace.comRackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://www.dlapiper.com/en/us/insights/publications/2015/08/wire-transfer-phishing-an-old-scam-returns/
[2] http://krebsonsecurity.com/2015/08/tech-firm-ubiquiti-suffers-46m-cyberheist/
[3] http://fortune.com/2015/10/13/ceo-wire-transfer-scam/
[4] http://krebsonsecurity.com/2015/08/fbi-1-2b-lost-to-business-email-scams/

Keywords:
14 comment(s)

Comments

I have a customer who does business with a company in China.
They pay their vendor in China via a wire transfer that had been established via an email from the vendor. All was well.

Until... my customer ignored my advice, and used a password 'they could remember' to access their IMAP email.

The email account was compromised due to either a weak password, a simple brute force attack on the email server, or the use of a password on more than one system where the password had been obtained via phishing.

How the password was obtained doesn't matter. The attacker took the time to review the email history and found the original email giving information on sending the wire transfers. The attacker then injected an email into the IMAP server from the same email sender indicating that they had changed banks and all future wire transfers would need to go to the specified new account number.

Since the email was injected directly into the IMAP mailbox, ALL of the headers had been spoofed and copied the previous email headers so that careful inspection would reveal no abnormalities.

The FBI was contacted, but I don't believe any resolution was found. Lesson learned.

If your IMAP account is hacked, forget about the headers. The only way to prove the message didn't arrive through your normal SMTP route would be to look for the messageID in the logs, which most users don't have access to.

The takeaway here is to make sure you use a STRONG unique password for your email accounts, not one you can 'remember'. Having your email provider blacklist brute force attempts against your server will also slow down these attempts.

Anonymous

Jan 7th 2016
8 years ago

I think it is worth mentioning a quick-win for many spoofed email scenarios;

implement Sender Policy Framework txt record for your domain _and_ respect SPF for incoming email.
https://en.wikipedia.org/wiki/Sender_Policy_Framework

If you are an organization providing IT services - start with your own domain to make it harder to impersonate your technical support services.

I also think people are not aware of how "cute" a spoofed email looks in your inbox; if it claims to be from your CEO that is "busy in a meeting" it is very likely that your mail client will compliment the email with a picture of your CEO and the expected (always active?) "in a meeting" status, courtesy of the unified communications system.

Anonymous

Jan 7th 2016
8 years ago

Saw another one within the past 24 hours.

Received: from emkei.cz (emkei.cz [46.167.245.118])
by [redacted] ; Thu, 7 Jan 2016 00:37:40 GMT
Received: by emkei.cz (Postfix, from userid 33)
id 89509D57BB; Thu, 7 Jan 2016 01:38:53 +0100 (CET)
To: [redacted]
Subject: Wire Payment
From: [redacted]
Reply-To: abc_ceo@mail.com
Message-Id: <20160107003853.89509D57BB@emkei.cz>
Date: Thu, 7 Jan 2016 01:38:53 +0100 (CET)

Hi [redacted],

Are you at your desk? I need you to process a wire transfer

[redacted]

Anonymous

Jan 7th 2016
8 years ago

We've seen several attempts by the "Francophoned" gang (detailed here by Symantec - http://www.symantec.com/connect/blogs/francophoned-sophisticated-social-engineering-attack) to do the same thing. However, this gang appear to be based in Israel and do everything in French.. perfect French.

Anonymous

Jan 7th 2016
8 years ago

Oh yeah I see these all the time, at least one a week spoofing execs in the message from header (but often not envelope sender). Here's one from this morning, I'm still waiting to see if the mysterious Gary Cooper contacts my user.

[redacted],

Regarding a new Acquisition we are finalizing, Attorney Gary Cooper
will be contacting you shortly.

I need you to provide him with some of our accounting details so they
can finish and file the financial forms required for the due process.

We will also need to proceed with several payments, the first one to
lock the Acquisition and the followings to finalize it. He will
further explain to you how to execute the wire instructions following
the regulations in place.

It is crucial for the company this operation is executed swiftly,
efficiently and with extreme discretion.

Again, you need to keep this matter very confidential to avoid any
financial fines or worst, I am sure you understand.

Any question you may have must be addressed directly to Gary.

We will be going public with the Acquisition as soon as it is done and
the rest of the company will be made aware.

Thank you for treating this with your utmost attention.

Best Regards.

[redacted]

Anonymous

Jan 7th 2016
8 years ago

We had this attempted against us last month. We have SPF in place so the crooks purchased a domain name that looked like ours but if you paid attention it was one character off. Our financial controller exchanged a couple of emails with "our CEO" (the crooks) but caught on before any funds were transferred.

JH

Anonymous

Jan 7th 2016
8 years ago

How does everyone suggest the handling of these events? Issue an abuse complaint? Track them in a spreadsheet?

Anonymous

Jan 7th 2016
8 years ago

I always encourage people to track these sort of events. Documentation is always important, and the details could be critical. See if there's anything common, and you might be able to identify a particular actor. Abuse complaints may not be effective in stopping the activity, because an aggressive criminal can easily change where they're coming from. People should still file abuse complaints, though. If only to generate more documentation on the activity.

Anonymous

Jan 7th 2016
8 years ago

It is amazing that a business would allow millions of dollars of wire transfers based solely on a simple email communication that can be easily spoofed or socially engineered without having both further technical protections in place on the communication and a more secure process. I can think of several ways to improve this process:

Technical controls:
1. Use digital signatures on all wire transfer emails (internal and external requests). No validated signature = no wire transfer. Sure the requesting wire transfer party could be hacked, signing key stolen, and used to initiate a fraudulent transfer, but it still raises the bar a bit for the actor.
2. Use anti-spoofing measures on the public-facing MX. If someone is trying to send email to your domain from the internet using your domain in one of the From headers you should block or quarantine it (there are a few that spoof the From header and are legit but this should not be the case for a wire transfer email request). Your public-facing MX should be aware of where it should receive mail from your email domain (typically from very specific internal IPs only)
3. Examine your mail logs and identify which mail servers are used to send mail to your org from specific external domains (if there are a ton to sort through, then only do the ones that would send wire transfer requests via email). Say person@domain1.com sends from myhosting.com servers. If you get an email from person@domain1.com from a different domainFlag or quarantine emails from known domains that are sent from different servers other than what you have alreday profiled.
4. Encrypt all wire transfer emails so they are not easily read while at rest in case the mailbox itself is compromised. This will prevent an actor from determining your wire transfer process by reading older emails.

Process:
1. Establish a well-documented process for wire transfers and train those who would handle wire transfers in the org on the process. Instruct them to immediately escalate anything that does not exactly follow the process.
2. Set expectations for the external entity. Generally some relationship has to be established between an org and external entity prior to any wire transfers taking place (at least one would hope this is the case). Your process (at least what is and is not acceptable to your org) should be clearly communicated to the external entity so they are aware that any deviations from it will not result in a transfer. Also exchange digital signatures at this point if that is part of your process.
3. Set up a second factor of some kind at the start of the relationship to validate emailed wire transfer requests such as a phone number to call and verify the request or approving party to contact and verify the request prior to initiating the transfer. The second factor should not be done over an email channel.

User training is probably the most effective technique, and simply training those involved in the wire transfer process to escalate to security when something doesn't look or seem quite right with a transfer request would prevent most transfer fraud.

Anonymous

Jan 7th 2016
8 years ago

... all the headers could be spoofed ...

However, I think that the line:

>>> X-PHP-script: dear.isdc.ac.in/lsyxxx.php for 69.129.222.142

referencing the FQDN: h69-129-222-142.clevwi.dedicated.static.tds.net

probably is telling the truth, namely that a computer at "Iswar Saran Degree College, a premier constituent college of the University of Allahabad (Pradesh province, India)" was compromised, and a "rogue" PHP-script was uploaded.

Then, a web-page generated by the PHP-code was probably a "fill-in-the-blanks" web-form,
accepting 'To:' and 'From:' and 'Subject:' and "body" fields.


Right now, the DNS-servers for the domain:

isdc.ac.in nameserver = ns1.megahostingweb.com
isdc.ac.in nameserver = ns2.megahostingweb.com

do not return an IP-address for the FQDN. Remediated, by removing the TYPE=A record?

Could there be a local DNS-server at 'isds.ac.in' containing different records
than the above "public" DNS-servers?

Google tells me that their web-server allows directory-access: http://isdc.ac.in/images/
which includes a congratulatory letter from Prime Minister Gandhi: http://isdc.ac.in/images/gandhiji.jpg
Not, presumably, for the skill of their Information Security Team. :-)

Anonymous

Jan 7th 2016
8 years ago

Login here to join the discussion.


Top of page
Diary Archives