{
	"id": "70dff08c-059d-4572-a859-4253e21db255",
	"created_at": "2026-04-06T00:19:10.670546Z",
	"updated_at": "2026-04-10T03:20:06.93086Z",
	"deleted_at": null,
	"sha1_hash": "b538bce85c34e0dfca7490d9155ba6a9a47b0e6d",
	"title": "Token tactics: How to prevent, detect, and respond to cloud token theft",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 721408,
	"plain_text": "Token tactics: How to prevent, detect, and respond to cloud token\r\ntheft\r\nBy Microsoft Defender Experts, Microsoft Incident Response\r\nPublished: 2022-11-16 · Archived: 2026-04-05 21:36:12 UTC\r\nAs organizations increase their coverage of multifactor authentication (MFA), threat actors have begun to move to\r\nmore sophisticated techniques to allow them to compromise corporate resources without needing to satisfy MFA.\r\nRecently, the Microsoft Detection and Response Team (DART) has seen an increase in attackers utilizing token\r\ntheft for this purpose. By compromising and replaying a token issued to an identity that has already completed\r\nmultifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational\r\nresources accordingly. This poses to be a concerning tactic for defenders because the expertise needed to\r\ncompromise a token is very low, is hard to detect, and few organizations have token theft mitigations in their\r\nincident response plan.\r\nWhy it matters\r\nIn the new world of hybrid work, users may be accessing corporate resources from personally owned or\r\nunmanaged devices which increases the risk of token theft occurring. These unmanaged devices likely have\r\nweaker security controls than those that are managed by organizations, and most importantly, are not visible to\r\ncorporate IT. Users on these devices may be signed into both personal websites and corporate applications at the\r\nsame time, allowing attackers to compromise tokens belonging to both.\r\nAs far as mitigations go, publicly available open-source tools for exploiting token theft already exist, and\r\ncommodity credential theft malware has already been adapted to include this technique in their arsenal. Detecting\r\ntoken theft can be difficult without the proper safeguards and visibility into authentication endpoints. Microsoft\r\nDART aims to provide defenders with the knowledge and strategies necessary to mitigate this tactic until\r\npermanent solutions become available.\r\nTokens are at the center of OAuth 2.0 identity platforms, such as Azure Active Directory (Azure AD). To access a\r\nresource (for example, a web application protected by Azure AD), a user must present a valid token. To obtain that\r\ntoken, the user must sign into Azure AD using their credentials. At that point, depending on policy, they may be\r\nrequired to complete MFA. The user then presents that token to the web application, which validates the token and\r\nallows the user access.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nPage 1 of 7\n\nFigure 1. OAuth Token flow chart\r\nWhen Azure AD issues a token, it contains information (claims) such as the username, source IP address, MFA,\r\nand more. It also includes any privilege a user has in Azure AD. If you sign in as a Global Administrator to your\r\nAzure AD tenant, then the token will reflect that. Two of the most common token theft techniques DART has\r\nobserved have been through adversary-in-the-middle (AitM) frameworks or the utilization of commodity malware\r\n(which enables a ‘pass-the-cookie’ scenario).\r\nWith traditional credential phishing, the attacker may use the credentials they have compromised to try and sign in\r\nto Azure AD. If the security policy requires MFA, the attacker is halted from being able to successfully sign in.\r\nThough the users’ credentials were compromised in this attack, the threat actor is prevented from accessing\r\norganizational resources.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nPage 2 of 7\n\nFigure 2. Common credential phishing attack mitigated by MFA\r\nAdversary-in-the-middle (AitM) phishing attack\r\nAttacker methodologies are always evolving, and to that end DART has seen an increase in attackers using AitM\r\ntechniques to steal tokens instead of passwords. Frameworks like Evilginx2 go far beyond credential phishing, by\r\ninserting malicious infrastructure between the user and the legitimate application the user is trying to access.\r\nWhen the user is phished, the malicious infrastructure captures both the credentials of the user, and the token.\r\nFigure 3. Adversary-in-the-middle (AitM) attack flowchart\r\nIf a regular user is phished and their token stolen, the attacker may attempt business email compromise (BEC) for\r\nfinancial gain. If a token with Global Administrator privilege is stolen, then they may attempt to take over the\r\nAzure AD tenant entirely, resulting in loss of administrative control and total tenant compromise.\r\nPass-the-cookie attack\r\nhttps://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nPage 3 of 7\n\nA “pass-the-cookie” attack is a type of attack where an attacker can bypass authentication controls by\r\ncompromising browser cookies. At a high level, browser cookies allow web applications to store user\r\nauthentication information. This allows a website to keep you signed in and not constantly prompt for credentials\r\nevery time you click a new page.\r\n“Pass-the-cookie” is like pass-the-hash or pass-the-ticket attacks in Active Directory. After authentication to Azure\r\nAD via a browser, a cookie is created and stored for that session. If an attacker can compromise a device and\r\nextract the browser cookies, they could pass that cookie into a separate web browser on another system, bypassing\r\nsecurity checkpoints along the way. Users who are accessing corporate resources on personal devices are\r\nespecially at risk. Personal devices often have weaker security controls than corporate-managed devices and IT\r\nstaff lack visibility to those devices to determine compromise. They also have additional attack vectors, such as\r\npersonal email addresses or social media accounts users may access on the same device. Attackers can\r\ncompromise these systems and steal the authentication cookies associated with both personal accounts and the\r\nusers’ corporate credentials.\r\nFigure 4. Pass-the-cookie attack flowchart\r\nCommodity credential theft malware like Emotet, Redline, IcedID, and more all have built-in functionality to\r\nextract and exfiltrate browser cookies. Additionally, the attacker does not have to know the compromised account\r\npassword or even the email address for this to work— those details are held within the cookie.\r\nRecommendations\r\nProtect\r\nOrganizations can take a significant step toward reducing the risk of token theft by ensuring that they have full\r\nvisibility of where and how their users are authenticating. To access critical applications like Exchange Online or\r\nSharePoint, the device used should be known by the organization. Utilizing compliance tools like Intune in\r\ncombination with device based conditional access policies can help to keep devices up to date with patches,\r\nantivirus definitions, and EDR solutions. Allowing only known devices that adhere to Microsoft’s recommended\r\nhttps://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nPage 4 of 7\n\nsecurity baselines helps mitigate the risk of commodity credential theft malware being able to compromise end\r\nuser devices.\r\nFor those devices that remain unmanaged, consider utilizing session conditional access policies and other\r\ncompensating controls to reduce the impact of token theft:\r\nReducing the lifetime of the session increases the number of times a user is forced to re-authenticate but\r\nminimizes the length of time session token is viable.\r\nReducing the viable time of a token forces threat actors to increase the frequency of token theft attempts\r\nwhich in turn provides defenders with additional chances at detection.\r\nImplement Conditional Access App Control in Microsoft Defender for Cloud Apps for users connecting\r\nfrom unmanaged devices.\r\nProtect your users by blocking initial access:\r\nPlan and implement phishing resistant MFA solutions such as FIDO2 security keys, Windows Hello for\r\nBusiness, or certificate-based authentication for users.\r\nWhile this may not be practical for all users, it should be considered for users of significant\r\nprivilege like Global Admins or users of high-risk applications.\r\nUsers that hold a high level of privilege in the tenant should have a segregated cloud-only identity for all\r\nadministrative activities, to reduce the attack surface from on-premises to cloud in the event of on-premises\r\ndomain compromise and abuse of privilege. These identities should also not have a mailbox attached to\r\nthem to prevent the likelihood of privileged account compromise via phishing techniques.\r\nWe recognize that while it may be recommended for organizations to enforce location, device compliance, and\r\nsession lifetime controls to all applications it may not always be practical. Decisionmakers should instead focus on\r\ndeploying these controls to applications and users that have the greatest risk to the organization which may\r\ninclude:\r\nHighly privileged users like Global Administrators, Service Administrators, Authentication Administrators,\r\nand Billing Administrators among others.\r\nFinance and treasury type applications that are attractive targets for attackers seeking financial gain.\r\nHuman capital management (HCM) applications containing personally identifiable information that may be\r\ntargeted for exfiltration.\r\nControl and management plane access to Microsoft 365 Defender, Azure, Office 365 and other cloud app\r\nadministrative portals.\r\nAccess to Office 365 services (Exchange, SharePoint, and Teams) and productivity-based cloud apps.\r\nVPN or remote access portals that provide external access to organizational resources.\r\nDetect\r\nWhen a token is replayed, the sign-in from the threat actor can flag anomalous features and impossible travel\r\nalerts. Azure Active Directory Identity Protection and Microsoft Defender for Cloud Apps both alert on these\r\nevents. Azure AD Identity Protection has a specific detection for anomalous token events. The token anomaly\r\nhttps://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nPage 5 of 7\n\ndetection in Azure AD Identity Protection is tuned to incur more noise than other alerts. This helps ensure that\r\ngenuine token theft events aren’t missed.\r\nDART recommends focusing on high severity alerts and focusing on those users who trigger multiple alerts\r\nrapidly. Detection rules that map to the MITRE ATT\u0026CK framework can help detect genuine compromise. For\r\nexample, a risky sign-in followed closely by indicators of persistence techniques, such as mailbox rule creation.\r\nResponse and investigation\r\nIf a user is confirmed compromised and their token stolen, there are several steps DART recommends evicting the\r\nthreat actor. Azure AD provides the capability to revoke a refresh token. Once a refresh token is revoked, it’s no\r\nlonger valid. When the associated access token expires, the user will be prompted to re-authenticate. The\r\nfollowing graphic outlines the methods by which access is terminated entirely:\r\nFigure 5. Refresh token revocation by type\r\nIt’s crucial to use both the Azure AD portal, Microsoft Graph, or Azure AD PowerShell in addition to resetting the\r\nusers’ passwords to complete the revocation process.\r\nImportantly, revoking refresh tokens via the above methods doesn’t invalidate the access token immediately,\r\nwhich can still be valid for up to an hour. This means the threat actor may still have access to a compromised\r\nuser’s account until the access token expires. Azure AD now supports continuous access evaluation for Exchange,\r\nSharePoint and Teams, allowing access tokens to be revoked in near real time following a ‘critical event’. This\r\nhelps to significantly reduce the up to one hour delay between refresh token revocation and access token expiry.\r\nMicrosoft DART also recommends checking the compromised user’s account for other signs of persistence. These\r\ncan include:\r\nMailbox rules – threat actors often create specific mailbox rules to forward or hide email. These can\r\ninclude rules to hide emails in folders that are not often used. For example, a threat actor may forward all\r\nemails containing the keyword ‘invoice’ to the Archive folder to hide them from the user or forward them\r\nto an external email address.\r\nMailbox forwarding – email forwarding may be configured to send a copy of all email to an external email\r\naddress. This allows the threat actor to silently retrieve a copy of every email the user receives.\r\nMultifactor authentication modification – DART has detected instances of threat actors registering\r\nadditional authentication methods against compromised accounts for use with MFA, such as phone\r\nnumbers or authenticator apps.\r\nhttps://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nPage 6 of 7\n\nDevice enrollment – in some cases, DART has seen threat actors add a device to an Azure AD tenant they\r\ncontrol. This is an attempt to bypass conditional access rules with exclusions such as known devices.\r\nData exfiltration – threat actors may use the inbuilt sharing functionality in SharePoint and OneDrive to\r\nshare important or sensitive documents and organizational resources externally.\r\nTo strengthen your security posture, you should configure alerts to review high-risk modifications to a tenant.\r\nSome examples of this are:\r\nModification or creation of security configurations\r\nModification or creation of Exchange transport rules\r\nModification or creation of privileged users or roles\r\nIncident responders should review any audit logs related to user activity to look for signs of persistence. Logs\r\navailable in the Unified Audit Log, Microsoft Defender for Cloud Apps, or SIEM solutions like Microsoft Sentinel\r\ncan aid with investigations.\r\nConclusion\r\nAlthough tactics from threat actors are constantly evolving, it is important to note that multifactor authentication,\r\nwhen combined with other basic security hygiene—utilizing antimalware, applying least privilege principals,\r\nkeeping software up to date and protecting data—still protects against 98% of all attacks.\r\nFundamentally, it is important to consider the identity trust chain for the organization, spanning both internally\r\nand externally. The trust chain includes all systems (such as identity providers, federated identity providers, MFA\r\nservices, VPN solutions, cloud-service providers, and enterprise applications) that issue access tokens and grant\r\nprivilege for identities both cloud and on-premises, resulting in implicit trust between them.\r\nIn instances of token theft, adversaries insert themselves in the middle of the trust chain and often subsequently\r\ncircumvent security controls. Having visibility, alerting, insights, and a full understanding of where security\r\ncontrols are enforced is key. Treating both identity providers that generate access tokens and their associated\r\nprivileged identities as critical assets is strongly encouraged.\r\nAdversaries have and will continue to find ways to evade security controls. The tactics utilized by threat actors to\r\nbypass controls and compromise tokens present additional challenges to defenders. However, by implementing the\r\ncontrols presented in this blog DART believes that organizations will be better prepared to detect, mitigate, and\r\nrespond to threats of this nature moving forward.\r\nSource: https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nhttps://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.microsoft.com/en-us/security/blog/2022/11/16/token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft/"
	],
	"report_names": [
		"token-tactics-how-to-prevent-detect-and-respond-to-cloud-token-theft"
	],
	"threat_actors": [],
	"ts_created_at": 1775434750,
	"ts_updated_at": 1775791206,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b538bce85c34e0dfca7490d9155ba6a9a47b0e6d.pdf",
		"text": "https://archive.orkl.eu/b538bce85c34e0dfca7490d9155ba6a9a47b0e6d.txt",
		"img": "https://archive.orkl.eu/b538bce85c34e0dfca7490d9155ba6a9a47b0e6d.jpg"
	}
}