Summary
- Between January and February 2025, an opportunistic Business Email Compromise (BEC) threat actor carried out an Adversary-In-The-Middle (AiTM) attack against a professional services organization.
- The threat actor used eM Client and forwarding rules to maintain persistent access.
- The threat actor registered legitimate Dropbox and WeTransfer accounts using the victim’s corporate email address, allowing them to impersonate the victim and continue the phishing campaign even after losing access to the M365 environment.
- These findings highlight the importance of reviewing and strengthening security measures in cloud environments.
Introduction
In this blog, Invictus shares insights from a recent BEC investigation within a Microsoft 365 environment that began with an AiTM attack – a tactic increasingly common among BEC threat actors. This case piqued our interest when we discovered that, after expelling the threat actor from the environment, they continued phishing numerous organizations using what appeared to be the original victim’s email address. However, the threat actor used the original victim’s corporate email address to register a new Dropbox account and later a WeTransfer account to conduct the large-scale phishing campaign. We hope that this information will be helpful to other incident responders and organizations working on similar cases.
Initial access via AiTM
The incident began when the victim received a Dropbox email containing an invoice with one of their legitimate clients’ names in the subject (see image below).
Clicking on the button called “View on Dropbox” redirects the user to an apparent legitimate Dropbox URL at first glance. However, the link leads the user to a phishing page controlled by the threat actor (see image below). Instead of authenticating with Dropbox, any credentials entered are captured by the threat actor. In this instance, the victim submitted both their login credentials and second-factor authentication code, inadvertently enabling the threat actor to capture the authentication token along with the credentials – a textbook example of an AiTM attack.
Persistence in the cloud with eM Client
After compromising the mailbox, the threat actor installed and granted admin consent to the eM Client application, or a desktop email client for Windows and macOS. The eM Client application included the Graph API permission “IMAP.AccessAsUser.All” to access the mailbox via the IMAP protocol with the same privileges as the signed-in user. This technique afforded the threat actor with the ability to maintain persistence in the victim’s inbox even after revoking sessions or changing passwords.
For some additional background on eM Client, it connects using Exchange Web Services (EWS), an API that enables non-Microsoft applications to integrate with Exchange Online and on-premises Exchange. During installation, users are prompted to add an email address, and after logging in, they must approve the application's requested permissions. Once granted, the threat actor then gains full mailbox access, similar to using Outlook Desktop.
Additionally, eM Client’s ability to manage multiple email accounts from various providers makes it an attractive tool for threat actors. By enabling seamless switching between compromised accounts without repeated sign-ins, the tool facilitates a persistent foothold in cloud environments. This tactic is in line with emerging trends noted in Huntress’ late-2024 blog, which further explains how threat actors are leveraging Microsoft 365 applications to remain under the radar in BEC scenarios.
In addition to leveraging the eM Client application, threat actors employed a more traditional persistence mechanism for BEC attacks – forwarding rules. The threat actors maintained access for three weeks before being discovered. After neutralizing the threat actor by resetting the password, uninstalling the eM Client application, deleting forwarding rules, and revoking all active sessions, the attacker was effectively locked out. Although a few failed login attempts were observed afterward, which is when things got really interesting.
Clever use of Dropbox and WeTransfer
Several days later, hundreds of the compromised account’s contacts – new victims in this attack chain – received authentic Dropbox email notifications accompanied by fraudulent invoices. Although the emails were genuine and originated from Dropbox, the victim had never knowingly set up a Dropbox account. Instead, the threat actor had secretly registered a legitimate Dropbox account using the victim’s corporate email address, thereby broadening the attack to include their regular business contacts.
After contacting Dropbox support, we uncovered a critical detail: Dropbox does not require email verification when creating an account. This oversight enables a threat actor to register an account using a corporate email address without accessing its inbox or confirming ownership. Our investigation also revealed that the threat actor spared no expense with the Dropbox account, paying less than EUR 15 for the business plan.
Once the spam phishing campaign appeared to be completed, the Dropbox account was switched to a different email address by the threat actor. This notion was discovered because the original compromised account received an email with the subject “Your Dropbox account's email address was recently changed.” Due to the original victim’s email no longer being associated with the Dropbox account, we lost access to the “Forgot Password” recovery option. This limitation prevented us from deactivating the account and gathering additional intelligence. Meanwhile, many business contacts continued to report receiving the phishing email, and unfortunately, some were deceived by the scam.
The screenshot below shows that the TA used the name 'Konstantinos' to sign-up for the business account and used it to change the associated email account.
After the storm of Dropbox spam subsided, a fresh wave of phishing emerged, but this time distributing WeTransfer files to the same contacts. Once again, an account was registered using the victim's name and corporate email. After losing access to M365 and burning the Dropbox account, the next spam wave used WeTransfer, with the attackers waiting until the end of the month when invoices are typically sent out. It is believed that threat actors favor WeTransfer because it allows them to include a custom comment with the file-sharing notification, adding a sense of urgency to the message. Interestingly enough WeTransfer noticed this attack, because after we made inquires they responded that the account was blocked. However they never informed our client of this, which would've been a very useful indicator.
Not their first time phishing
In an attempt to find more indicators of compromise we pivoted on the DropBox and WeTransfer URLs, which redirected to other websites presenting fake Microsoft login pages. The fake login pages all had similar infrastructure characteristics, such as the domains being registered with NameCheap and using the same name servers (ns1[.]maindksdns[.]com). Furthermore, the domains were likely produced with a Domain Generation Algorithm (DGA). The DGA appears to produce domains by concatenating a 10-character random sequence with a fixed name element and then appending a top-level domain (TLD) from a preset list (e.g., store, shop, or net). For example, consider the domain rmlsjufbad[.]bolaa[.]shop:
- rmlsjufbad is a 10-character random string
- bolaa is the fixed name element
- .shop is the chosen TLD
This automated approach allows threat actors to rapidly rotate their infrastructure, making it difficult for defenders to track or block their malicious activities.
Overall, these phishing campaigns align with the behavior of a highly opportunistic criminal threat actor conducting BEC attacks. Analysis suggests that this particular campaign likely began as early as 02 January 2025 based on SSL certificates and domain registration dates. Additional evidence from infrastructure characteristics, such as the registrations on 209.74.66[.]141 points to at least one other campaign by the same threat actor dating back to September 2024. Unfortunately, it is highly likely that this was neither their first attempt at BEC attacks nor their last.
Indicators of Compromise
For further details on this campaign, we’ve compiled a list of IOCs and TTPs into a repository on our GitHub. This resource provides full context on each indicator and the corresponding MITRE ATT&CK mapping, enabling you to correlate these findings with your cloud logs.
About Invictus Incident Response
We are an incident response company and we ❤️ the cloud and specialize in supporting organizations in preparing and responding to a cyber attack. We help our clients stay undefeated!
🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/24-7