Spearphishing, Business Email Compromise (BEC), and Email Account Compromise (EAC) attacks continue to silently menace businesses across the globe, steadily outpacing damages inflicted by other attacks such as ransomware. Adversaries traditionally rely on social engineering schemes that allow them to trick unsuspecting users into facilitating payment fraud, disclosing sensitive information, or installing malware.
Social engineering vs. account takeovers
BEC attacks usually involve rerouting funds into accounts under the adversary’s control. Adversaries commonly accomplish this via relatively unsophisticated methods of social engineering, like by typosquatting or spoofing corporate domains in email headers so that victims believe they’re engaging with a legitimate business partner. These schemes remain successful despite increasingly watchful employees who are wary of financially themed emails originating from unknown or external sources.
On the contrary, employees are far less likely to flag internal-to-internal communications as suspicious. As such, adversaries have ample incentive to compromise email accounts rather than simply impersonate them. Gaining access to these accounts with legitimate credentials also allows adversaries to search the inbox for useful messages or interesting documents. While the upfront effort of compromising victims’ credentials is harder, the success rate of this attack is typically much higher.
What we (almost always) saw in 2022
In the past year we’ve identified and detected numerous compromises where adversaries abuse valid credentials to silently modify a victim’s mailbox settings. The intent is almost always to redirect specific emails of interest to places that legitimate users are unlikely to look. These incidents almost always unfolded in the same way: the adversary generated email inbox rules to filter and hide emails from the user by placing them in rarely used, built-in folders like RSS Subscriptions, RSS Feeds, or the Archive folder.
Adversaries then use the newly discovered information during their reconnaissance efforts to craft emails to the accounting or payroll departments requesting to update direct deposit information or to otherwise redirect funds to accounts under their control. We’ve also detected threats where the adversary creates inbox rules to automatically mark as read and move password reset emails. The adversaries then remove all traces of their access by deleting the password reset emails and all of their newly created inbox rules. Of course, from a victim’s perspective the activity is silent, but with robust logging like the Microsoft Unified Audit Log, tracking the adversary’s moves is fairly easy.
The expedited timeline of these intrusions shows that adversaries spare no time in moving from initial access to their objectives. We’ve observed some incidents where the adversary makes their inbox modifications within minutes of compromising the account. We’ve also witnessed adversaries waiting an extended period of time to carefully perform reconnaissance within the victim’s mailbox, sometimes holding off until the next day to make any direct changes to their account via inbox rules.
Confidently detecting the initial email account compromise is typically difficult, as it requires teams to detect anomalies to a user’s login behavior through a complicated series of alerting algorithms, potentially across numerous devices. As working from home becomes more commonplace—and bring-your-own-device policies remain lax—very few security teams can keep up with the overwhelming number of false positives these signatures typically produce. Some identity alerting platforms take upwards of two days for their own machine learning algorithms to flag what they consider to be a “high-risk” login. By contrast, adversaries need just minutes to programmatically tackle their objectives.
The threat of compromised personal devices in the work environment remains a huge blindspot. These devices often become infected with info-stealing malware designed to grab and decrypt session cookies from browsers, such as the Rhadamanthys, Raccoon, and Vidar malware families. Additionally, man-in-the-middle (MitM) reverse-proxy phishing kits such as Evilginx2, EvilProxy, and Modlishka are also on the rise.
One example of a token phishing technique that we predict will gain traction in the world of EACs, or account takeovers in general, is device code phishing. This attack takes advantage of one of the underlying authorization flows within the OAuth 2.0 Authorization Framework specification, which allows devices without browsers (such as TVs or Internet-of-Things devices) to authorize themselves on behalf of users. You have probably used Device Code Authorization yourself when authorizing your favorite streaming applications on your smart TV, allowing it to continue to operate without continuously asking you to log in.
Without any costly infrastructure setup, all the adversary needs to do is to request a “user code” from a cloud or identity provider and send it with a legitimate URL (like “microsoft.com/devicelogin” or “device.sso.us-east-1.amazonaws.com”) for the victim to enter it into. Part of the initial user code retrieval step is to request access as a specific application like Microsoft Office. Adversaries can generally request any existing application they want as long as they know its application or client_id.
Once the victim clicks the link, enters the provided user code, and authenticates, they’re presented with a seemingly benign consent page, which asks them to simply authorize access for the application initially requested by the adversary. At a high level, this consent page could ask the user something like “Would you like to let Microsoft Office read and send mail on your behalf?,” which to many users seems like a very reasonable request as that’s what Microsoft Office is designed to do.
In the background, adversaries poll the OAuth authorization API, awaiting a user to successfully authenticate. If successful, an adversary could gain a token for long-term access, potentially lasting as long as 90 days. Depending on the client application requested in the original authorization request, their token could grant them read/write permissions to their mailbox, which allows them full access to dump all of the victim’s emails and even send new emails on their behalf.
A crucial aspect for defenders to understand is that, during the lifecycle of this attack, the victim never needs to visit any website or infrastructure they wouldn’t normally visit. The destination of this crafted URL is a legitimate login screen from a cloud service that most users are familiar with—making it harder to detect malicious activity without closely monitoring their sign-in logs. Detecting this attack would require defenders to closely monitor their logs for authentications that originated from the “device code” flow.