Business Email Compromise (BEC) Fraud is Exploiting the Cloud

Business Email Compromise (BEC) Fraud is Exploiting the Cloud

Business Email Compromise (BEC) fraud: It has been officially tracked by the FBI since 2013 and identified in more than 100 countries with losses totaling in the billions of dollars. Unfortunately, BEC is now moving to the cloud. New Tools, Tactics, and Procedures (TTPs) focused on cloud exploitation were discovered in the wild in 2018 with continued maturation into 2019. BEC scammers are taking full advantage of cloud exploitation before the industry implements new cloud-specific solutions against these attacks.


The FBI has identified four distinct phases of BEC:


  • Target Acquired – A scammer can identify a target, or it can be leveraged from an existing or previous compromise of a business
  • Grooming – This can involve telephone calls, social engineering and, most commonly, a spear phishing email targeting a specific user or a specific organization
  • Exchange of Information – Occurs between the scammer and the target
  • Wire Transfer – The victim, who thinks the scammer is a legitimate contact, sends money to the scammer. 


An Attack Case Study

In the spring of 2018, a new style of BEC fraud took place which exploited the Microsoft Office 365 cloud environment. While traditional security controls on an organization’s typical network architecture work much of the time, the occasional malicious email gets through leading to possible compromise. In this instance, at least two victims in the same company were hit with a targeted spear phishing campaign. Once the emails got through, the scammers pivoted to the cloud to orchestrate the rest of their attack, successfully bypassing security controls in the traditional security environment of the target.


In staging the attack the scammers:


  • Created a typo squatting domain. (Think “” instead of the legitimate “” regarding capitalization of the “I”.)
  • Created rogue Punycode domains. Punycode domains enable scammers to conceal a possible hostile domain by obfuscating it within ASCII or Unicode representations. A benign example of this conversion is seen with the domain mañ translating into the Punycode domain xn—
  • Created an autodiscover sub-domain for the registered rogue domain to increase confidence in the messaging orchestration as part of the attack.
  • Crafted spear phishing emails using the compromised email account through the rogue domain.
  • Configured the DNS MX record to increase rogue email reputation and trust.


The attack was launched against multiple users within the targeted organization. At least two of the targets had their email login credentials phished. Security controls were in place to ensure the endpoint did not contain malware, however, e-mail credentials were successfully harvested by the scammers, enabling them to gain remote access to the Outlook 365 (OWA) cloud instance of the compromised email accounts.


Once the scammers had control over the OWA accounts they immediately:


  • Created an auto-forwarding rule for the rogue domain emails to control communications if and when the email was used.
  • Created an auto-filtering rule for scammer alerting and management of emails in the cloud.
  • Filtered data into the RSS Subscriptions directory in the cloud to conceal cloud activity from victims.
  • Performed reconnaissance and monitoring of messages to obtain copies of people, processes, and documents critical in the authorization of wire transfers for normal operations with trusted clients and partners.
  • Modified documents were created by the scammers where differences were difficult, if not impossible, to detect to the human eye.


Once the scammers had full control over messaging in the cloud and had the modified documents staged, they were able to send emails to and from accounts, as if they were the manager or other roles victimized in the target company, to stage the attack. One example of how to do this is that an organization may require an invoice or wire transfer request to be signed and sent by a manager to one or more individuals internally before being processed. Scammers can control and orchestrate this activity in the cloud until an email chain is successfully constructed or created based upon data and processes available to them. They can then initiate a wire transfer request to their real victim, an accounts payable employee in the target organization.


Normal methods of authentication by accounts payable may involve looking for attachments with appropriate signatures by an external client and internal managers, and an email thread showing authorizations. In our case study, this had been constructed and forged or modified from a legitimate set of transactions so that wire transfers were sent to a rogue account overseas. Once the wire transfer was completed the funds were lost without the hope of recovery. 


Wire transfers commonly range in the hundreds of thousands of dollars to over $1 million. It is not uncommon to see multiple transactions attempted or performed for a single relationship abused in such BEC fraud. Some targets have dozens, if not hundreds, of relationships that can be concurrently abused for such BEC fraud while a compromise in the cloud is taking place. This can quickly result in the loss of millions of dollars due to the scale and scope of the fraud and the inability of a target to realize they are compromised.


Additional Challenges

Humans are often the strongest link in the chain of detection for BEC fraud orchestrated in the cloud. For example, in a smaller organization such as a real estate office or bank, individuals may be seated next to one another, thereby having a closer relationship than remote employees and they may ask a coworker about a transfer request. If an unauthorized BEC wire attempt is made, workers in these scenarios are often the ones to detect it, as traditional security measures have been subverted due to a lack of controls and monitoring in the cloud. Once possible fraud has been discovered it is all too common for victims to subsequently use email to notify IT – using the very accounts that are compromised. This is of course monitored by the scammers who are notified of their discovery and take counter actions.


In more than one instance, the exit strategy of a cloud-based BEC fraudster has been to initiate an outbound email spam campaign on a secondary victim account. The strategy results in a large number of spear phishing attacks being sent from the initially targeted and trusted organization to other organizations targeted by the BEC scammers. In these situations, the email distribution could easily involve all contacts for the targeted organization’s compromised email accounts as well as that of targeted accounts identified by scammers for their own custom spear phishing list.


Lessons Learned and Prevention

Traditional BEC fraud is now regularly attacking the cloud for maximum survivability and profit. Security, in the adoption of nascent solutions, is often frequently ignored - this is especially true for those adopting cloud services within the past 18 months. It is rare that an organization prioritizes staging and testing cloud security before hosting data in the cloud. 


Humans are often the weakest link in the chain, especially when considering emails and social engineering, but they can also be an organization’s greatest strength. Properly trained staff, with Out of Band Authentication (OOBA) for critical operations such as wire transfers, can successfully stop such attacks. 


Incident response must consider cloud and global credential management when responding to an incident. Encryption for sensitive documents requiring a signature also helps prevent data mining by scammers for this type of BEC fraud. Additional controls may also be put into place on the network layer to help monitor and identify typo squatting and Punycode domains. Proactively, security controls need to be placed into the cloud to ensure logging, permissions and monitoring on a regular basis. For this new type of attack method, audit OWA365 regularly for rules related to forwarding and filtering and rules related to data in the RSS Subscriptions directory which should not exist there normally. Additionally, monitoring failed login attempts and successful foreign IP logins is recommended.


Security must be a top priority, especially with the adoption of a new technology or process. As organizations adopt cloud, they must ensure they have included security controls and solutions to manage risk. Stay abreast of ongoing updates to TTPs and threats impacting cloud security, and where possible applying lessons learned as the threat landscape continues to change.

Ken Dunham
Senior Director, Technical Cyber Threat Intelligence
Ken Dunham has spent 30 years in cybersecurity, consulting in adversarial counterintelligence, forensics, Darknet Special Ops, phishing and hacking schemes, AI/BI, machine learning and threat identification.