The Cloud Heist: Golden & Silver Token Attacks in Azure and Microsoft 365

Cloud identity systems like Microsoft Entra ID (formerly Azure AD) and Microsoft 365 use token-based authentication instead of traditional Kerberos tickets. In this model, a user signs in to an identity provider (IdP) and receives digital tokens (such as OAuth/OIDC JWTs or SAML assertions) that attest to their identity and permissions. As Microsoft explains, “A token is an authentication artifact that grants you access to resources. You get a token by signing into an identity provider (IDP) such as Microsoft Entra ID… The IDP responds to a successful sign-in by issuing a token that describes who you are and what you have permission to do”. These tokens are then presented to applications or services, which validate the issuer’s signature and any included claims to grant access. This flow is akin to receiving an amusement park pass (ID token) and exchanging it for ride tickets (access tokens) without re-entering credentials for each ride.

In Azure AD and Microsoft 365, token formats include OAuth 2.0 access tokens and refresh tokens, OpenID Connect (OIDC) ID tokens, and SAML 2.0 assertions. Each token contains claims about the user (e.g. user ID, roles, group memberships) and is cryptographically signed by the identity provider. Because tokens are bearer credentials, possession of a valid token (or the means to forge one) effectively grants the holder the identity and privileges it represents. Protecting tokens is therefore critical: if attackers steal or forge tokens, they can impersonate users or apps without ever knowing passwords.

What Are Access Tokens and Refresh Tokens?

Access tokens and refresh tokens are fundamental to OAuth 2.0 / OIDC. An access token is a short-lived credential used to access a specific resource (such as Microsoft Graph, Exchange Online, or a web API). As Microsoft documentation notes, “Access tokens are a type of security token designed for authorization, granting access to specific resources on behalf of an authenticated user… Access tokens differ from ID tokens which serve as proof of authentication”. In other words, access tokens are like keys unlocking a resource door; they contain claims (such as the user’s ID, groups, and scopes) that the service uses to decide if access is allowed. Access tokens are usually JSON Web Tokens (JWTs) signed by the IdP. Because they directly grant resource access, they must be protected carefully and have limited lifetimes (typically on the order of minutes or hours). For example, Azure AD’s default access token lifetime is about two hours for Microsoft 365 clients. When an access token expires, the client can no longer use it until a new token is obtained.

A refresh token is a longer-lived credential that allows the client to obtain new access tokens (and new refresh tokens) without requiring the user to reauthenticate. After the user initially signs in (often completing any MFA), Azure AD issues both an access token and a refresh token to the client. The client uses the short-lived access token to call APIs. When the access token expires (or is nearing expiration), the client sends the refresh token to Azure AD’s token endpoint to request a fresh access token (and refresh token) pair. Importantly, refresh tokens are bound to the user and client but can be used across multiple resources and tenants. Microsoft explains that “A refresh token is used to obtain new access and refresh token pairs when the current access token expires… Refresh tokens are encrypted and only the Microsoft identity platform can read them”. In Azure AD the default lifetime of a refresh token is much longer (typically 90 days), and each use of a refresh token usually results in a new refresh token, while the old one should be discarded by the client. Because refresh tokens last longer and can mint new access tokens, they are extremely sensitive—analogous to a season pass that grants continual ride tickets.

Kerberos Golden/Silver Ticket vs. Cloud Token Attacks

In on-premises Active Directory environments, attackers can exploit Kerberos ticket vulnerabilities. A Golden Ticket attack (MITRE T1558.001) occurs when an adversary obtains the Kerberos service account credentials (the KRBTGT account hash) and forges Ticket Granting Tickets (TGTs). With a valid forged TGT, the attacker can impersonate any user (including Domain Admins) on the domain. As CrowdStrike explains, Golden Ticket attacks give adversaries “long-term access by leveraging forged Kerberos Ticket Granting Tickets, effectively allowing an attacker to authenticate as any user, including domain admins.”. By contrast, a Silver Ticket attack involves forging a service ticket (TGS) for a specific service by cracking that service’s key. For example, if an attacker cracks the password for the SQLServer service account, they can create Silver Tickets granting access to SQL services without contacting the DC. Silver tickets are often stealthier because the authentication can occur without revalidating against the DC, and the normal user sign-in logs on the DC may not show anything unusual.

Token-based attacks in the cloud are analogous but use OAuth/SAML tokens instead of Kerberos tickets. A “Golden Token” attack means the adversary can forge or mint new tokens at will, usually by obtaining the identity provider’s signing key or certificate. This is similar in spirit to a Kerberos Golden Ticket: it allows arbitrary identities to be created without bounds. A “Silver Token” attack refers to the attacker obtaining and replaying valid tokens (session cookies, access tokens, refresh tokens) from users or devices. In effect, a stolen token is reused to masquerade as the legitimate user, bypassing fresh authentication. These token attacks have parallels to Pass-the-Ticket in AD and Pass-the-Hash attacks, but they play out entirely in the cloud identity space.

In summary, Kerberos golden/silver tickets rely on on-premises domain secrets and have to adhere to Kerberos protocols, while cloud token attacks target OAuth/OIDC/SAML flows and typically exploit stolen tokens or signing keys. Also, cloud tokens often carry device and location claims, so attackers may attempt token replay from different networks – something a Kerberos ticket would not normally show. Importantly, stolen cloud tokens are issued after MFA, so they inherently bypass multi-factor requirements on subsequent uses, whereas Kerberos tickets are primarily single-factor (password) based.

Golden Token Attack (Forged Tokens / Compromised Keys)

A Golden Token Attack is one in which the attacker is able to forge authentication tokens – for example, by extracting or compromising the identity provider’s signing key or certificate. Once an attacker has the private key used by the IdP (Azure AD, AD FS, etc.) to sign tokens, they can craft arbitrary tokens that will be accepted by any trusted service. For instance, Microsoft’s Storm-0558 analysis explains that “an actor that can acquire a private signing key can then create falsified tokens with valid signatures that will be accepted by relying parties,” enabling full impersonation. In practice, this has occurred in multiple breaches:

Golden SAML (SolarWinds). In the Solorigate/SolarWinds attack (2020), threat actors penetrated on-prem AD FS servers and used the FoggyWeb backdoor to steal the AD FS token-signing certificate. With that private key, they generated forged SAML assertions for arbitrary user accounts in Microsoft 365, giving themselves persistent admin-level cloud access without valid credentials. As Semperis reports, “Golden SAML… has been known for its extraction of signing certificates from Active Directory Federation Services… and its use of those certificates to forge SAML authentication responses.”. The SolarWinds actors “moved laterally into the AD FS environment” and “stole the private key material used to sign SAML responses”. FoggyWeb (“GoldenSAML backdoor”) let the attackers exfiltrate the decrypted signing certificate from AD FS, after which they could create valid SAML tokens at will. In short, Golden SAML is a classic Golden Token: compromised IdP keys → forged tokens.
Storm-0558 (OIDC/JWT token forgery). In 2023, the Storm-0558 (aka Antique Typhoon) incident involved stolen Azure/Microsoft account signing keys. The attackers managed to acquire a Microsoft Account (MSA) signing key and used it to create Azure AD tokens for Outlook Web Access. As Trustwave explains, “If [the identity provider’s] private keys are compromised, attackers can create tokens that appear valid to any service that relies on them.”. Storm-0558 did exactly that: by forging tokens (for example by adjusting JWT claims like sub and tid) and signing with the stolen key, they bypassed tenant checks and obtained full mailbox access for victims. Microsoft’s analysis confirms: “an actor… can create falsified tokens with valid signatures… This is called token forgery”. In essence, they performed a Golden Token Attack on the OAuth/OIDC infrastructure.
Other SAML/Token key attacks. Any time an IdP’s signing certificate is compromised, it enables Golden Tokens. For example, if an organization uses AD FS or other federated SAML identity providers, an attacker who acquires the SAML signing certificate (or its private key) can forge SAML tokens for any user or service. Semperis also notes that such an attack can even happen in Azure AD itself if an external certificate is imported: “Any attacker that obtains the private key of an externally generated certificate can forge any SAML response they want and sign that response with the same private key… the attacker can then access the application—as any user.”. Microsoft even recommends protecting AD FS keys with an HSM and migrating to Entra ID because “AD FS servers can authenticate users and should therefore be treated with the same high level of security... AD FS is on-premises, and deployments can get out of date and be impacted by local compromises. For these reasons, migration to a cloud-based identity solution such as Azure Active Directory is recommended”.

In summary, a Golden Token Attack means the attacker has effectively hijacked the token signing process: they can mint unlimited new tokens (SAML, OAuth/JWT, etc.) for any identity. These forged tokens will pass all normal signature and claim checks (issuer, audience, tenant) unless additional measures (like proof-of-possession binding) are in place. No adversary knowledge of the victim’s password or MFA credential is needed once the signing key is under control.

Silver Token Attack (Hijacked and Replayed Tokens)

A Silver Token Attack involves stealing existing tokens (such as access tokens, session cookies, or refresh tokens) and reusing them to gain access as the victim. This is analogous to a Kerberos Silver Ticket: the attacker uses a legitimate service ticket (token) for a specific service. In cloud terms, a Silver Token might be a valid refresh token, an OAuth access token, or even a session cookie from an authenticated browser session. Once in the attacker’s hands, the token can be replayed to access resources until it expires or is revoked.

For example, red team exercises have shown that Azure AD refresh tokens (which by default can live 90 days) are particularly valuable. As one researcher noted, “Even without compromising credentials or MFA, if I can steal a token, I can impersonate a user or app, access cloud resources without logging in, [and] bypass conditional access if the token already satisfies the policy”. In practice, attackers use malware, man-in-the-middle phishing frameworks (like Evilginx), or malicious apps to extract tokens from browsers or memory. A stolen refresh token can then be used to obtain new access tokens silently. As another analyst observed: “Refresh tokens often lived for 90+ days (default)… making them very valuable for attackers. Replayed tokens allow attackers to act as legitimate users — without needing passwords”. Similarly, session cookies captured from a user’s browser allow the attacker to “pass the cookie” into another browser and access web apps as that user, all under the radar.

In a Silver Token Attack, no forging is needed, the attacker works entirely with valid, previously issued tokens. It typically requires an initial compromise of the user’s device or environment (e.g., phishing, malware, compromised admin workstation, or vulnerable service). Once the attacker obtains the token, they use it with standard client libraries or API calls. For instance, they might use a PowerShell script or a tool like TokenTactics to feed the stolen refresh token to Azure AD and collect new access tokens. As one red team demonstrated, after stealing a session cookie via phishing, they used TokenTactics to quietly request new tokens by accepting a device-code prompt, yielding bearer tokens for later abuse. Tools like AADInternals can extract Primary Refresh Tokens (PRTs) or manipulate OAuth flows, and TokenTactics can automate device flow compromises, both ultimately result in usable tokens for the attacker.

Because stolen tokens often carry high privileges and are already MFA-validated, they let attackers move freely. However, unlike Golden Tokens, they are limited to whatever identity and scopes the token grants. Once detected or expired, the threat is contained (unless the attacker continually steals new tokens).

Technical Attack Workflow for Each

Golden Token Attack Workflow:

Compromise the IdP or trust chain. The attacker first gains access to the identity provider’s sensitive assets. This could be an on-prem AD FS server (via malware like FoggyWeb/MagicWeb) or the Azure AD certificate store. In SolarWinds, attackers embedded FoggyWeb on AD FS to extract the private signing certificate. In Storm-0558, they somehow obtained the MSA signing key for Azure AD.
Extract signing material. Using local privileges, memory dumps or backdoors, the attacker retrieves the private keys or certificates used for signing tokens. For example, FoggyWeb allowed retrieval of the AD FS token-signing certificate.
Forge tokens. With the key in hand, the attacker crafts new authentication tokens. This may involve building a SAML assertion XML or assembling a JWT, setting claims (user ID, group memberships, tenant ID, etc.) as desired, and signing it with the stolen key. Specialized tools or scripts (e.g. SilverSAMLForger, custom PowerShell modules, or JWT libraries) can automate this. The attacker can impersonate any account: an ordinary user or a Global Admin, depending on the forged claims.
Use the forged token. The attacker presents the forged token to the target application or service. For SAML, this means posting the fake SAML response to the service provider’s endpoint. For OAuth/OIDC, it could mean exchanging the forged JWT at an API or using it in a bearer header. Because the token signature validates (the service trusts the compromised key), the attacker gains immediate access with the chosen identity. No further checks (like MFA) are performed if the token appears valid.

Silver Token Attack Workflow:

Steal a valid token. The attacker obtains an active token from a user or app. This could be done via credential phishing + malware (to dump browser cookies or in-memory tokens), man-in-the-middle (AitM frameworks that proxy and capture cookies/tokens), exploiting a web app vulnerability that exposes tokens, or extracting a token cache from a compromised device (e.g. using AADInternals to grab a PRT or refresh token). For example, using Evilginx2 a red team phishing campaign captured a user’s browser session cookie.
Validate/use the token. With the stolen token (refresh or access token), the attacker uses normal API calls. An access token can be used directly in REST calls (e.g. Authorization: Bearer to Microsoft Graph). A refresh token is used at the token endpoint to fetch a new access token. Attackers often do this programmatically with PowerShell (Invoke-RestMethod) or tools. In the TrustedSec example, after session theft they ran TokenTactics, accepted a device code prompt, and obtained new bearer tokens.
Escalate and move laterally. With the token validated, the attacker operates as the victim. They can list data, send emails, configure resources, etc., all while showing as the legitimate user. If an access token carries elevated privileges (e.g. from a Global Admin), the impact is huge. Even if not, they might use the access granted to find other credentials or set up persistent abuse (e.g. create new tokens, register malicious apps).
Maintain persistence. Since refresh tokens are long-lived, the attacker can keep requesting new access tokens until the refresh token expires or is revoked. They may also steal additional tokens periodically (for example by maintaining malware on the device or reusing phishing).

Tools and Tactics: In these workflows, red teams and attackers leverage specialized tools. Besides TokenTactics, the AADInternals toolkit can extract Primary Refresh Tokens (PRTs) on Windows devices (Pass-the-PRT) or enumerate Azure AD details. They may also use modified MSAL libraries or PowerShell modules to perform OAuth flows with stolen tokens. For on-prem federation attacks, tools like Mimikatz or custom scripts extract AD FS certificates. In all cases, standard Azure AD endpoints (OAuth token endpoint, Graph API) are used under the hood, making the actions appear legitimate.

Real-World Case Studies

SolarWinds/Solorigate and FoggyWeb (Golden SAML). In the 2020 SolarWinds breach, attackers (Nobelium/CozyBear) injected malicious code into the Orion software, then leveraged that foothold to infiltrate Microsoft’s own environment. Critically, they breached on-prem AD FS servers and installed the FoggyWeb backdoor. FoggyWeb was designed “to exfiltrate sensitive information from a compromised AD FS server”. Once in, the attackers extracted the AD FS token-signing certificates (both signing and decryption certs were compromised). With those keys, they executed a classic Golden SAML attack: forging SAML tokens for any user in Microsoft 365. Semperis notes that Golden SAML in Solorigate was “one of the attackers’ more innovative attack vectors”. The result was silent, pervasive access: victims’ token caches were full of malicious SAML assertions, effectively granting the attackers near-blanket access to email and data. Microsoft and CISA later advised organizations to migrate away from on-prem AD FS and use native Entra ID SAML sign-in (where signing keys cannot be exported).

Storm-0558 (Cross-Tenant Token Forgery). In mid-2023, Microsoft disclosed an Azure AD attack dubbed Storm-0558. In this case, the adversary managed to “acquire an inactive MSA consumer signing key and [use] it to forge authentication tokens for Azure AD”. Due to a misconfiguration in Azure’s multi-tenant validation logic, tokens signed with the stolen consumer key were accepted for enterprise (Azure AD) users. The attackers adjusted the token claims (e.g. tenant ID and subject) and signed it with the compromised key. The forged token was then used to access Outlook Web Access and exfiltrate email. This incident underlines the Golden Token concept: by taking over a legitimate signing key, the attackers could fabricate tokens that any Azure service would trust. As one analysis summarized, “the signed tokens were given access to resources such as Outlook Web Access… a single stolen key became a universal pass across multiple tenants, which is a worst-case outcome for multi-tenant services.”. The lessons included the importance of key isolation and retiring old keys.

Other Token Thefts and Replay. Beyond these headline cases, many red-team and APT campaigns leverage stolen tokens. For example, Microsoft’s Incident Response teams have repeatedly found attackers using OAuth token replay: harvesting refresh tokens from endpoints (or browser caches) and using them to move laterally in cloud environments. In one published Red Team case study, replaying Azure AD refresh tokens yielded access with no alerts, since “most organizations do not revoke refresh tokens quickly”. Researchers have also demonstrated Silver SAML (an Entra ID analog of Golden SAML) where Azure AD-issued SAML signing certs can be abused if poor certificate management allows key export. These cases collectively show that token abuse spans both older federation (SAML) and modern OAuth/OIDC scenarios, and that detection often hinges on subtle anomalies rather than explicit “token compromised” logs.

Detection and Logging Challenges in Cloud

Detecting token-based attacks in cloud environments is difficult. Unlike Kerberos, where a suspicious TGT might trip a domain controller log, OAuth/SAML token usage generates few distinct events. Azure AD sign-in logs will show a successful authentication for a user, but they cannot easily distinguish whether that authentication came from a legitimate login or from a replayed/forged token. In fact, if the attacker uses a token from a familiar IP/device, the sign-in may look completely normal. As one Microsoft blog notes, “Because a token is digital… [the attacker] can use their copy of your token to get unlimited new access tokens… and it may take a while to determine that anything is amiss—if you ever do.”.

Instead, defenders must rely on anomaly detection and risk signals. Azure AD Identity Protection has specific detections for “anomalous token events”; for example, a login marked by token replay from a distant location can trigger impossible-travel alerts. As Microsoft DART describes: “When a token is replayed, the sign-in from the threat actor can flag anomalous features and impossible travel alerts. Azure AD Identity Protection and Microsoft Defender for Cloud Apps both alert on these events.”. In practice, this means looking for login patterns that violate normal behavior – e.g. a valid refresh token used from a new country, or simultaneous sessions that overlap physically impossible locations. Defender for Cloud Apps (MCAS) can also detect risky sign-ins.

Logging is another hurdle. Standard Azure AD logs do not record raw tokens or their contents. If an attacker presents a stolen token, Azure AD simply logs a successful sign-in under the original user account, with perhaps an IP address or device ID. On-prem AD FS logs may not capture anything useful either (a forged SAML token will be accepted as if real). Thus, defenders often have to correlate multiple logs: Azure AD sign-in logs, audit logs (e.g. records of refresh token revocations or conditional access events), and cloud app logs. Even then, evidence might be limited to “normal user signed in” with no password prompt.

In summary, token attacks can fly under the radar of traditional logging. Detection hinges on identifying outliers: suspicious IPs, unfamiliar devices, sudden elevation of privileges, or other persistence actions after the fact. For example, a sign-in from a token might later be followed by unusual mailbox forwarding rules or data downloads. Security teams should enable Azure AD Identity Protection risk policies, monitor conditional access insights, and consider using advanced SIEM correlation (e.g. Microsoft Sentinel) to flag anomalies that might indicate token misuse.

Prevention Strategies

Preventing Golden/Silver token attacks requires a multi-layered approach focused on protecting tokens and hardening identity systems:

Conditional Access and Device Compliance. Enforce Azure AD Conditional Access policies that tie sessions to trusted conditions. For example, require that only known devices (Azure AD joined or Intune-compliant) can access critical apps like Exchange or SharePoint. Device-based policies ensure that even if a token is stolen, it can only be used on the legitimate user’s enrolled device. Use location-based conditions, MFA requirements for high-risk apps, and sign-in frequency/session controls. Microsoft suggests reducing session lifetimes (forcing periodic re-authentication) to limit token validity and increase chances of detection.
Token Protection (Token Binding). Enable Azure AD’s Token Protection session control (preview) in Conditional Access. Token protection binds issued tokens cryptographically to the device they were issued on. As Microsoft explains, “Token protection… attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker is able to steal a token… they can impersonate their victim until the token expires”. In practice, this means a stolen refresh token exported to another machine becomes useless without the device’s private key. Deploy token protection policies (e.g. via CA “Require token protection” settings) for Windows devices and supported apps as they come out of preview.
Phishing-Resistant MFA and Credential Hygiene. Deploy strong multi-factor authentication methods (FIDO2 keys, certificate-based auth, etc.) especially for high-privilege accounts. Use separate “break-glass” or “cloud-only” admin accounts for tenant administration (no mailbox, no legacy protocols) to reduce attack surface. Training and detection for phishing/AitM attacks is crucial, since stealing tokens often starts with credential/phish. Also enable Password Hash Sync on-prem (even if using AD FS) as a backup to allow Azure AD to detect leaked passwords.
Secure Federation and Keys. Protect any on-prem federation infrastructure. If AD FS is used, store signing certificates in a hardened manner (e.g. HSM) and limit admin access. As a Microsoft advisor lamented, customers should ask “why… do not protect their AD FS keys in an HSM…? This was a key vector during the SolarWinds attack”. If possible, decommission AD FS in favor of cloud-native authentication (Entra ID) or at least follow Microsoft’s AD FS hardening guidance. Enforce short lifetimes and frequent rotation for SAML/OIDC certificates. Use Azure Key Vault for certificate management when importing external SAML certs. Semperis also warns against using externally generated SAML certs that can be exported: “Any attacker that obtains the private key of an externally generated certificate can forge any SAML response they want”.
Least Privilege and Tenant Hardening. Apply rigorous least-privilege in Azure AD. Do not sync high-privilege on-prem accounts (Tier 0) into Azure AD, so a breach on-prem doesn’t directly yield cloud admin creds. Minimize the number of global or privileged admins. Monitor and alert on the creation of new admin roles or enterprise apps. Enforce baseline security policies (e.g. require MFA on all privileged tasks, disable legacy auth protocols). Treat identity systems (Entra ID, AD FS, MFA services) as crown jewels and monitor changes to their configuration.
Continuous Monitoring and Risk Policies. Enable Azure AD Identity Protection and custom risk-based controls. Configure alerts for unusual sign-ins (impossible travel, unfamiliar locations, legacy auth from cloud-only apps). Use tools like Cloud App Security (MCAS) to detect unusual OAuth app consents or token usage. Employ continuous access evaluation (CAE) where supported: Azure AD CAE can instant-revoke tokens upon critical events (e.g. account compromise), reducing the risk window. In short, assume tokens can be stolen; make sure there are sensors that flag when something odd happens.

Incident Response Recommendations for Token Abuse

If you suspect token compromise or replay in your environment, take immediate action to cut off the attacker’s access and investigate:

Revoke Tokens. Use Azure AD to revoke refresh tokens for the affected user(s). Azure AD provides the capability to revoke (invalidate) a user’s refresh token via the admin portal, PowerShell or Microsoft Graph. Once revoked, that refresh token cannot be used to obtain new access tokens. Also reset the user’s password as part of the response. Keep in mind that revoking refresh tokens does not immediately kill any active access tokens (which may still be valid for up to an hour). To address this gap, rely on Continuous Access Evaluation (CAE): in tenants where CAE is enabled for services like Exchange, SharePoint and Teams, Azure will block access tokens in near real-time after a revocation or risk event. If CAE is not available, defenders should assume up to a one-hour “grace period” for access tokens to expire.
Contain and Eradicate. After token revocation, look for other persistence. According to Microsoft DART, check for typical persistence signals that often accompany token theft: malicious mailbox rules or forwarding that could exfiltrate or hide emails, unexpected added MFA methods (e.g. attacker’s phone), suspicious device registrations or exclusions (to bypass CA), or illicit cloud file shares. Investigate audit logs in Microsoft 365 and Azure AD to find any other suspicious actions: creation of service principals or app consents, elevation of privileges, modification of conditional access policies, etc. Use the Unified Audit Log, Defender for Cloud Apps logs, or SIEM solutions to correlate events. Remove any discovered backdoors or malware from compromised hosts (e.g. AD FS or user devices).
Monitor and Report. Enable continuous monitoring for further anomalies related to the affected accounts, and look out for repeat attempts from similar IPs or user-agents. Apply any conditional access policy changes needed (for instance, block sign-ins from unmanaged devices for that user). Microsoft also advises configuring alerts for “high-risk modifications” in the tenant – for example, creation of new admin accounts or changes to security settings. Report the incident to Microsoft or relevant threat intelligence partners if needed, especially if it appears part of a larger campaign (e.g. SolarWinds was state-sponsored).
User Communication and Review. Inform the impacted user(s) of the breach. They should sign out of all sessions and re-authenticate. Consider requiring multi-factor re-verification for all critical apps. Educate the user on phishing hygiene. Finally, review the root cause: Was it a phishing email? Malware? An improperly secured certificate? Hardening these areas will help prevent recurrence.

FAQs

Q: How is a token-based attack different from a password compromise? Token attacks (Golden/Silver tokens) operate after authentication has occurred. For example, an MFA-authenticated session yields a token, and the attacker abuses that token. Unlike a direct password break-in, token attacks often bypass MFA altogether, once the token exists, the user doesn’t need to re-enter credentials or second factors. Moreover, tokens can carry privileged information (device ID, claims) which passwords do not. However, both ultimately allow the attacker to impersonate the user.

Q: Can MFA stop these attacks? By itself, no. If an attacker steals or forges a token after a successful MFA, the system sees a valid MFA session. Enforcing phishing-resistant MFA (like hardware keys) can prevent some attacks (for example, man-in-the-middle OAuth phishing typically fails against FIDO2). But if the attacker has the finished token, even FIDO-protected sessions can be replayed. This is why layered defenses (device checks, token binding, CAE) are essential.

Q: What happens if I rotate or revoke a signing certificate? For a Golden Token scenario, rotating the compromised key stops new forgeries. For example, after Storm-0558, Microsoft invalidated all keys issued before the incident. Revoking certificates will invalidate any tokens signed by that cert. However, tokens already minted may remain valid until expiry, so doing this quickly after detection is important.

Q: How long do stolen tokens remain useful? It depends on the token type. Azure AD access tokens are generally short-lived (minutes to a couple of hours). Refresh tokens default to 90 days, so an attacker could use a stolen refresh token for weeks. However, any active access token issued by that refresh token will remain usable until it expires or is explicitly revoked (if CAE is enabled, revocation is almost immediate).

Q: What is token replay, and why is it a concern? Token replay is the reuse of a valid token by an attacker. For example, capturing a refresh token (e.g. via browser malware) and then using it to silently sign in from another location. The attacker “replays” that token to obtain new access tokens. It’s dangerous because the token looks legitimate. Azure AD may detect it as an unusual sign-in (impossible travel, unfamiliar IP), but if those anomalies are subtle, replay can continue unseen.

Q: What is Continuous Access Evaluation (CAE)? CAE is a feature where Azure AD can revoke already-issued access tokens in real time upon certain triggers (like credential changes or reported compromises). With CAE enabled for apps like Exchange and SharePoint, if you revoke a user’s refresh token or update their MFA status, any current access tokens can be invalidated immediately. This significantly shortens the window in which a stolen token can be used.

Q: Do I need to do anything in MFA Conditional Access specifically for token attacks? Token attacks exploit sessions after MFA. However, enforcing session controls (like short sign-in frequency or token protection) via Conditional Access can mitigate them. For example, requiring token protection (device-bound tokens) under CA, or using session policies to limit the duration of SSO, can reduce risk. Ensuring “Require sign-in frequency” is set to a reasonable value causes re-authentication regularly, limiting the lifetime of tokens.

Q: Are there any audit logs that show token usage? Azure AD sign-in logs show the IP, location, and device for each sign-in, but they do not log token contents. There are no explicit “token was replayed” events. However, you can look for related events: e.g. multiple sign-ins from different locations in a short time, or sign-ins that weren’t triggered by user action (look at activity type in logs). Azure also records events like “RefreshTokenIssuance” in some logs, which can be parsed for anomalies. In general, use Identity Protection risk events and SIEM correlation to catch suspicious patterns.

Conclusion and Final Thoughts

Token-based attacks in Microsoft 365 and Azure AD highlight that identity is the new perimeter. As organizations move to cloud identity, attackers have shifted from old-style Kerberos exploits to these token-based techniques. Golden Token attacks (forged SAML/JWT tokens via compromised keys) and Silver Token attacks (stolen refresh/access tokens) can grant attackers wide-ranging, stealthy access. However, modern cloud IAM also offers modern defenses: Conditional Access, token protection, identity protection, and continuous evaluation can all help close the window on token abuse.

Defenders should assume that usernames and passwords alone are not enough , if an attacker can trick, phish, or malware their way into token acquisition, they can bypass many controls. Therefore, implement defense-in-depth: strong MFA, device management, least privilege, and especially careful handling of cryptographic keys and certificates. Monitor relentlessly for anomalies, and have incident plans ready (knowing how to revoke tokens and analyze audit logs). With vigilance and Azure AD security best practices, organizations can make token attacks much harder and minimize the damage if they occur.