Secure Scroll

Your password is the lock on the front door. MFA is the deadbolt. But once you’re authenticated, the server hands you a wristband — a session token — that says “this person already proved who they are.” Session hijacking doesn’t pick the lock or break the deadbolt. It clones the wristband. And in 2026, threat actors are cloning millions of them every month.

In early 2026, Microsoft’s Detection and Response Team (DART) documented a campaign by a financially motivated group tracked as **Storm-2755**. The group wasn’t deploying ransomware. They weren’t exploiting zero-days. They were doing something far simpler and far more devastating: they were waiting for their victims to log in correctly — MFA and all — and then silently stealing the authenticated session from underneath them.Paychecks from Canadian employees across multiple industries were quietly redirected to attacker-controlled bank accounts. The victims didn’t lose their passwords. They did everything right. They still lost.
In this article we are going to break down exactly how this attack worked , Mapped to MITRE ATT&CK framework and Walkthrough exact detection logic.

SIMPLE EXPLANATION:

The Attack Lifecycle: Storm-2755 Mapped to MITRE ATT&CK

Phase 1: The Trap (Rigged Google Searches)

Instead of sending spam emails, the attackers poisoned Google search results. When employees searched for “Office 365 login,” they were tricked into clicking a fake—but identical-looking—Microsoft login page that the attackers controlled.

• MITRE ATT&CK: Initial Access (TA0001) | Phishing (T1566)

Phase 2: The Theft (Stealing the Digital Key)

The fake website acted as a silent middleman. When the employee entered their password and approved their MFA prompt on their phone, the middleman passed that info to the real Microsoft server. Microsoft approved the login and sent back a “session cookie” (a digital key that keeps you logged in). The attacker secretly copied this key for themselves, bypassing MFA entirely.

• MITRE ATT&CK: Credential Access (TA0006) | Adversary-in-the-Middle (T1557) | Steal Web Session Cookie (T1539)

Phase 3: Staying Hidden (Keeping the Door Open)

Digital keys usually expire after a certain amount of time. To stop this from happening, the attackers used an automated script to silently ping Microsoft every 30 minutes. This kept their stolen session alive and active without ever triggering a new MFA prompt or security alarm.

• MITRE ATT&CK: Defense Evasion (TA0005) | Use Alternate Authentication Material: Web Session Cookie (T1550.004)

Phase 4: The Heist (Stealing the Paycheck)

Once they had full, silent access to the victim’s account, the attackers searched the inbox for payroll information. They emailed HR to change the victim’s direct deposit details to their own bank account. To cover their tracks, they set up hidden email rules to instantly delete any confirmation messages from HR, ensuring the victim never realized their paycheck was stolen.

• MITRE ATT&CK: Collection (TA0009) & Impact (TA0040) | Email Collection (T1114.002) & Financial Theft (T1657)

The SOC Playbook for AiTM Session Hijacking

This guide breaks down how a Security Operations Center (SOC) identifies, investigates, and neutralizes a stolen session token across three operational tiers.

Tier 1: Alert Triage & Escalation The entry-level analyst’s job is to spot the initial surface anomalies. Stolen tokens often trigger two main alerts:

• Impossible Travel: A single session logging in from two geographically distant locations within minutes.
• Suspicious User-Agents: A successful login using a programmatic HTTP client (like Axios/1.7.9) instead of a standard web browser.
• Action: The analyst verifies the source IP and user-agent in the last 24 hours of sign-in logs and escalates the session ID to Tier-2.

Tier 2: Behavioral Corroboration & Containment The mid-level analyst takes the escalation and uses SIEM queries (like KQL or Splunk) to confirm the token replay.

• The Goal: Prove that the exact same SessionId was used by two different IP addresses, specifically where one IP is utilizing a headless HTTP client.
• Action: Once confirmed, the analyst revokes the user’s refresh tokens, temporarily disables the account to freeze the session, and escalates to Tier-3 for deep forensics.

In Microsoft Sentinel (KQL):
```kql
// Detect session token reuse from two geographically distinct IPs
let SuspectSession = SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0  // Successful sign-in
| where UserAgent contains "axios" or UserAgent contains "python-requests"
| project SessionId, UserPrincipalName, IPAddress, UserAgent, TimeGenerated;
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| join kind=inner SuspectSession on SessionId
| where IPAddress != IPAddress1
| project
    TimeGenerated,
    UserPrincipalName,
    LegitIP = IPAddress1,
    SuspectIP = IPAddress,
    UserAgent,
    SessionId
| order by TimeGenerated desc
```

Tier 3: Proactive Hunting & Incident Response The senior threat hunter does not wait for alerts. They actively scan the identity data lake for pre-compromise and post-compromise fingerprints, and lead the counter-attack if a breach occurs.

• Pre-Compromise Hunting: Searching for the 50199 interrupt error (a known AiTM proxy fingerprint) immediately followed by a successful login from a new IP.
• Post-Compromise Hunting: Looking for suspicious inbox rule creations (used to hide HR/payroll emails) immediately following an anomalous login.
• The Counter-Attack: If the token was actively used to steal data, Tier-3 executes a full remediation pipeline: hard-disabling the account in Entra ID to kill the live session, auditing all accessed resources for exfiltration, checking internal emails for lateral phishing, and enforcing strict Conditional Access policies before re-enabling the user.

Sigma Rule — AiTM Token Replay via Non-Interactive Sign-In:
YAML
title: AiTM Session Hijacking - Axios Token Replay via Non-Interactive Sign-In
id: f3b4a2e5-7c91-4d8e-9b2f-1a3c5e7d9f2b
status: stable
description: >
  Detects non-interactive sign-ins to Microsoft 365 services using the Axios
  HTTP client user-agent, a behavior pattern consistent with AiTM session
  hijacking toolkits including those observed in the Storm-2755 campaign.
author: Secure Scroll
tags:
    - attack.credential_access
    - attack.defense_evasion
    - attack.t1539
    - attack.t1550.004
    - attack.t1557
logsource:
    product: azure
    service: signinlogs
detection:
    selection:
        ResultType: 0
        IsInteractive: false
        UserAgent|contains:
            - 'axios'
            - 'python-requests'
            - 'go-http-client'
    filter_legitimate:
        AppDisplayName|contains:
            - 'Microsoft'
            - 'Azure'
    condition: selection and not filter_legitimate
falsepositives:
    - Legitimate automation scripts using Axios or similar HTTP libraries
      for non-interactive service-to-service authentication. Validate against
      your known automation inventory before closing.
level: high
```
---

 The Takeaway: MFA Is Not the Finish Line

The Storm-2755 campaign is a stark operational reminder that the authentication event and the session are two different attack surfaces. Most enterprise security architecture is built around protecting the login. Almost none of it is built to monitor what happens to the token after the login succeeds.

The session is the new credential. When you design your detection coverage, your MITRE heat map should have no red boxes in **T1539 (Steal Web Session Cookie)** or **T1550.004 (Use Alternate Authentication Material)**. If it does, your SOC has a blind spot that financially motivated threat actors are actively mapping in 2026.

Harden your identity, monitor your sessions, and keep hunting.

**Legal & Operational Disclaimer**

Educational Purposes Only: The technical configurations, detection rules, and threat actor analysis in this article are provided strictly for educational and informational purposes.

Threat Actor References: The Storm-2755 campaign details referenced in this article are drawn from publicly available research published by Microsoft DART. Network indicators and malicious infrastructure references are for analytical context only. Do not interact with or probe any infrastructure associated with threat actor activity.