-
Notifications
You must be signed in to change notification settings - Fork 0
From EvilTokens to HarrierOps Azure Why Token Theft Can Become Azure Control
Sekoia's EvilTokens research shows how Microsoft device code phishing can move quickly from token theft into real post-compromise access across Microsoft 365, Microsoft Graph, SharePoint, and Azure.
That is the part Azure defenders should not underplay.
HarrierOps Azure is not a defender-first tool. It is an attack-path-oriented Azure reconnaissance tool built around the same practical question an attacker asks after gaining authenticated access: what can this identity reach, control, or pivot into next?
That is exactly why it matters to defenders.
The Sekoia research documents the tradecraft. HarrierOps Azure helps turn the Azure-side implications of that tradecraft into something concrete: identity scope, privilege, trust, cross-tenant reach, and follow-on credential paths. If valid Azure authentication exists on a compromised machine, defenders should assume the reachable cloud path matters immediately.
The EvilTokens reporting is important because it shows that "token theft" is not a narrow outcome.
The two Sekoia posts describe a workflow where a victim is lured into completing a legitimate Microsoft device code flow, the attacker captures Microsoft access and refresh tokens, then uses those tokens to reach Outlook, Microsoft Graph, SharePoint, Azure, and persistence-related session material.
That is already more than account access. It is authenticated operational access.
HarrierOps Azure matters here because it helps answer the next question quickly:
What does that authenticated Azure-capable identity actually open up?
Sekoia documents the TTPs. HarrierOps Azure helps turn those TTPs into Azure-side implementation and investigation paths. The research explains what an attacker is doing. HarrierOps Azure helps show what that attacker can likely reach next from the live authenticated context already present on a workstation.
At a high level, Sekoia's March 30, 2026 and April 7, 2026 EvilTokens reporting describes this chain:
- The attacker uses Microsoft device code phishing to trick a user into authorizing the attacker's device.
- The attacker captures Microsoft access and refresh tokens from the completed flow.
- Those tokens are then used to request access for Outlook, Microsoft Graph, Azure, Substrate, and SharePoint.
- The attacker performs reconnaissance through Microsoft Graph and related Microsoft 365 data sources.
- The attacker uses the compromised session for follow-on access, fraud workflows, and persistence.
The important Azure takeaway is not just that tokens were stolen.
The important takeaway is that a valid authenticated identity may now be available to inspect Azure posture, enumerate privilege, discover trust paths, and locate additional authentication material or secrets.
"Just a token grab" makes the problem sound smaller than it is.
A valid Microsoft token can be the start of:
- immediate access to Azure-capable identity context
- Azure RBAC discovery
- trust-path mapping
- Microsoft Graph reconnaissance
- app and service principal follow-on abuse
- cross-tenant expansion
- discovery of additional auth material
- persistence through longer-lived session mechanisms
In other words, token theft is often only the opening move. The real issue is what the authenticated identity can do next.
HarrierOps Azure is useful in this moment because it brings that next-step picture to the top quickly. It does not invent the risk. It makes the reachable Azure path easier to see and much faster to act on.
Use whoami first to confirm the exact Azure identity context already present on the compromised
machine.
- Post-compromise question: Which principal, tenant, and subscription is this session actually operating under?
- Defender value: It grounds the Azure investigation in the real authenticated identity instead of assumptions about who or what was compromised.
Use permissions to see whether the authenticated identity already has meaningful Azure control.
- Post-compromise question: Does this foothold already have high-impact Azure roles or broad scope?
- Defender value: It quickly shows whether token theft may already have become an Azure control problem.
Use auth-policies to understand whether tenant-wide identity posture makes follow-on abuse
easier.
- Post-compromise question: Do guest access, app registration, consent, or related policy settings widen what this foothold can become?
- Defender value: It helps explain why a lower-privilege compromise may still carry outsized risk in a permissive tenant.
Use role-trusts to identify indirect control paths through ownership, federation, or application
trust.
- Post-compromise question: Can this foothold influence stronger identities or applications without starting with direct Azure admin rights?
- Defender value: It brings indirect control paths to the surface before they are missed in a role-only review.
Use cross-tenant to determine whether the reachable trust picture extends beyond the current
tenant.
- Post-compromise question: Does this authenticated path connect to outside-tenant management, externally owned service principals, or broader trust edges?
- Defender value: It helps defenders assess whether blast radius may cross tenant boundaries.
Use tokens-credentials to look for the next useful authentication path behind the current
foothold.
- Post-compromise question: What additional token, secret, managed identity, or credential-bearing surface could this attacker reach next?
- Defender value: It helps defenders find the follow-on auth material an attacker is likely to target before they do.
If EvilTokens-style activity is present, defenders should expect the attacker to move quickly from authentication to expansion.
Common next objectives include:
The attacker wants stronger Azure roles or broader control than the initial identity already has.
Relevant HarrierOps Azure commands:
permissions, privesc, rbac
The attacker wants to use app ownership, federation, delegated trust, or indirect control to reach something stronger.
Relevant HarrierOps Azure commands:
role-trusts, auth-policies
The attacker wants to move from user access into application-backed control, persistence, or workload identity paths.
Relevant HarrierOps Azure commands:
principals, managed-identities, role-trusts, permissions
The attacker wants to determine whether the current foothold reaches another tenant or delegated management path.
Relevant HarrierOps Azure commands:
cross-tenant, lighthouse
The attacker wants to find the next token, the next secret, or the next workload identity path.
Relevant HarrierOps Azure commands:
tokens-credentials, env-vars, keyvault, managed-identities
HarrierOps Azure is not a defender-first incident response product.
It is useful here for the opposite reason: it reflects the kind of Azure path analysis an attacker would already want to perform after gaining authenticated access.
That is the defender value.
If EvilTokens-style compromise is suspected on a workstation, do not stop at "tokens may have been stolen." Move quickly to determine:
- which Azure identity is active
- what that identity can control
- whether trust expands the path
- whether the foothold crosses tenant boundaries
- whether more authentication material is now reachable
This is not a panic point. It is a call to action.
The right response is to treat authenticated Azure context on a compromised machine as an immediate cloud triage priority, then map the reachable blast radius before the attacker can do the same faster than you.
ho-azure whoami
ho-azure permissions
ho-azure auth-policies
ho-azure role-trusts
ho-azure cross-tenant
ho-azure tokens-credentials- Home
- Getting Started
- Platform Notes
- Running Against The Proof Lab
- Understanding Output
- Command Guides
Core
Identity
Config
Secrets
Storage
Resource
Compute
Orchestration
Chain Families
Investigations
- Axios - Post Exposure Azure Triage
- From EvilTokens to HarrierOps Azure: Why Token Theft Can Become Azure Control
- FAQ / Known Limits (coming soon)