> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Phishing kits bypass MFA via token theft and AitM attacks targeting Microsoft 365 - URL: https://f4n6.co.uk/security-feed/phishing-kits-bypass-mfa-via-token-theft-and-aitm-attacks-targeting-microsoft-365/ - Published: 2026-10-22T16:33:27.000Z - Updated: 2026-10-22T16:33:27.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary Huntress has published an analysis of three phishing kits that target Microsoft 365 session tokens rather than passwords, using device-code phishing, adversary-in-the-middle (AitM) relay and token replay. The kits named are EvilTokens, whose alleged operator was arrested in a joint Microsoft Digital Crimes Unit and FBI action, and Kali365, a phishing-as-a-service platform the FBI has warned about. Microsoft attributes EvilTokens to the actor it tracks as Storm-2992 and reports more than 12,000 compromised inboxes across over 10,000 organisations, with financial services among the affected sectors and the United Kingdom and France among the countries with the highest observed victim activity. No CVE is associated with this item and no CISA KEV entry applies; the exposure is to identity compromise through a legitimate authentication flow, not to an unpatched software flaw. For EMEA financial services the risk is account takeover that survives password resets and MFA prompts, because the attacker holds a valid refresh token. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 17 | The kits give an attacker a usable authenticated session and mailbox access, so an incident here is an ICT-related incident that must be handled through a defined management process, including token revocation and device removal, not just mailbox cleanup. | The incident response process must cover identity artefacts (refresh tokens, registered devices, Windows Hello credentials, inbox rules) as first-class containment targets. | | DORA Art. 19 | Microsoft reports more than 12,000 compromised inboxes across over 10,000 organisations, and financial services is a named affected sector, so a client compromise may meet the major-incident reporting threshold. | A confirmed token compromise with mailbox access needs a reporting decision on the DORA timeline; the evidence to support it (sign-in logs, token issuance, device registration) must be preserved from the outset. | | NIS2 Art. 21(2)(d) | The delivery path runs through email and third-party cloud identity (Microsoft 365, and EvilTokens abused the Railway PaaS for token harvesting and replay), which is a supply chain and third-party exposure. | Supply chain security measures must extend to identity provider configuration (device-code flow, Conditional Access) and to cloud service dependencies, not only to on-premises vendors. | ## 3\. Technical analysis & attack chain The kits in this item do not steal passwords. They obtain a valid Microsoft 365 session and reuse it. Three techniques are described: device-code phishing, AitM relay, and token theft and replay. A kit can deliver any of the three, and Kali365 is described as combining device-code and AitM methods with AI-assisted lure generation. Confirmed steps in a device-code phishing flow, as described by Malwarebytes and Microsoft: 1. The victim receives a message styled as a cloud or collaboration notification (a document-sharing notice or a Teams invite) carrying a short device code and an instruction to enter it on Microsoft's verification page. 2. The victim goes to a genuine Microsoft device sign-in URL, not a lookalike page, and enters the code. 3. The victim completes the standard Microsoft sign-in and consent screens, possibly seeing their own organisation's branding. 4. The attacker's device receives OAuth access and refresh tokens tied to the victim's account. 5. The attacker uses the refresh token to reach Outlook, OneDrive, Teams and other Microsoft services without a password, and keeps access until the token is revoked or expires. The device-code flow is a legitimate OAuth mechanism for devices with limited interfaces (smart TVs, printers, Teams and conferencing devices). Its design, where authentication completes on a separate device from the one requesting access, is what the kits abuse. Microsoft's guidance is that most Microsoft environments do not need device code flow, and Conditional Access policies can block it. AitM relay works differently. The attacker relays the authentication exchange in real time, either through a fake login page or by intercepting an exchange inside the legitimate app. The victim completes the MFA prompt, and the attacker captures the resulting session. A completed MFA prompt therefore does not make the session trustworthy on its own. Post-compromise, Microsoft reports that EvilTokens operators used AI assistants to read victim mailbox activity and craft follow-on phishing from the accessible content, and ran Microsoft Graph reconnaissance to map organisational structure and permissions. Persistence was maintained through malicious inbox rules that conceal communications and, in some cases, by granting new devices access to the victim's inbox. EvilTokens delivered lures through 44 themes including invoices, requests for proposals and shared files, using malicious URLs, PDF attachments and HTML files. Microsoft's Digital Crimes Unit coordinated a disruption of EvilTokens infrastructure, and Huntress reports the arrest of one alleged operator; EvilTokens had abused the Railway platform-as-a-service as its token-harvesting and token-replay engine. Kali365 is described as a full criminal ecosystem in a box with a control panel and AI features, covering infrastructure acquisition, collection of authentication material, retention of access and scaling. The FBI has issued a public service announcement about it. Huntress reports that an estimated one in six incidents its ITDR team investigated involved a rogue device being registered. Attribution and confidence. Microsoft tracks the actor behind EvilTokens development and support as Storm-2992\. No MITRE ATT&CK profile for Storm-2992 is available in the data supplied with this item, so that attribution is unconfirmed here and should be treated as Microsoft's designation only. The arrest of an alleged EvilTokens operator is reported by Huntress and rests on the Microsoft Digital Crimes Unit and FBI action it describes; the specific charges and the individual's identity are not in the source material. The Kali365 capability description rests on Malwarebytes, BleepingComputer and The Hacker News reporting plus the FBI warning; the technical detail is consistent across them but the kit's internals are not documented in these sources. The one-in-six device-registration figure is a single Huntress estimate from its own incident data and should not be generalised. ## 4\. Mitigation & containment P1 within 24 hours - Block device-code authentication where the business does not need it. In Microsoft Entra, apply a Conditional Access policy that blocks the device code flow authentication type for all users except a named break-glass or device group. Microsoft's position, quoted by Huntress, is that the vast majority of Microsoft environments do not need device code flow. - For any suspected token compromise, revoke refresh tokens for the affected account and remove unauthorised devices and Windows Hello credentials. Containment that only removes the phishing email or blocks the lure domain leaves the attacker's session live. - Review inbox rules, mail forwarding and delegate access on the affected mailbox, and check for new device registrations and new authentication methods added to the account. - Hunt for successful sign-ins from unfamiliar cloud infrastructure and for automated token refresh patterns, correlating identity provider, endpoint, browser, network and mailbox telemetry. Huntress's point is that one signal is weak and the sequence is strong. P2 within 72 hours - Restrict or disable legacy and device-code authentication paths tenant-wide and require compliant, registered devices for token issuance where the licence tier allows it. - Review Microsoft Graph permissions granted to applications in the tenant and remove consent for any app the identity team cannot account for, given the Graph reconnaissance Microsoft observed in EvilTokens intrusions. - Add mail flow rules and spoof protections for inbound mail that carries device-code instructions or links to Microsoft device sign-in pages, and review third-party connector configuration for spoofed senders as Microsoft's guidance sets out. - Continue hunting after the original phishing domain is taken down. The kits are hosted infrastructure that disappears; the stolen token does not. P3 within 7 days - Run an exercise against the response loop Huntress describes: detect correlated identity and endpoint activity, revoke persistence, investigate downstream mailbox and outbound-phishing activity, and keep monitoring for replay or re-entry after containment. - Brief service desk and finance staff that a genuine Microsoft sign-in page and a completed MFA prompt are not proof of legitimacy when a short code was supplied by someone else. Device-code lures arrive as document-sharing or Teams notifications. ## 5\. Indicators of compromise No atomic indicators (hashes, domains, IP addresses, file paths) are present in the source material. The sources describe behaviours and authentication patterns rather than machine-pivotable artefacts. Behavioural indicators | behaviour | where to observe | confidence | | ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | Device-code authentication followed by token issuance to an unmanaged device | Entra sign-in logs, authentication method and device registration logs | High (described by Microsoft and Malwarebytes) | | Successful sign-in from unfamiliar cloud infrastructure shortly after a document-sharing or Teams lure | Identity provider sign-in logs, correlated with mail gateway logs | High | | Automated token refresh from a device not previously seen for the account | Entra sign-in logs, token refresh events | Medium | | New device registration or new authentication method added to an account | Entra device and authentication method logs | High (Huntress reports one in six ITDR incidents involved a rogue device; single-sourced estimate) | | Malicious inbox rule created to conceal communications | Exchange Online mailbox audit logs | High (Microsoft) | | Microsoft Graph reconnaissance mapping organisational structure and permissions | Graph audit and API logs | Medium (Microsoft, EvilTokens-specific) | | Outbound phishing sent from a compromised mailbox using content read from that mailbox | Exchange Online message trace, mailbox audit logs | High | ## 6\. Detection The sources give behavioural and log indicators but no file artefacts, distinctive strings, command lines, mutexes or registry keys from the kits themselves. A YARA rule built on kit or actor names would detect reporting about the threat, not the threat, so none is emitted. The Sigma rule below targets the device-code sign-in pattern in Entra sign-in logs; the field names are the standard Entra sign-in schema and should be validated against the client's log pipeline before deployment. ```yaml title: Microsoft 365 Device Code Authentication Sign-In id: 8f2c1a44-6b7e-4d21-9c3a-5e0b7a1d2f90 status: experimental description: Detects successful interactive sign-ins completed through the OAuth device code flow, the mechanism abused by EvilTokens, Kali365 and similar Microsoft 365 token-phishing kits. author: Adverse Trace date: 2026-10-22 references: - https://www.huntress.com/blog/unboxing-phishing-kits - https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/ logsource: product: azure service: signinlogs detection: selection_flow: AuthenticationProtocol: 'deviceCode' selection_result: ResultType: '0' condition: selection_flow and selection_result falsepositives: - Legitimate sign-in from smart TVs, printers, Teams rooms and conferencing devices where device code flow is genuinely required level: medium ``` ## 7\. Sources - Huntress, "Unboxing Phishing Kits: Huntress Examines 3 Real Kits", https://www.huntress.com/blog/unboxing-phishing-kits, 2026-10-22. - Malwarebytes Labs, "Kali365 phishing kit bypasses MFA and steals Microsoft logins", https://www.malwarebytes.com/blog/scams/2026/05/kali365-phishing-kit-bypasses-mfa-and-steals-microsoft-logins, May 2026. - BleepingComputer, "FBI warns of Kali365 phishing service targeting Microsoft 365 accounts", https://www.bleepingcomputer.com/news/security/fbi-warns-of-kali365-phishing-service-targeting-microsoft-365-accounts/. - Microsoft Threat Intelligence, "Unmasking EvilTokens: Getting to the root of device code phishing", https://www.microsoft.com/en-us/security/blog/2026/09/22/unmasking-eviltokens-getting-to-the-root-of-device-code-phishing/, 2026-09-22. - 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/. - The Hacker News, "Kali365 Weaponizes Microsoft Authentication Against US Companies: New Enterprise Risk", https://thehackernews.com/2026/08/kali365-weaponizes-microsoft.html, August 2026. - The Hacker News, "Police Dismantle Kratos Phishing Kit Built to Steal Microsoft 365 Sessions and Bypass MFA", https://thehackernews.com/2026/07/police-dismantle-kratos-phishing-kit.html, July 2026. ## 8\. Adverse Trace position No CVE is associated with this item and no CISA KEV entry applies, so there is no patch deadline to set; the severity here is operational, driven by the fact that a successful device-code or AitM phishing attempt yields a valid refresh token that survives password reset and MFA. Microsoft's figure of more than 12,000 compromised inboxes across over 10,000 organisations, with financial services named among affected sectors and the UK and France among the highest-activity countries, puts EMEA financial services directly in scope. The Storm-2992 attribution is Microsoft's and is unconfirmed here because no MITRE ATT&CK profile for that actor is available to us; the arrest of an alleged EvilTokens operator is reported by Huntress and the specific charges are not in our sources. We assess the device-code technique as the higher priority for most clients because it needs no fake page and no password, and because the fix (blocking device code flow in Conditional Access) is a configuration change most tenants can make quickly. We will monitor for further reporting on Kali365 and Forg365 kit internals and for any atomic indicators, and we will update this advisory if either becomes available. Clients who want the device-code Conditional Access policy reviewed against their tenant configuration should contact their Adverse Trace account lead. --- [Read the original source →](https://www.huntress.com/blog/unboxing-phishing-kits?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*