~/f4n6 $ grep -r "AiTM token spray campaign bypasses MFA to compromise M365 accounts via 1337 Services IPs" ./investigations/ --include="*.md"

AiTM token spray campaign bypasses MFA to compromise M365 accounts via 1337 Services IPs

Jeff Davies 22 Oct 2026 11 min read

1. Executive summary

Between 14 July and 22 September 2026, Huntress recorded 497 successful Microsoft 365 sign-ins across 79 victim organisations in which the attacker replayed session tokens stolen through adversary-in-the-middle (AiTM) relays, device-code phishing and social engineering, without ever holding a password. The replay hosts sat in a single /24 at German hosting provider 1337 Services GmbH (AS210558), 193.26.115[.]0/24, and the operator rotated through six addresses in four phases; more than 200,000 failed sign-ins were traced to the same range. Post-compromise the actor registered 48 rogue Entra-joined devices, wiped and replaced MFA methods in 19 organisations, and planted hidden inbox rules keyed on payroll and banking terms, in one case using a compromised mailbox to send a payroll-related email to an external contact. No CVE is associated with this item and no CISA KEV entry applies; the exposure is configuration and identity-control, not a patchable flaw. For EMEA financial services the risk concentrates in business email compromise against finance and treasury workflows, and in the persistence that survives a password reset because the rogue authenticator and device remain on the account.

2. Regulatory framing

Article Trigger (the fact in this item) Practical impact
DORA Art. 17 Token replay gave the actor access to M365 mailboxes and the actor planted inbox rules to hide payroll and banking correspondence, an ICT-related incident affecting production email services The incident management process must cover detection, containment and eradication of the rogue MFA method and device, not just the mailbox; a password reset alone does not close it
DORA Art. 19 79 organisations had accounts compromised over ten weeks, and the actor sent payroll-related email from at least one compromised mailbox Where the incident meets the major-incident classification, reporting to the competent authority is engaged; the payroll-fraud email is the fact that drives the assessment
NIS2 Art. 23 Same compromise of M365 accounts used for financial workflows across many entities Essential and important entities must run the incident notification process on the same facts; the ten-week dwell and hidden rules affect the timeline reported

3. Technical analysis & attack chain

The campaign ran in four phases across six replay addresses, with the capture infrastructure and the replay infrastructure deliberately separated across different hosting providers. Huntress states it cannot say with certainty why the operator rotated addresses; the effect was that a block or Conditional Access rule written for one address did nothing against the next, and Microsoft's own threat-actor IP detections named individual addresses ([.]221, [.]72, [.]16, [.]21), not the range.

Confirmed sequence, from the 21 July timeline and the phase descriptions:

  1. The victim is directed to a fake sign-in page fronted by an AiTM relay. On 21 July the relay at 185.238.2[.]195 caught the victim at the MFA prompt at 17:18:20 UTC.
  2. The relay passes Microsoft's real login page and MFA prompt through to the victim and keeps the post-MFA session token once the victim completes sign-in.
  3. Within minutes the stolen session is replayed from a 1337 Services address. On 21 July the hijacked session appeared from 193.26.115[.]199 at 17:30:21, 12 minutes after the MFA prompt; on 22 September the gap was four minutes.
  4. The same session was then used from a second 1337 Services address, 124.198.132[.]33, at 17:43:15.
  5. At 18:08:50 a new authenticator app labelled "iPhone 13" was activated on the account, giving the actor an MFA method that outlives the stolen token.
  6. The actor registered a rogue Entra-joined device named DESKTOP- plus eight uppercase hex characters (for example DESKTOP-54521F46, DESKTOP-BAF88EF4, DESKTOP-CA85907C), then often pivoted to an ExpressVPN or CrownCloud address for further activity.
  7. Hidden inbox rules were created from VPN or rented hosting addresses (ExpressVPN, NordVPN, CrownCloud, DataWagon, GLOBALTELEHOST, LeaseWeb, Dynu, Interserver), never from the 1337 range, to move or delete mail matching business terms.

Two toolsets ran in parallel. Build A (hosts [.]221, [.]16, [.]21, [.]72) was scripted token replay: a node user agent (bare Mozilla/5.0 on [.]21), OAuth2:Token requests, the Microsoft Office client ID d3590ed6-52b3-4102-aeff-aad2292ab01c and Microsoft Authentication Broker client ID 29d9ed98-a469-4536-ade2-f981bc1d605e, targeting Microsoft Graph (00000003-0000-0000-c000-000000000000), Exchange Online (00000002-0000-0ff1-ce00-000000000000), SharePoint Online (00000003-0000-0ff1-ce00-000000000000) and the Device Registration Service (01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9). Build B (hosts [.]199, [.]210) replayed browser sessions directly from AiTM relays using a current Chrome/Edge on Windows user agent, Login:reprocess and OAuth2:Authorize requests, and the OfficeHome client ID 4765445b-32c6-49b0-83e6-1d93765276ca.

Phase 1 (from 14 July, [.]221 and [.]199): 13 of the 14 incidents Huntress responded to on 14 July involved a rogue DESKTOP- device registered from the 1337 address. Rules named ., sss and ss marked mail as read and deleted it or moved it to RSS Feeds; one mailbox with a rule named sss was then used to send outbound spam to hundreds of external recipients before Entra ID Protection rated the account high risk. By 3 August the actor had signed in to 37 organisations and registered 37 rogue devices.

Phase 2 (from 17 August, [.]16 and [.]21): device-code phishing appeared, with sign-ins through the Microsoft Office device-code flow from [.]16 where the victim enters a code on Microsoft's legitimate sign-in page and hands over a valid refresh and access token. The same address signed in to the Device Registration Service. MFA methods were wiped through Microsoft's security-info registration service and a new authenticator registered minutes later; in one incident the actor used a deviceless authenticator method already on the account. In 19 organisations existing MFA methods were wiped and a new method registered within three hours of the first sign-in from a campaign address.

Phase 3 (11 September, [.]72): an automated node user agent completed 303 successful sign-ins across 29 organisations over four days, most targeting Microsoft Graph. The same address logged 1,052 blocked sign-ins, but every block came from just four organisations; in the 29 where it succeeded nothing stopped it. In one incident the actor modified a rule named s to catch messages mentioning payroll, direct deposit, bank or bonus, then five minutes later from 167.148.41[.]96 created rule d to mark all mail from an external CPA as read and move it to Conversation History, hiding the replies. A payroll-related email was sent to that CPA from the compromised mailbox.

Phase 4 (2 to 22 September, [.]210): an AiTM relay at Evoxt Sdn. Bhd. (2400:8d60:2::1:841d:5dd) paired with replay from [.]210. A 3 September replay of a session stolen the day before failed with SsoArtifactRevoked (AADSTS50133). The final takeover on 22 September began at 20:46 UTC from a macOS browser using OfficeHome, replayed at 20:50 from [.]210 through a Remote Desktop Protocol VDI tunnel operator, with the session OS changing from macOS to Windows before the actor accessed email. In one organisation the actor retried the same stolen session three more times in August, from [.]199, 45.83.31[.]44 and 192.159.99[.]172, each failing with AADSTS50133.

The persistence matters more than the initial access. A password reset does not remove the attacker-registered authenticator or the rogue device, and does not invalidate the access token, which Huntress gives a time to live of approximately 90 minutes. Session revocation is a separate action. Four mailboxes had rules created through the Outlook REST API rather than Outlook itself, two of them within minutes of the first sign-in from a campaign address.

Attribution is unconfirmed. Microsoft Entra ID Protection raised verified threat actor IP detections against four of the addresses, described as consistent with nation state actors or cyber crime groups based on MSTIC intelligence, but no named actor is identified in the source and no MITRE ATT&CK group profile is available for this item. A February 2025 Krebs on Security article cited by Huntress suggests 1337 Services GmbH's founder may have operated the Cracked cybercrime forum; that is a single-source, historical link to the hosting provider, not to this campaign's operator. The entire technical account rests on one vendor's telemetry (Huntress), with Microsoft's IP detections as partial corroboration; treat the phase boundaries and host-to-build mapping as single-sourced until independently confirmed.

4. Mitigation & containment

P1 within 24 hours, for any tenant with a sign-in from 193.26.115[.]0/24 or the other listed addresses:

  • Revoke sessions and reset the password for affected accounts. Do both. A password reset alone leaves the access token valid for roughly 90 minutes and leaves the rogue authenticator and device in place.
  • Audit and remove attacker-registered MFA methods. Look for methods cleared and re-registered within minutes, and for authenticators the user does not recognise (the campaign used the label "iPhone 13").
  • Audit Entra devices for names matching DESKTOP-, Device- or Work Pc plus eight hex characters, especially those registered from hosting IP addresses. Confirm before deleting; the pattern is rare but not unique to this campaign.
  • Review inbox rules for one to three-character or punctuation-only names (., sss, ss, iT, ,., ........, s, d), rules moving mail to RSS Feeds, RSS Subscriptions or Conversation History, and rules keyed on payroll, direct deposit, bank or bonus.
  • Block 193.26.115[.]0/24 at the perimeter and in Conditional Access named locations. Blocking individual addresses covers one phase at most; the operator also used a few other 1337 Services addresses outside the /24.

P2 within 72 hours:

  • Require MFA, or block, for All Users, All Cloud Apps and All Client App types unconditionally in Conditional Access. In Phase 3 the four organisations with working policy blocked all 1,052 attempts against them.
  • Restrict the device-code authentication flow with a Conditional Access authentication-flow policy. Where device code is needed, use service accounts with restricted permissions and exclusions.
  • Disable standard-user consent to new enterprise applications and route requests through an approval process; audit existing enterprise app grants for new or unexpected applications.
  • Treat AADSTS53003 (BlockedByConditionalAccess) as evidence of a valid credential, not a save. The block happens after authentication succeeds, so the credential is live and the user needs remediation.

P3 within 7 days:

  • Hunt for OAuth2:Token and Cmsi:Cmsi sign-ins from hosting infrastructure using the Microsoft Office or Authentication Broker client with a node or bare Mozilla/5.0 user agent. Expect some legitimate automation; prioritise sign-ins touching user mailboxes or the Device Registration Service.
  • Prioritise response by credential validity, not spray volume. Ranking tenants by failed attempts points at the most-sprayed, least-compromised tenants; in Phase 3 the 1,052 blocked attempts and the 232 successful ones had no overlap in organisations.
  • Review mail-flow and DLP for outbound payroll or banking changes to external parties from accounts that recently showed the sign-in patterns above.

5. Indicators of compromise

type value confidence source
ipv4 193.26.115[.]221 high Huntress
ipv4 193.26.115[.]199 high Huntress
ipv4 193.26.115[.]16 high Huntress
ipv4 193.26.115[.]21 high Huntress
ipv4 193.26.115[.]72 high Huntress
ipv4 193.26.115[.]210 high Huntress
ipv4 124.198.132[.]33 high Huntress
ipv4 45.83.31[.]44 high Huntress
ipv4 192.159.99[.]172 high Huntress
ipv4 185.238.2[.]195 high Huntress
ipv6 2400:8d60:2::1:841d:5dd high Huntress
ipv4 167.148.41[.]96 high Huntress
sha256 apns2-d8a3fedb1a3cd1287ca47c6851a49e6052ab6116b43666e674765ca892d798ce medium Huntress (attacker-registered authenticator device token, not a file hash)

The client application IDs, target resource IDs, user agents, request types and error codes in the source are legitimate Microsoft values and are not indicators on their own; they are used in the detection logic in §6. The apns2- value is an authenticator device token, not a file hash; it is reproduced verbatim because it is the only account-level artefact the source gives.

ipv4  193.26.115[.]221
ipv4  193.26.115[.]199
ipv4  193.26.115[.]16
ipv4  193.26.115[.]21
ipv4  193.26.115[.]72
ipv4  193.26.115[.]210
ipv4  124.198.132[.]33
ipv4  45.83.31[.]44
ipv4  192.159.99[.]172
ipv4  185.238.2[.]195
ipv6  2400:8d60:2::1:841d:5dd
ipv4  167.148.41[.]96
sha256  apns2-d8a3fedb1a3cd1287ca47c6851a49e6052ab6116b43666e674765ca892d798ce

Behavioural indicators:

behaviour where to observe confidence
Sign-in from an Entra-joined device named DESKTOP- plus eight uppercase hex characters Entra ID sign-in logs, device registration records high
MFA methods wiped and a new authenticator registered within minutes Entra ID audit logs, security-info registration events high
Inbox rules with one to three-character or punctuation-only names moving mail to RSS Feeds, RSS Subscriptions or Conversation History Exchange Online mailbox audit, Outlook REST API activity high
OAuth2:Token or Cmsi:Cmsi sign-ins from hosting IPs using Microsoft Office or Authentication Broker client with node or bare Mozilla/5.0 user agent Entra ID sign-in logs high
Session OS changing mid-session (macOS to Windows) via a VDI tunnel Entra ID sign-in logs, session telemetry medium
Replay attempts returning AADSTS50133 (SsoArtifactRevoked) Entra ID sign-in logs high
Rules created through the Outlook REST API rather than Outlook Exchange Online audit logs medium

6. Detection

The sources give no file artefacts, so a YARA rule is not applicable. Detection rests on Entra ID sign-in and audit telemetry.

title: M365 Token Replay from 1337 Services Hosting Range
id: 8f3c2a71-4d6e-4b9a-9c1f-2e7a5b0d6c14
status: experimental
description: Detects OAuth2 token replay and device registration from the 1337 Services GmbH replay range using Microsoft Office or Authentication Broker clients with scripted user agents, per Huntress AT-2026-10-22-1466.
author: Adverse Trace
date: 2026-10-22
references:

  - https://www.huntress.com/blog/token-replay-spray
logsource:
  product: azure
  service: signinlogs
detection:
  selection_ip:
    IPAddress|cidr:

      - '193.26.115.0/24'
      - '124.198.132.33/32'
      - '45.83.31.44/32'
      - '192.159.99.172/32'
  selection_client:
    AppId:

      - 'd3590ed6-52b3-4102-aeff-aad2292ab01c'
      - '29d9ed98-a469-4536-ade2-f981bc1d605e'
      - '4765445b-32c6-49b0-83e6-1d93765276ca'
  selection_ua:
    UserAgent|contains:

      - 'node'
      - 'Mozilla/5.0'
  selection_resource:
    ResourceId:

      - '00000003-0000-0000-c000-000000000000'
      - '00000002-0000-0ff1-ce00-000000000000'
      - '00000003-0000-0ff1-ce00-000000000000'
      - '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'
  condition: selection_ip and selection_client and selection_ua and selection_resource
falsepositives:

  - Legitimate automation using the Office client from the same hosting range (unlikely; verify before enforcement)
level: high
title: Suspicious M365 Inbox Rule Names and Destinations
id: 2b6d9e04-7a1c-4f58-b3d2-9e0c4a7f1d83
status: experimental
description: Detects hidden inbox rules with punctuation or short names moving mail to RSS or Conversation History folders, and rules keyed on payroll or banking terms, per Huntress AT-2026-10-22-1466.
author: Adverse Trace
date: 2026-10-22
references:

  - https://www.huntress.com/blog/token-replay-spray
logsource:
  product: m365
  service: exchange
detection:
  selection_rule_name:
    Operation: 'New-InboxRule'
    Parameters|contains:

      - 'Name: .'
      - 'Name: sss'
      - 'Name: ss'
      - 'Name: iT'
      - 'Name: ,.'
      - 'Name: ........'
      - 'Name: s'
      - 'Name: d'
  selection_destination:
    Parameters|contains:

      - 'RSS Feeds'
      - 'RSS Subscriptions'
      - 'Conversation History'
  selection_keywords:
    Parameters|contains:

      - 'payroll'
      - 'direct deposit'
      - 'bank'
      - 'bonus'
  condition: selection_rule_name or (selection_destination and selection_keywords)
falsepositives:

  - Users creating short-named rules or filing mail to RSS folders manually
level: medium

7. Sources

  • Huntress, "M365 Token Spray and Replay Campaign Compromises Business Email Accounts", https://www.huntress.com/blog/token-replay-spray, 2026-10-22 (primary; single source for the technical account and IOC set)
  • The Hacker News, "Microsoft 365 AitM Phishing Hijacks Accounts to Collect Payroll and Finance Emails", https://thehackernews.com/2026/08/microsoft-365-aitm-phishing-hijacks.html (context on a related AiTM campaign targeting financial workflows; not confirmed as the same operator)
  • BleepingComputer, "New Forg365 phishing platform uses AI to target Microsoft 365 accounts", https://www.bleepingcomputer.com/news/security/new-forg365-phishing-platform-uses-ai-to-target-microsoft-365-accounts/ (context on AiTM and device-code phishing tooling; no link to this campaign established)

8. Adverse Trace position

Adverse Trace assesses this as a high-impact identity compromise campaign rather than a vulnerability, and the severity sits in the persistence and the business email compromise, not the initial token theft. No CVE is associated and no CISA KEV entry applies, so there is nothing to patch; the controls that would have stopped Phase 3 are Conditional Access policies requiring MFA for all users, cloud apps and client app types, and device-code flow restriction. The technical account and the full IOC set are single-sourced to Huntress, with Microsoft's threat-actor IP detections as partial corroboration, so we treat the phase mapping and host-to-build attribution as provisional and recommend verifying any block against your own sign-in telemetry before enforcement. Attribution to a named actor is unconfirmed: Microsoft's detection language points to nation state or cyber crime infrastructure but names no group, and the Krebs link to the hosting provider's founder is historical and does not identify this operator. We will monitor for further reporting that corroborates the 193.26.115[.]0/24 range and the DESKTOP- device pattern, and will issue an update if a second source confirms the toolset or names the actor. Clients running Microsoft 365 with finance or treasury mailboxes should treat the P1 steps in §4 as immediate: revoke sessions, audit MFA methods and devices, and review inbox rules for the names and destinations listed.


Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.

Post this to LinkedIn
Formatting is converted automatically — headings, bullets, a link back & hashtags. Paste straight in.
J
Jeff Davies