Advanced BEC Scam Campaign Targeting Executives on O365

Mitiga spotted a sophisticated, advanced business email compromise (BEC) campaign, directly targeting relevant executives of organizations (mostly CEOs and CFOs) usingOffice 365. The attackers combine high-end spear-phishing with an adversary-in-the-middle (AiTM) attack to circumvent multi-factor authentication (MFA) and a Microsoft 365 design flaw that allows them to create access persistency with MFA.

Leveraging this unrestricted access, the attackers monitor the victim’s email accounts until a substantial transaction is about to happen, and then send a fraudulent email requesting a change of the destination bank account to an account in control of the attackers, effectively stealing those funds.

This campaign is widespread on the internet now and targeting large transactions of up to several million dollars each.

Background

Mitiga was called to investigate an attempted Business Email Compromise (BEC) attack.While the alertness of the involved parties prevented the fraud, the attack showed that the attacker had access to sensitive information that could only be obtained by compromising a user in the organization. This led to a full-blown investigation, uncovering the entire flow of the attackers in the campaign.

The following blog describes our full analysis of the attack.

Business Email Compromise

The incident was initially discovered by a third party of the attacked company, who received the following fraudulent email:

The thread was regarding an ongoing transaction, which had four different parties involved:

Foobar— The company receiving the funds in the transaction

Foobarlegal—The law firm representing Foobar

Buyer—The company conducting the transaction

Buyerlegal—The law firm of the Buyer

The email also contained an attachment with the wiring instructions, but more importantly, the email was a “Reply All” in a thread regarding the transaction, which contained all the latest messages in this thread. This was a clear indication that one of the accounts on that thread had been compromised.

The email that the attacker sent included all the recipients of the original thread. However, the attacker created forged domains for Foobar and Foobar legal using similar domain names, such as using capital i to replace an l, and so on.The attacker used the fake domain F00bar legal to send the mail from Bob, as the authorized legal representative notifying the Buyer of a change in the destination account. They also needed the fake domainF00bar to make sure that the email looked real by seeming to include the recipients of Foobar in CC,without them actually seeing the email due to the new fake domains. The following diagram demonstrates this:

‍

‍

Following the realization that one of the accounts had been compromised, Mitiga launched a full investigation.

Initial Investigation & Containment

After ruling out the compromise of several third-party participants, the investigation concluded that the compromised account belonged to one of the executives of Foobar, who was on the mail thread regarding the transaction. This was determined after identifying logins by that executive’s account from several suspicious IP addresses, including Singapore, Dubai, and San Jose, California — none of which were addresses normally used by the user.

Following this discovery, the user’s password was reset and all sessions were revoked. The user also identified another, unrecognized, Authenticator device registered to the account, and immediately removed it as well (more on this later).

After containing the threat completely, Mitiga conducted a full root cause analysis investigation. Here are the findings:  

Full Attack Flow

This is the high-level attack flow.

Initial Access

• Victim receives a well-crafted phishing email, appearing from DocuSign, with a legitimate docusign.net from address. This was crafted specifically for an individual executive in the organization and is part of an existing phishing campaign targeting executives using Office 365.  
• Clicking the email takes the victim to the threat actor’s site (the investigation identified it as a site in Singapore). This site is part of the adversary-in-the-middle technique campaign, likely using evilginx2 framework (or similar) for 2FA phishing.

During our investigation, we found one Indicator of Compromise (IOC) that overlaps with this post from ZScaler the IOC and the method of operation (MO) of the threat actor described in the Zscaler post indicate it may be a similar or a related threat actor, but with modified MO, leveragingMFA persistency.

• The site simulates a redirect to the M365 SSO login page, perfectly imitating the user experience and look of the original site.
• The victim types in their username and password, which are proxied directly to M365 on the session between the threat actor and Microsoft.
• Authenticator app on the victim’s phone requires second factor verification of the newly created session.
• A valid session is created for the attacker as the victim approves the login. The victim is then redirected to a benign looking error message.

Reconnaissance

• Session is transferred (or proxied) to use in another location (Dubai) for reconnaissance and maintenance.
  
• Attacker uses the newly created session to roam around the Office 365 environment, including access to Outlook (emails) and SharePoint (files).
• Attacker identifies correspondence related to an upcoming transaction and continues collecting information by accessing files related to said transaction(contracts, financial details, and so on).

Persistency

• Attacker uses a design flaw in M365 MFA to create a new Authenticator app for the compromised user. This circumvents various potential security controls, including identity protection and session expiration by completely eliminating the protection provided by MFA going forward for this account! It also allows the attacker to transfer the credentials.
• We have not seen previous reports of this technique in other references to AiTM attacks, and we have published a separate advisory, warning customers of this risk.

Execution

• Credentials are transferred to a different attacker (it is not clear whether they are sold to another group or used by part of the same group), potentially located in the United States (the IP address indicates that this is a possibility, as well as the proficient level of English used in the email).
• Attacker conducts additional reconnaissance, accessing more files in preparation for the attack.
  
• Attacker registers multiple fake domains, replacing Foobar with F00bar and Foobarlegal with F00barlegal as preparation for the fake emails.
  
• The attacker also creates a bank account in Singapore under the name Foobar.
• The attacker finally creates the fake email, as a ReplyAll with the entire original thread quoted, including all the original recipients on the thread, only those email addresses for Foobar and Foorbarlegal replaced with users on the fake domains.
• Finally, the attacker sends the email from an account on the fake F00bar legal account.

At this point, the buyer’s finance team member’s awareness of business email compromise schemes allowed for identification of foul play and eliminated the threat, leading to this investigation.

Technical Details

The following are technical details for the attack.

Phishing Email

The phishing email appears to be a legitimate signing request that arrived from DocuSign.

The sender appears to be a legitimate DocuSign address (dse@docusign.net), However, it is a spoofed address.  

‍

‍

Microsoft tags this email as a phishing attempt (since it does not pass DMARC security checks), however, due to a misconfiguration in the client environment, the email was not blocked and appeared as legitimate in the executive’s email inbox.

‍

‍

It is important to note that this misconfiguration can be a result of guidance provided by DocuSign to eliminate false positive spam alerts. DocuSign provides a list of email addresses it uses to send emails, including dse@docusign.net  and recommends marking them as safe sender. This can easily be misinterpreted and lead to disabling email security checks for these email addresses, enabling an attack such as this. While this article discusses spam filters, it can easily be misinterpreted and lead to disabling email security checks for these email addresses, enabling an attack such as this.

Adversary in the middle

After clicking on the “Review Document” button, the victim is prompted to enter his Azure authentication. However, he is unknowingly interacting with a malicious server, not the legitimate Microsoft server.

The link points to a Google firebase app, which redirects the user to a spoofed domain, such as lointree[.]com (which is probably mimicking liontree[.]com, a known banking firm).

This server proxies the requests between the client and the real Microsoft server and records the victim’s email address and password. Since the adversary only listens in on the connection between the victim and the genuine Microsoft server, it proxies the MFA request as well. The victim is prompted with a genuine MFA request on their MFA device. After approving the request, the Microsoft server returns a valid session cookie, which the adversary sniffs and can then use to assume the victim’s session, without needing to re-enter a password or approve an MFA request.

After completing the malicious login, the victim is redirected to a generic DocuSign error page.

This is supposed to be a graceful fallback that does not raise the victim’s attention, in the hopes that the victim will not realize he fell for a phishing attempt. This way, no security measures are taken, and the stolen session cookie remains valid.

‍

‍

Reconnaissance

After attaining the stolen session cookie, the malicious actor accessed the victim’s account on several occasions. We can find the various applications the attacker accessed using the victim’s session by looking at `UserLoggedIn` events in Azure Active Directory (AD) Audit logs. Each event has an `ApplicationID,` which can be correlated with a specific application connected to the Azure AD by listing the installed applications or by using third-party services, such as AppTotal.

‍

‍

The attacker has not connected to any third-party app, but  almost exclusively to SharePoint and Exchange. Using the irrespective logs, or Azure’s Unified Audit Logs (UAL), we can track the attacker’s exact actions. 

Using SharePointAudit logs, we can see which files were accessed/downloaded, and at what time:

‍

‍

Using Mailbox audit logs, we can see operations performed by the attacker in the victim’s mailbox. We found no active actions, so we assume the only action was reading emails.

MFA Persistency

The attacker added a new MFA device to the victim session to maintain access to the victim account even after the session expires or is revoked.

As previously indicated and published in our separate advisory, adding an additional MFA device to an Azure AD user does not require any additional verification, such as re-approving MFA for the session. This means that the attacker can add an MFA device to the victim account even an entire week after the session was stolen without invoking any further user interaction, such as re-prompting for MFA approval.

The addition of an MFA is recorded by a “Update user” operation in Azure AD logs. This operation logs changes to the user account and contains a field calledModifiedProperties. This field contains a JSON in the form of:

[{

   “Name”:XYZ,
   “NewValue”: …,
           “OldValue”: …
},
{

               …

}
]

Each field in the array records a modified property, its old value, and its new value.

Specifically, when adding an additional mobile phone as an MFA device, we can see the modified property is “StrongAuthenticationPhoneAppDetail.” The “NewValue” contains an array of two devices, while the “OldValue” contains an array of one device, indicating that a device was added by the attacker. Marty’s phone in the screenshot below is the threat actor’s account.

‍

‍

Indicators of Compromise (IOCs)

139.99.6.158 - Singapore, OVH service

154.6.17.158 - New York, VPN service (rackdog)

5.31.10.180  - Dubai

20.245.118.47 - San Jose

hxxps://awin1[%%]com/cread[%%]php

noxdirect.web[.]app - 365 Phishing Infra

lointree[.]com - 365 Phishing Infra

dsena3.web[.]app - 365 Phishing Infra

dxdirect.web[.]app - 365 Phishing Infra

dse@docusign.net - Phish Sender

https://accounts.lointree.com/common/login

https://accounts.lointree.com