Beyond the Bait: Behavioral Sigma Detections for AiTM Phishing

Phishing campaigns are a moving target. The sender domain rotates every 48 hours. The PDF hash changes with each wave. The landing page infrastructure spins up on fresh hosting and disappears before anyone can block it. Chasing those indicators is necessary. It is also a treadmill.

Microsoft’s Defender Research team recently published a detailed analysis of a large-scale adversary-in-the-middle phishing campaign that targeted more than 35,000 users across 13,000 organizations using code of conduct lures, multi-stage CAPTCHA gating, and a polished AiTM session hijacking flow. The full technical breakdown is worth reading at the Microsoft Security Blog. Their detections – Anomalous Token alerts, Impossible Travel flags, and Defender for Office 365 URL click detections – are the right first line of response for Microsoft shops.

This post is about what comes after those platform detections. It is about the behavioral signals that live in your authentication logs, proxy logs, and cloud audit trails regardless of which AiTM kit the attacker is running this week. The lure will change. The authentication abuse pattern will not.

That is what we are building for.

What Makes This Campaign Worth Studying

Before we get to the rules, it is worth understanding why this campaign is a useful detection engineering case study beyond its scale.

Most phishing campaigns are simple: send email, get click, harvest credential. This one is a five-stage operation. The email uses enterprise-style HTML templates with embedded compliance branding and a Paubox encryption notice designed to signal HIPAA legitimacy. The PDF attachment adds a second layer of social context before the user ever visits a URL. The landing page presents a Cloudflare CAPTCHA that filters out automated sandboxes. A second image-selection CAPTCHA follows email submission. A platform-detection script routes mobile and desktop users to different final payloads. The final stage presents a genuine Microsoft sign-in page – because it is one, proxied in real time by an AiTM framework that intercepts the session token before it reaches the user’s browser.

Each stage serves a purpose. The CAPTCHA gates block automated analysis. The multi-step flow creates perceived legitimacy through friction. The real Microsoft sign-in page bypasses user suspicion because it IS the real Microsoft sign-in page. And the AiTM proxy captures a fully authenticated session token, bypassing standard MFA entirely.

The sophistication is in the social engineering and delivery chain. The authentication abuse at the end is a pattern that has appeared in dozens of campaigns. Tycoon2FA, Evilginx2, Modlishka, and a growing list of PhaaS kits all use the same fundamental AiTM mechanic. When you detect the behavior, you detect all of them.

The Detection Opportunity Map

Microsoft’s published detections cover the email delivery layer and the identity anomaly layer well. The gaps worth filling with Sigma are:

The token replay window – the period immediately after a stolen session token is used to authenticate from an attacker IP. The authentication succeeds, so no MFA failure fires. But the geolocation, ASN, and device fingerprint are all wrong.

The post-authentication cloud activity burst – attackers who steal tokens move fast. They enumerate mailboxes, set forwarding rules, search for financial content, and establish persistence within minutes. That burst pattern is detectable even if the initial authentication looks clean.

The PDF-to-external-domain redirect chain – a PDF attachment that contains a link redirecting to a domain registered within the last 30 days, followed by a CAPTCHA redirect, followed by a Microsoft authentication URL, is a detectable sequence in proxy logs.

The inbox rule persistence play – after token theft, setting a server-side inbox rule to silently forward mail or delete security notifications is one of the most consistent post-compromise behaviors across all AiTM campaigns.

Let us build rules for each.

Sigma Rule Suite: aitm-phishing-behavioral-suite

All five rules carry the tag aitm-phishing-behavioral-suite. Correlate across the suite: two or more rules firing on the same user within 30 minutes is a confirmed AiTM session hijack until proven otherwise.

Rule 1: IOC Coverage – Campaign Domains, Sender Addresses, and PDF Hashes

We start at the bottom of the pyramid because we always start at the bottom of the pyramid. These indicators will age out as the campaign rotates infrastructure, but they may catch reused sender domains, the same PDF repurposed in a follow-on wave, or a lazy attacker who did not bother spinning up fresh infrastructure.

The .de domains used in this campaign – acceptable-use-policy-calendly[.]de and compliance-protectionoutlook[.]de – follow a naming pattern worth flagging even beyond the specific domains: legitimate subdomain names appended to .de registrations designed to look like .com alternatives. That structural pattern is worth a broader rule, which we will cover in Rule 3.

title: AiTM Code of Conduct Campaign Known IOC Match
id: a1c3e5f7-9b2d-4e8a-b0c2-4d6f8a0c2e4f
status: stable
description: >
  Matches known indicators from the April 2026 multi-stage code of conduct
  AiTM phishing campaign documented by Microsoft Defender Research. Covers
  sender domains, sender email addresses, landing page domains, and PDF
  attachment hashes. IOC indicators will rotate; use this rule alongside
  behavioral rules in the aitm-phishing-behavioral-suite for durable coverage.  
references:
  - https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/
  - https://attack.mitre.org/techniques/T1566/001/
author: Cyber Mixology
date: 2026-05-11
tags:
  - attack.initial_access
  - attack.t1566.001
  - aitm-phishing-behavioral-suite
logsource:
  category: proxy
  product: any
detection:
  selection_domains:
    cs-host|endswith:
      - "compliance-protectionoutlook.de"
      - "acceptable-use-policy-calendly.de"
      - "cocinternal.com"
      - "gadellinet.com"
      - "harteprn.com"
      - "businesshellosign.de"
  selection_senders:
    cs-uri|contains:
      - "[email protected]"
      - "[email protected]"
      - "[email protected]"
      - "[email protected]"
      - "[email protected]"
  selection_hashes:
    Hashes|contains:
      - "5DB1ECBBB2C90C51D81BDA138D4300B90EA5EB2885CCE1BD921D692214AECBC6"
      - "B5A3346082AC566B4494E6175F1CD9873B64ABE6C902DB49BD4E8088876C9EAD"
      - "11420D6D693BF8B19195E6B98FEDD03B9BCBC770B6988BC64CB788BFABE1A49D"
  condition: selection_domains or selection_senders or selection_hashes
falsepositives:
  - None expected for these specific indicators.
level: critical

Rule 2: Successful Authentication Followed by Impossible Travel or ASN Mismatch Within 10 Minutes

Technique: T1539 – Steal Web Session Cookie | T1078 – Valid Accounts

This is the core AiTM detection. The attacker steals a session token from a proxied authentication flow and immediately replays it from their own infrastructure. The user just authenticated from their home IP in Dallas. Within minutes, the same account is active from an ASN belonging to a bulletproof hosting provider in Eastern Europe.

The token is valid. The MFA was satisfied. The authentication logs show a clean success. But the context is wrong. This rule targets that contradiction – a successful authentication event where the source IP or ASN has never been seen for this account, occurring within a short window of the prior legitimate authentication.

This rule targets Entra ID (Azure AD) sign-in logs.

title: Successful Entra ID Authentication from Novel ASN Within Short Window of Prior Auth
id: 3e5a7c9f-1b4d-4e8c-9f1b-5d7a9c1e3f5a
status: experimental
description: >
  Detects a successful Entra ID authentication from a network ASN with no
  prior sign-in history for the account, occurring within 10 minutes of a
  previous successful authentication from a known IP. This pattern is
  consistent with AiTM token replay, where an attacker uses a proxied
  authentication flow to capture a valid session token and immediately
  replays it from attacker-controlled infrastructure. Standard MFA will
  appear satisfied because the AiTM proxy handled it.  
references:
  - https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/
  - https://attack.mitre.org/techniques/T1539/
  - https://attack.mitre.org/techniques/T1078/
author: Cyber Mixology
date: 2026-05-11
tags:
  - attack.credential_access
  - attack.t1539
  - attack.t1078
  - aitm-phishing-behavioral-suite
logsource:
  product: azure_ad
  category: signin
detection:
  selection_success:
    ResultType: "0"
    AuthenticationRequirement: "multiFactorAuthentication"
  filter_known_ips:
    # This filter requires a lookup against known IP baseline per user
    # Implement as a watchlist or enrichment step in your SIEM
    NetworkLocationDetails|contains: "trustedNamedLocation"
  selection_novel_asn:
    RiskLevelDuringSignIn:
      - "medium"
      - "high"
    TokenIssuerType: "AzureAD"
  timeframe: 10m
  condition: selection_success and not filter_known_ips and selection_novel_asn
falsepositives:
  - Users traveling and authenticating from hotel or airport networks
  - VPN users whose exit node changes between sessions
  - First-time authentication from a new corporate location
level: high

Tuning tip: The precision of this rule depends entirely on your IP baseline enrichment. In Sentinel, build a watchlist of known user IP ranges and ASNs and join against it at query time. Without that baseline, the false positive rate will be high. With it, this becomes one of your most reliable AiTM signals. The Microsoft Entra ID Protection “Unfamiliar sign-in properties” alert covers similar ground – this rule is for SIEM platforms where you want the logic outside of Entra.

Rule 3: PDF Attachment Redirect Chain to Recently Registered Domain Followed by Authentication URL

Technique: T1566.001 – Phishing: Spearphishing Attachment | T1027.006 – HTML Smuggling

This campaign’s delivery chain has a distinctive shape in proxy logs: a PDF is opened, the user clicks a link that hits a newly registered .de domain, a CAPTCHA redirect fires, and within a few minutes the same user session is hitting a Microsoft login URL. That three-hop sequence – PDF-origin domain, CAPTCHA host, Microsoft auth endpoint – is the shape of the attack in proxy telemetry.

This rule targets the middle stage: a click to a domain that matches the structural pattern of this campaign’s infrastructure (compliance or policy-themed subdomain-style name on a country-code TLD), followed by a redirect to login.microsoft.com or login.microsoftonline.com.

title: Phishing Redirect Chain from Policy-Themed Domain to Microsoft Authentication
id: 6f8a0c2e-4b6d-4f0c-8e1f-3a5c7e9f1b3d
status: experimental
description: >
  Detects a web redirect chain where a user navigates from a policy or
  compliance-themed domain to a Microsoft authentication endpoint within
  a short session window. This pattern is consistent with AiTM phishing
  delivery chains that use compliance-lure landing pages to direct victims
  to a proxied Microsoft sign-in page. The naming pattern of landing domains
  (compliance, policy, conduct, regulatory terms combined with legitimate
  brand names on ccTLD registrations) is a consistent structural indicator
  across multiple AiTM campaigns.  
references:
  - https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/
  - https://attack.mitre.org/techniques/T1566/001/
author: Cyber Mixology
date: 2026-05-11
tags:
  - attack.initial_access
  - attack.t1566.001
  - aitm-phishing-behavioral-suite
logsource:
  category: proxy
  product: any
detection:
  selection_lure_domain:
    cs-host|contains:
      - "compliance"
      - "conduct"
      - "policy"
      - "regulatory"
      - "workforce"
      - "disciplinary"
    cs-host|endswith:
      - ".de"
      - ".xyz"
      - ".online"
      - ".site"
      - ".click"
  selection_auth_redirect:
    cs-host|endswith:
      - "login.microsoft.com"
      - "login.microsoftonline.com"
      - "login.live.com"
  timeframe: 5m
  condition: selection_lure_domain followed by selection_auth_redirect
falsepositives:
  - Legitimate compliance portals on non-standard TLDs that link to Microsoft
    SSO for authentication. Add confirmed legitimate domains to an exclusion
    list rather than weakening the keyword set.
level: medium

Tuning tip: The keyword set in selection_lure_domain will generate noise in environments with legitimate third-party compliance portals. Build an exclusion list of known-good compliance vendor domains and filter against it. The combination of policy-themed keywords AND non-standard ccTLD registrations is the tighter signal – the .de/.xyz/.online suffix is doing real work here for a US-targeted campaign.

Rule 4: Inbox Rule Created Immediately After First Authentication from New IP

Technique: T1564.008 – Hide Artifacts: Email Hiding Rules | T1114.003 – Email Collection: Email Forwarding Rule

After stealing a session token, attackers establish persistence and situational awareness quickly. Creating server-side inbox rules is one of the most consistent post-AiTM behaviors across all campaigns. Rules that forward all mail to an external address, delete emails matching keywords like “security”, “alert”, “password”, or “MFA”, or move flagged emails to obscure folders – these are the attacker maintaining visibility while hiding their tracks from the victim.

This rule targets Office 365 unified audit logs for inbox rule creation events occurring within a short window of a first-seen-IP authentication for the same account.

title: Inbox Forwarding or Deletion Rule Created After Authentication from Novel IP
id: 9b1d3f5a-7c9e-4b1d-8f3a-5c7e9b1d3f6a
status: stable
description: >
  Detects creation of an Exchange Online inbox rule that forwards mail
  externally or deletes messages matching security-related keywords,
  occurring within a short window after a successful authentication from
  an IP address with no prior sign-in history for the account. This is
  one of the most consistent post-AiTM token theft behaviors across
  phishing campaigns and BEC operations. The rule creation establishes
  long-term mailbox access and hides security notifications from the
  victim.  
references:
  - https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/
  - https://attack.mitre.org/techniques/T1564/008/
  - https://attack.mitre.org/techniques/T1114/003/
author: Cyber Mixology
date: 2026-05-11
tags:
  - attack.persistence
  - attack.collection
  - attack.t1564.008
  - attack.t1114.003
  - aitm-phishing-behavioral-suite
logsource:
  product: m365
  service: exchange
detection:
  selection_rule_creation:
    Operation:
      - "New-InboxRule"
      - "Set-InboxRule"
  selection_forwarding:
    Parameters|contains:
      - "ForwardTo"
      - "ForwardAsAttachmentTo"
      - "RedirectTo"
  selection_deletion_keywords:
    Parameters|contains:
      - "DeleteMessage"
      - "SubjectContainsWords"
  selection_suspicious_keywords:
    Parameters|contains:
      - "security"
      - "alert"
      - "verify"
      - "password"
      - "unusual"
      - "suspicious"
      - "mfa"
      - "authenticat"
  condition: selection_rule_creation and (selection_forwarding or (selection_deletion_keywords and selection_suspicious_keywords))
falsepositives:
  - Legitimate inbox rules created by users for email organization
    (forwarding to personal accounts is legitimately uncommon in corporate
    environments and warrants verification even as a false positive)
  - IT-managed mail flow rules (these appear under different operations
    and accounts)
level: high

Tuning tip: Forwarding rules that point to external domains are almost never legitimate in corporate environments. Even if this rule fires and the user claims they set it up, that claim warrants verification. Consider treating any external forwarding rule creation as high priority regardless of whether the authentication context is anomalous.

Rule 5: Post-Authentication Cloud Enumeration Burst

Technique: T1087.003 – Account Discovery: Email Account | T1530 – Data from Cloud Storage

AiTM attackers do not browse. They enumerate. A human user logs in and reads their email. An attacker with a stolen token runs a script that pulls mailbox folder structure, searches for keywords like “invoice”, “wire”, “password”, “credentials”, and “vpn”, downloads recent attachments, and checks SharePoint document libraries – all within the first five minutes of the session.

The volume and breadth of activity per unit time is the signal. This rule targets the Microsoft 365 unified audit log for a burst of distinct cloud operations across multiple workloads from a single session within a short window.

title: Cloud Workload Enumeration Burst in M365 Session Following Authentication
id: 2d4f6a8e-0c1e-4f8a-9d2e-4f6a8c0e1f3d
status: experimental
description: >
  Detects a high volume of distinct Microsoft 365 operations across multiple
  workloads (Exchange, SharePoint, OneDrive, Teams) within a short session
  window following user authentication. This burst pattern is consistent with
  automated post-AiTM token exploitation where attackers enumerate mailbox
  content, SharePoint libraries, and Teams messages programmatically using
  a stolen session token. Legitimate user sessions show lower operation
  diversity and volume in short windows.  
references:
  - https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/
  - https://attack.mitre.org/techniques/T1087/003/
  - https://attack.mitre.org/techniques/T1530/
author: Cyber Mixology
date: 2026-05-11
tags:
  - attack.discovery
  - attack.collection
  - attack.t1087.003
  - attack.t1530
  - aitm-phishing-behavioral-suite
logsource:
  product: m365
  service: audit
detection:
  selection_operations:
    Operation:
      - "MailItemsAccessed"
      - "SearchQueryInitiatedExchange"
      - "FileDownloaded"
      - "FilePreviewed"
      - "ListItems"
      - "GetFolder"
      - "SearchQueryInitiatedSharePoint"
      - "MessageRead"
      - "ChatMessageRead"
  timeframe: 5m
  condition: selection_operations | count() by UserId > 40
falsepositives:
  - Automated email management tools or archiving solutions operating
    under user credentials
  - Power Automate flows that process mail or files in bulk
  - Migration tooling operating under individual user tokens
level: medium

Tuning tip: The threshold of 40 distinct operations in 5 minutes is a starting point. Measure your environment’s baseline for legitimate power users – someone running a large file sync or an email migration will exceed this. The key enrichment is pairing this rule with Rule 2: a burst that follows a novel-IP authentication is a confirmed incident. A burst from a known IP may be a power user or an automation. Context changes everything here.

Thinking in Suites: What the Correlation Tells You

Each rule above catches a piece of the attack chain. But look at what the suite covers end to end:

Rule 1 catches the delivery infrastructure if it matches known IOCs. Rule 3 catches the redirect chain shape even on fresh domains. Rule 2 catches the token replay moment – the authentication that should not have succeeded. Rule 4 catches the persistence play – the inbox rule that survives token revocation. Rule 5 catches the collection phase – the automated trawl through the compromised mailbox.

An attacker who triggers two or more of these rules on the same account within 30 minutes has moved through at least half of a confirmed AiTM post-compromise sequence. Build that correlation. When it fires, the response is not “investigate” – the response is “revoke all sessions, reset credentials, and audit inbox rules and OAuth app grants immediately.”

One rule firing is a signal worth checking. Two rules firing on the same user is a case.

The Bigger Picture: AiTM Is the New Normal

Standard MFA stopped traditional password spray. Attackers responded with AiTM proxy kits that make MFA irrelevant by intercepting the authenticated session token rather than the password. Phishing-as-a-Service platforms have made AiTM accessible to operators with no technical depth. This campaign, with its polished HTML templates, multi-stage CAPTCHA gating, and platform-specific redirect logic, represents the high end of what those platforms now deliver.

The defenses that work against AiTM are phishing-resistant MFA – FIDO2 hardware keys and Windows Hello bind authentication to the physical device, making token replay impossible. But phishing-resistant MFA is not universally deployed, and migration takes time. In the meantime, behavioral detection is the practical layer that catches what platform MFA controls cannot.

The lure will change. The PDF filename will rotate. The landing domain will be fresh next week. The authentication abuse pattern, the inbox rule, the cloud enumeration burst – these are slower to change because they are structural to how AiTM attacks work, not cosmetic choices the attacker can swap overnight.

Build for the behavior. Write the IOC rules. Ship both.

Full technical analysis of this campaign, including email template screenshots, CAPTCHA flow documentation, and all published indicators of compromise, is available in Microsoft’s original research. The Microsoft Security Blog link is in the references for each rule above.