Over the last decade, the migration of applications and compute to using cloud has shifted users’ resources and identity/authentication methods to internet-accessible public channels. The functionality and convenience offered by cloud-based IdPs and federation can hardly be overstated; collaboration between organisations and access to cloud-hosted applications have been completely transformed by it.

However, because they are internet-accessible and highly prevalent, these IdPs are a key target for attackers seeking an initial foothold within an organisation. While there has been a continuous game of “whack-a-mole” to harden authentication steps over recent years, phishing and proxy kits like EvilNginx remain accessible, easy to use, and highly effective for gaining unauthorised access. When we conducted active testing with these kits a while back, I was shocked by how straightforward the setup was.

What is Attacker-in-the-Middle?

Attacker-in-the-Middle (AitM) is a simple concept. Through phishing or misdirection, the adversary tricks the user into visiting a malicious site designed to mirror a legitimate authentication page. As the user interacts with it and completes their standard authentication flow (password, push-notification MFA, etc.), the attacker proxies the traffic back to the real IdP. Once the IdP returns a successful authentication response, the attacker’s infrastructure intercepts and harvests the resulting tokens – effectively minting its own key for access. From there, the adversary can use the active session window to achieve their objectives using the compromised user’s identity.

AitM is a crafty technique – with the right planning and OpSec by a threat actor, it can be remarkably difficult to detect.

Mitigating AitM Threats

if you are worried about Attacker-in-the-Middle threats, here are some practical places to start:

• Implement effective, layered inbound email security controls. Relying solely on default protections like Microsoft 365 P2 or Google Workspace Enterprise+ isn’t enough. Sorry.
• Implement a solid identity configuration using conditional access, context-aware access, and phishing-resistant MFA wherever available.
• Educate your users on how to spot and report suspicious activity through a suitable training program and a dedicated abuse/phishing mailbox.
• Validate and harden your network and browser-level controls to increase visibility and potentially block malicious clicks.

Failing all of that thwarting, detection becomes our last port of call. I recently worked on building out new detection logic for this exact scenario. Obvious disclaimer: This specific rule might not catch every threat actor, and this logic differs from what we run internally for our Wingman MDR customers, which includes additional proprietary techniques.

Detecting AitM in Google Workspace

There are many ways to approach AitM detection, and we’ve built a real war-chest of techniques across various IdPs for our customer base. Here, I want to focus on Google Workspace. While account compromises on Google Workspace are reported less frequently than on other cloud IdPs, it is far from immune to these attacks.

The rule I’ve presented here covers a scenario that might seem ridiculously simple: we monitor for when a user clicks a link or opens an attachment in an email, followed by a sign-in event from a different country tagged with an is_suspicious flag. While many factors can trigger a user to enter credentials, this remains a very common and effective attack vector.

This brings to mind a memorable quote from the movie Glass Onion, A Knives Out Mystery: “It’s so dumb, it’s brilliant.” (let us leave Benoit Blanc’s last line of that exchange out of this). If logic successfully identifies threat actors, it works: years of detection engineering have taught me that you can easily overcomplicate things, and often, simple is smart.

YARA-L Detection Rule

The rule below, crafted in Google’s YARA-L 2.0 language within Google SecOps, has two main constructs: $email, which tracks the user’s interaction with a received message, and $login, which captures the suspicious sign-in event. The rule correlates the two by comparing geographic locations: if the countries differ, bingo, an alert is generated.

There are a few more levers you can pull:

• Remove the country comparison constraint ($emailcountry != $logincountry). Threat actors may deliberately operate from infrastructure geographically close to the victim, or proxy requests such that some traffic originates from the user’s own IP space.
• Restrict the rule to inspect only externally sourced emails. (I kept internal emails in scope here because a previously compromised internal account could be used to target peers laterally.)
• Expand the trigger events beyond email interactions.or example, looking for users opening shared Google Drive links from external domains or joining external Zoom meetings.

rule auth_workspace_phish_and_aitm_login {

    meta:

        author = “SEP2 – Benoit Blanc”

        description = “A user receives an email, opens the link or attachment, an is_suspicious:true flag occurs on their Workspace account. These two events occur from different countries”

        severity = “High”

    events:

        $email.metadata.log_type = “WORKSPACE_ACTIVITY”

        $email.metadata.event_type = “EMAIL_TRANSACTION”

        (

            any $email.security_result.action_details = “11 – A link in an attachment was clicked when the attachment was previewed.” or

            any $email.security_result.action_details = “20 – One or more message attachments were previewed.” or

            any $email.security_result.action_details = “10 – One or more message attachments were downloaded.” or

            any $email.security_result.action_details = “9 – A link in the message body was clicked.”

        )

        $emailcountry = $email.principal.ip_geo_artifact.location.country_or_region

        $user = $email.security_result.about.email

        $login.metadata.log_type = “WORKSPACE_ACTIVITY”

        $login.metadata.event_type = “USER_LOGIN”

        $login.additional.fields[“is_suspicious”] = “true”

        $logincountry = $login.principal.ip_geo_artifact.location.country_or_region

        $user = $login.security_result.about.email

        $emailcountry != $logincountry

        $email.principal.ip_geo_artifact.location.country_or_region != “”

        $login.principal.ip_geo_artifact.location.country_or_region != “”

        $email.metadata.event_timestamp.seconds < $login.metadata.event_timestamp.seconds

           //$email.network.email.from != /@yourmaildomain.com/ //This rule can optionally be restricted to external only emails additionally

    match:

        $user over 20m

    outcome:

        $risk_score = 60

    condition:

        $email and $login 

}

Analysing the Signal

The is_suspicious = true flag is interesting. Google Workspace has a couple of ways to attribute risk to user sessions that Google seem to keep fairly closed box by design. This flag alone is generally too noisy to alert on for each individual interaction. However, combining it with contextual triggers adds a high-confidence signal to an already suspicious interaction. Google Workspace provides several similar signals such as risky actions, Security Sandbox alerts, and device registration events. These can make up a really nice composite detection use case in addition to the flag. 

A large part of detection engineering comes down to noise management. Leveraging these platform flags can mean the difference between a high-fidelity alert you act on and one that never makes it to production.

There is much that has to be done to make for effective identity protection, but the above can be one tool in your toolbox.

While protections such as Device Bound Session Credentials roll out to improve session security, threat actors will continue to adapt. Stay sharp!