EvilTokens: A phishing attack that doesn’t steal your password

1. Executive summary

EvilTokens is a phishing-as-a-service (PhaaS) kit that compromises Microsoft 365 accounts by abusing the OAuth 2.0 device authorization grant flow rather than stealing credentials or hosting fake login pages. Victims are lured to a decoy page that prompts them to enter a short device code on the legitimate microsoft.com/devicelogin portal, which authorises the attacker's session and yields OAuth access and refresh tokens tied to the victim's tenant. The kit has been advertised on Telegram channels and observed in active attacks since at least February 2026, including a March 2026 campaign that Sekoia and others documented targeting more than 340 organisations across multiple countries. For EMEA financial services firms, the bottom-line risk is account takeover and business email compromise (BEC) against high-value mailboxes (finance, treasury, HR, logistics) without any of the traditional phishing red flags (fake URL, typosquatted domain, password capture form), and with refresh-token persistence that survives until tokens are explicitly revoked.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 17 (ICT-related incident management process)	A successful EvilTokens compromise of an M365 mailbox used by a financial entity is an ICT-related incident requiring a defined response process.	Activate the entity's ICT incident management process; preserve evidence (token issuance logs, mailbox audit, sign-in logs) before remediation.
DORA Art. 18 (classification of ICT-related incidents and cyber threats)	The kit is an active cyber threat against M365-dependent financial entities; a successful takeover of a finance/treasury mailbox is a classifiable ICT-related incident.	Apply the entity's classification criteria; map the incident severity against reporting thresholds.
DORA Art. 19 (reporting of major ICT-related incidents to competent authorities)	A BEC-grade compromise of a finance/treasury mailbox, or any incident meeting the entity's "major" threshold, triggers reporting.	Report through the entity's competent-authority channel per the defined timeline and template.
DORA Art. 24 (digital operational resilience testing — general requirements)	The kit specifically defeats 2FA/MFA controls; resilience testing must cover device-code-flow abuse.	Include device-code-flow abuse scenarios in scenario-based testing; validate that conditional access and token revocation controls function as designed.
DORA Art. 28 (ICT third-party risk — general principles)	Microsoft 365 is an ICT third-party provider; EvilTokens is a third-party-platform risk.	Maintain a current register entry for M365 covering this threat class; review Microsoft's published guidance and controls.
DORA Art. 29 (preliminary assessment of ICT concentration risk)	M365 is a concentrated dependency for many EMEA financial entities; EvilTokens exploits a single shared control surface.	Confirm M365 is flagged as a concentration-risk dependency; ensure exit/contingency options are documented.
DORA Art. 30 (key contractual provisions with ICT third-party providers)	Microsoft is an ICT third-party provider; contractual notification and support obligations are engaged when a tenant is compromised.	Engage Microsoft via the contractual incident-support channel; preserve audit logs and sign-in telemetry before any tenant-wide changes.
NIS2 Art. 21(2)(d) (supply chain security measures)	EvilTokens is a supply-chain threat delivered via the M365 platform used by in-scope entities.	Assess vendor-side mitigations (device-code controls, conditional access) as part of supply-chain security measures.
NIS2 Art. 23 (incident reporting obligations)	A successful EvilTokens compromise of an in-scope entity's M365 environment may meet incident-reporting thresholds.	Apply the entity's NIS2 incident-reporting workflow; align with DORA reporting where both regimes apply.
UK NIS 2018 (OES/RDSP duties)	An OES/RDSP running M365 may be compromised via this technique.	Apply the OES/RDSP incident-handling duties under UK NIS 2018.

3. Technical analysis & attack chain

Reconnaissance (T-10 to T-15 days). Attackers verify the target M365 account is active ahead of the phishing attempt. Microsoft has observed this pre-attack reconnaissance running 10–15 days before the lure is sent.
Lure delivery. The victim receives an email or message themed as an invoice, shared document, calendar invite, or SharePoint access request. The lure sits on a decoy page impersonating a trusted brand or service and uses simple wording such as "Verify to view" or "Signature required."
Device-code request. Click-through causes the decoy page to request a device code from Microsoft on the attacker's behalf. The returned code is valid for 15 minutes, which is why timing matters operationally.
Victim authorisation on the real Microsoft portal. The decoy page displays the code and instructs the victim to visit the legitimate microsoft.com/devicelogin portal and enter it. The victim completes the standard Microsoft sign-in and consent flow (including any 2FA challenge) on a real Microsoft page, often with their own organisation's branding visible.
Token issuance to the attacker. Because the code belongs to the attacker's session, Microsoft issues OAuth access and refresh tokens to the attacker's device/session, not the victim's.
Account takeover and persistence. The attacker uses the tokens to access Outlook, OneDrive, Teams, SharePoint, and other M365 resources. Refresh tokens provide long-lived access until explicitly revoked or expired, blending with normal account activity.
Impact actions. Observed outcomes include mailbox read/exfiltration, internal mail-send abuse for further compromise (BEC, lateral phishing), and targeting of finance, HR, logistics, and sales accounts.

Technical specifics that matter to a defender

Legitimate URL abused: microsoft.com/devicelogin (the real Microsoft device-login portal). Defenders should not block this URL; instead they must detect anomalous use.
OAuth 2.0 grant type abused: Device authorization grant (RFC 8628). Tokens issued are standard M365 OAuth access + refresh tokens.
Code lifetime: 15 minutes — drives the operational tempo of the attack.
Recon window: 10–15 days of pre-attack account activity checks.
Lure themes: invoice, shared document, calendar invite, SharePoint access request; copy patterns include "Verify to view" and "Signature required".
Targeted roles: finance, treasury, HR, logistics, sales — i.e. accounts that enable BEC and payment fraud.
Persistence mechanism: OAuth refresh tokens. Revocation requires explicit token revocation or app consent removal; password reset alone does not invalidate them.
Distribution: advertised on Telegram channels; AI-enabled variants with dynamic device-code generation and bespoke lures have been documented by Microsoft.

Unconfirmed / single-sourced claims. The reporting attributes the kit to criminal actors operating via Telegram-based PhaaS distribution; no named actor profile is available in our reference data, so attribution to any specific threat group is unconfirmed. The relationship between EvilTokens and the separately reported "Kali365" PhaaS platform (corpus-1) is not established by the source material; treat any cross-attribution as unconfirmed.

4. Mitigation & containment

P1 — within 24 hours

Audit M365 for suspicious device-code activity. Review Entra ID (Azure AD) sign-in logs and device code redemption events for the last 30 days; flag any redemption where the user-agent, IP, or location does not match the user's normal pattern.
Revoke active sessions and tokens for any impacted user. In Entra ID: disable the user account, revoke all refresh tokens, and revoke all OAuth consents for any app the user may have authorised during the window. A password reset alone is not sufficient — refresh tokens survive password changes.
Block the device-code flow where business operations allow. In Entra ID tenant settings, disable the "Allow users to request device code flow" / device code sign-in setting for users or groups that do not legitimately need it (e.g. smart-TV/IoT scenarios). Where disabling is not possible, require Conditional Access approval for device-code redemption.
Containment communications. Notify finance, HR, logistics, and sales teams of the active lure themes ("Verify to view", "Signature required", invoice/SharePoint/Teams lures) and instruct them to report any recent interaction.

P2 — within 72 hours

Tighten Conditional Access. Require Conditional Access enforcement for any device-code redemption; restrict to known locations/devices; require MFA re-prompt on token issuance.
Mail-flow and identity hardening. Enable and tune Microsoft Defender for Office 365 policies against the lure themes; enable unified audit logging and ensure logs are forwarded to the SIEM with at least 90 days retention.
BEC controls. Enforce DMARC (p=reject or quarantine) on any customer-facing domains; flag outbound wire/invoice changes that originate from a mailbox that recently redeemed a device code.
Vendor / supply-chain review. Confirm Microsoft 365 is registered as an ICT third-party provider with current contractual incident-support contacts (DORA Art. 30 trigger).

P3 — within 7 days

Awareness uplift. Run a targeted phishing-awareness module covering device-code phishing specifically: the lure is a real Microsoft URL, the user is asked to enter a code, and the page may show their own organisation's branding.
Tabletop / scenario test. Add a device-code-flow abuse scenario to the resilience-testing programme (DORA Art. 24 trigger).
Concentration-risk review. Confirm M365 is flagged as a concentration-risk dependency and that contingency options are documented (DORA Art. 29 trigger).

5. Indicators of compromise

No indicators of compromise available in the source material.

The source material describes lure themes and a legitimate URL abused by the technique, but does not provide specific file hashes, IP addresses, attacker-controlled domains, or decoy-page URLs that can be used as IOCs. The microsoft.com/devicelogin URL is legitimate and must not be blocked.

6. Detection

Sigma rule — suspicious device-code redemption followed by mailbox abuse

title: Suspicious M365 Device Code Redemption Followed by Mail Send
id: 9c1f3a2e-7b4d-4e6a-8f12-1a2b3c4d5e6f
status: experimental
description: |
  Detects a Microsoft 365 device-code redemption (microsoft.com/devicelogin)
  followed shortly by an OAuth mail-send or mailbox access from an unusual
  location/AS, consistent with EvilTokens-style device-code phishing.
author: Adverse Trace
date: 2026-06-16
references:

  - https://www.welivesecurity.com/en/cybercrime/eviltokens-phishing-doesnt-steal-password/
logsource:
  product: azure
  service: signinlogs
detection:
  selection_devicecode:
    EventType: "Device Code"
    Application|startswith: "microsoft.com/devicelogin"
  selection_mailbox_abuse:
    EventType:

      - "MailboxItemAccessed"
      - "MailItemsAccessed"
      - "Send"
  timeframe: 30m
  condition: selection_devicecode AND selection_mailbox_abuse
falsepositives:

  - Legitimate IoT/smart-device device-code flows (rare in financial services)
level: high
tags:

  - attack.initial_access
  - attack.t1078
  - attack.t1566

Sigma rule — lure-content pattern in inbound mail

title: Inbound Mail With Device-Code Lure Pattern
id: 2b8e4d1a-9c3f-4a7b-8e2d-5f6a7b8c9d0e
status: experimental
description: |
  Flags inbound messages containing EvilTokens-style lure copy
  ("Verify to view", "Signature required") combined with a reference
  to microsoft.com/devicelogon or microsoft.com/devicelogin.
author: Adverse Trace
date: 2026-06-16
references:

  - https://www.welivesecurity.com/en/cybercrime/eviltokens-phishing-doesnt-steal-password/
logsource:
  product: m365
  service: exchange
detection:
  selection_lure:
    Subject|contains:

      - "Verify to view"
      - "Signature required"
  selection_url:
    HttpRequestUrl|contains:

      - "microsoft.com/devicelogin"
      - "microsoft.com/devicelogon"
  condition: selection_lure AND selection_url
falsepositives:

  - Legitimate IT communications directing users to device-login (rare)
level: high
tags:

  - attack.initial_access
  - attack.t1566
  - attack.t1566.002

7. Sources

ESET (WeLiveSecurity) — EvilTokens: A phishing attack that doesn't steal your password — https://www.welivesecurity.com/en/cybercrime/eviltokens-phishing-doesnt-steal-password/ — 2026-06-15
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 — 2026-05

8. Adverse Trace position

EvilTokens is a high-impact, low-noise threat to EMEA financial services because it weaponises a legitimate Microsoft authentication flow against high-value mailboxes (finance, treasury, HR, logistics, sales) and yields long-lived refresh-token persistence that survives password resets. The technique has been in active use since at least February 2026 and was deployed against 340+ organisations in March 2026, with Microsoft reporting AI-enabled variants that increase success rates. We assess the immediate priority as (a) auditing Entra ID for device-code redemptions and revoking tokens/sessions for any impacted user, (b) disabling or Conditional-Access-gating the device-code flow where business operations allow, and (c) running targeted user awareness on the lure pattern (real Microsoft URL, "Verify to view" / "Signature required" copy). Next steps: we will continue to monitor for additional IOCs and lure infrastructure, and update this advisory if specific attacker-controlled domains, hashes, or app IDs are published.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.