{
	"id": "a6120674-0efd-496b-b78d-105ff2cdbd59",
	"created_at": "2026-04-06T02:12:52.96959Z",
	"updated_at": "2026-04-10T03:20:54.839644Z",
	"deleted_at": null,
	"sha1_hash": "946bb44679d66b8f12f22c2ec484d8894a09f90d",
	"title": "Detecting Microsoft 365 and Azure Active Directory Backdoors | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2640059,
	"plain_text": "Detecting Microsoft 365 and Azure Active Directory Backdoors |\r\nMandiant\r\nBy Mandiant\r\nPublished: 2020-09-30 · Archived: 2026-04-06 01:38:56 UTC\r\nWritten by: Mike Burns\r\nMandiant has seen an uptick in incidents involving Microsoft 365 (M365) and Azure Active Directory (Azure\r\nAD). Most of these incidents are the result of a phishing email coercing a user to enter their credentials used for\r\naccessing M365 into a phishing site. Other incidents have been a result of password spraying, password stuffing,\r\nor simple brute force attempts against M365 tenants. In almost all of these incidents, the user or account was not\r\nprotected by multi-factor authentication (MFA).\r\nThese opportunistic attacks are certainly the most common form of compromise for M365 and Azure AD, and are\r\nusually the initial vector to establish persistence. During both incident response (IR) engagements and proactive\r\ncloud assessments we are often asked:\r\nWhat are some other types of attacks that Mandiant is seeing against M365 and Azure AD?\r\nIs it possible for an on-premises compromise to “vertically” move to M365 and Azure AD?\r\nIf a global administrator account is compromised, is it possible to maintain persistence even after the\r\ncompromised account has been detected, a password reset has occurred, and MFA has been applied?\r\nAADInternals PowerShell Module\r\nIn some incidents, Mandiant has witnessed attackers utilizing a PowerShell module called AADInternals, which\r\ncan allow an attacker to vertically move from on-premises to Azure AD, establish backdoors, steal passwords,\r\ngenerate user security tokens, and bypass MFA protections. This PowerShell module has allowed attackers to\r\nmaintain persistence in the tenant even after initial eradication efforts were conducted.\r\nTo see this module in action and understand how it works, Dr. Nestori Syynimaa’s PSCONFEU 2020 presentation,\r\nAbusing Azure Active Directory: Who would you like to be today?, provides an in-depth overview of the module.\r\nTo detect the use of AADInternals, it is important to understand how some of these attacks work. Once an\r\nunderstanding is established, abnormal usage can be detected through a combination of log analysis and host-based indicators.\r\nBackdoor 1: Abusing Pass-Through Authentication\r\nAttacker Requirements\r\nLocal Administrative Access to a server running Pass-through Authentication\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 1 of 18\n\nOr\r\nM365 global administrator credentials\r\nThe AADInternals PowerShell module contains a function called Install-AADIntPTASPY. The function works by\r\ninserting itself as a man-in-the-middle within the Pass-through Authentication (PTA) process that occurs between\r\nAzure AD and the server running the PTA Agent in the on-premises environment. Commonly, the PTA Agent runs\r\non the same on-premises server as Azure AD Connect (AAD Connect).\r\nWhen PTA is enabled, every logon that occurs against Azure AD gets redirected to the PTA Agent on-premises.\r\nThe PTA Agent asks an on-premises Active Directory Domain Controller if a password is valid for an\r\nauthenticating account. If valid, the PTA Agent responds back to Azure AD to grant the requestor access. Figure 1\r\nprovides the workflow of Pass-through Authentication and where AADInternals can intercept the request.\r\nFigure 1: Pass-through Authentication workflow\r\nOnce the function is running, every PTA attempt against Azure AD will be intercepted by the installed\r\nAADIntPTASpy module. The module will record the user’s password attempt and reply back to Azure AD on\r\nbehalf of the PTA Agent. This reply advises Azure AD the password attempt was valid and grants the user access\r\nto the cloud, even if the password is incorrect. If an attacker has implanted AADIntPTASpy, they can log in as any\r\nuser that attempts to authenticate using PTA—and will be granted access.\r\nAdditionally, all password attempts that are registered by the AADIntPTASpy module are recorded within a log\r\nfile on the server (Default location: C:\\PTASpy\\PTASPy.csv). Figure 2 shows how the log file can be decoded to\r\nreveal a user’s password in cleartext.\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 2 of 18\n\nFigure 2: PTASpy.csv decoded passwords\r\nNot only will this function allow an attacker to login as any user who authenticates via PTA, but it will also act as\r\na repository for collecting user passwords who are legitimately logging into Azure AD. This could allow an\r\nattacker to pivot their attack to other areas of the network—or use these credentials against other internet\r\naccessible portals that may leverage single-factor authentication (e.g., VPN gateway).\r\nAn attacker can use this module in one of two ways:\r\nMethod 1: On-Premises Compromise\r\nAn attacker has gained access to an on-premises domain and is able to laterally move to the AADConnect / PTA\r\nAgent Server. From this server, an attacker can potentially leverage the AADInternals PowerShell module and\r\ninvoke the Install-AADIntPTASpy function.\r\nMethod 2: Cloud Compromise\r\nIf an attacker has successfully compromised an Azure AD global admin account, an attack can be conducted from\r\nan attacker’s own infrastructure. An attacker can install a PTA Agent on a server they manage and register the\r\nagent using the compromised global administrator account (Figure 3).\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 3 of 18\n\nFigure 3: Azure AD Portal—registered Pass-through Authentication agents\r\nOnce registered with Azure AD, the rogue server will begin to intercept and authorize all login attempts. As with\r\nMethod 1, this server can also be used to harvest valid credentials.\r\nBackdoor 2: Abusing Identity Federation\r\nAttacker Requirements\r\nLocal administrative access to AD and server running Active Directory Federation Services\r\nOr\r\nM365 global administrator credentials\r\nAnother method of authenticating to M365 is through the usage of federation services. When a M365 domain is\r\nconfigured as a federated domain, a trust is configured between M365 and an external identify provider. In many\r\ncases, this trust is established with an Active Directory Federation Services (ADFS) server for an on-premises\r\nActive Directory domain.\r\nOnce a trust is established, when a user logs into M365 using a federated domain, their request is redirected to the\r\nexternal identify provider (ADFS) where their authentication is validated (Figure 4). Once validated, the ADFS\r\nserver provides the user a security token. This token is then trusted by M365 and grants the access to the platform.\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 4 of 18\n\nFigure 4: Microsoft 365 Federation Sign-in workflow\r\nAADInternals has a PowerShell function to craft security tokens, which mimics the ADFS authentication process.\r\nWhen providing the function a valid UserPrincipalName, Immutable ID and IssuerURI, an attacker can generate a\r\nsecurity token as any user of the tenant. What’s even more concerning is that once this security token is generated,\r\nthis can allow an attacker to bypass MFA.\r\nAs with Backdoor 1, this attack can either be performed from a compromised on-premises environment or from an\r\nattacker’s own infrastructure.\r\nMethod 1: On-Premises Compromise\r\nOnce an attacker has gained access to an on-premises domain with elevated access, they can begin to collect the\r\nrequired information to craft their own security tokens to backdoor into M365 as any user. An attacker will\r\nrequire:\r\nA valid UserPrincipalName and Immutable.\r\nBoth of these attributes can be pulled from the on-premises Active Directory domain.\r\nIssuerURI of the ADFS server and ADFS Signing certificate.\r\nThis can be obtained from an ADFS server when directly logged into the server or remotely\r\nquerying the server via an privileged account.\r\nOnce an attacker has collected the necessary information, using the AADInternals Open-AADIntOffice365Portal\r\ncommand, a security token for the user can be generated granting an attacker access to M365 (Figure 5).\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 5 of 18\n\nFigure 5: AADInternals Open-AADIntOffice365Portal command\r\nMethod 2: Cloud Compromise\r\nIf an attacker has a compromised an M365 Global Administrator account, using their own infrastructure, an\r\nattacker can use their administrative access to collect user information and reconfigure the tenant to establish their\r\nbackdoor. In this method, an attacker will require:\r\nA valid UserPrincipalName and valid ImmutableId.\r\nFigure 6 shows how the Get-MsolUser command can obtain a user’s ImmutableId from Azure AD.\r\nFigure 6: Get-MsolUser—list user UPN \u0026 ImmutableId\r\nIssuerURI\r\nThis can be obtained by converting a managed domain to a federated domain. Figures 7 through 10\r\nshow how the AADInternals ConvertTo-AADIntBackdoor command (Figure 8) can be used to\r\nallow attacker to register their own IssuerURI for a federated domain.\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 6 of 18\n\nFigure 7: Get-msoldomain—list of registered domains and authentication\r\nFigure 8: ConvertTo-AADIntBackdoor—convert domain to federated authentication\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 7 of 18\n\nFigure 9: Changed authentication method\r\nFigure 10: Azure AD Portal registered domains\r\nNote: To not interrupt production and authentication with an existing federated domain (and to remain\r\nundetected), an attacker may opt to register a new domain with the tenant.\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 8 of 18\n\nFigure 11: AADInternals Open-AADIntOffice365Portal Command using new Federated domain\r\nOnce an attacker has properly configured the tenant, using the ImmutableId of any user, a security token can be\r\ngenerated by executing the Open-AADIntOffice365Portal command (Figure 11). This will allow an attacker to\r\nlogin as that user without the need for a valid certificate or a legitimate IssuerURI.\r\nFortunately for defenders, this method will generate a number of events in the unified audit log, which can be\r\nleveraged for monitoring and alerting.\r\nMitigation and Detection\r\nOnce persistence is established, it can be extremely difficult to detect login activity that is utilizing one of the\r\npreviously described methods. In lieu of this, it is recommended to monitor and alert on M365 unified audit logs\r\nand Azure AD sign-in activity to detect anomalous activity.\r\nDetection in FireEye Helix\r\nBeing that Mandiant has seen this methodology being used in the wild, we felt it was necessary to build these\r\ndetections into our FireEye Helix security platform. Helix engineers have created sever new detection rules that\r\nmonitor for detectable activity of an attacker making use of the AADInternals PowerShell module.\r\nThe following five rules will monitor a server’s event logs and alert upon the installation and usage of the\r\nAADInternals PowerShell module (Figure 12). The detection of these activities could be high fidelity alerts that\r\nan attacker is preparing to configure backdoors into M365 and Azure AD environments.\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 9 of 18\n\nFigure 12: AADInternals Helix rules\r\nIf an attacker has successfully configured a backdoor using AADInternals, Helix will alert upon the following\r\nevents registered in the Office 365 unified audit log and Azure Activity Log as indication of a possible event\r\n(Figure 13 and Figure 14). It is important to note that these alerts could be triggered upon legitimate administrator\r\nactivity. When responding to these alerts, first check with your M365 and Azure AD administrator to verify the\r\nactivity before raising a security event.\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 10 of 18\n\nFigure 13: Office 365 and Azure Helix rules\r\nFigure 14: PTA Connector Registered alert description\r\nHunting for Backdoors in M365 Unified Audit Logs and Azure AD Logs\r\nIf you suspect a global administrator account was compromised and you want to review Azure AD for indicators\r\nof potential abuse, the following should be reviewed (note that these same concepts can be used for proactive log\r\nmonitoring):\r\nFrom Azure AD Sign-ins logs, monitor logon activity from On-Premises Directory Synchronization\r\nService Accounts. This account is used by the Azure AD Connect service (Figure 15).\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 11 of 18\n\nFigure 15: Azure AD Sign-ins\r\nBaseline the IP addresses used by this account and make sure the IPs match those assigned to the on-premises WAN infrastructure. If the attacker has configure a PTA Agent on their own infrastructure, seeing\r\nan IP that does not match your baseline could be an indicator that a rogue PTA Agent has been configured\r\nby the attacker (Figure 16).\r\nFigure 16: Azure AD Sign-in logs—On-Premises Directory Synchronization Services account\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 12 of 18\n\nFrom Azure AD Sign-ins, monitor and baseline Azure AD Sign-ins to the Azure AD Application Proxy Connector.\r\nMake sure to validate username, IP and location.\r\nThese events are typically only generated when a new PTA agent is connected to the tenant. This could be an\r\nindicator that an attacker has connected a rogue PTA server hosted on an attacker’s infrastructure (Figure 17).\r\nFigure 17: Azure AD Sign-in logs—Azure AD Application Proxy Connector\r\nIf using Azure Sentinel, this event will also be registered in the Azure AuditLogs table as a “Register Connector”\r\nOperationName (Figure 18).\r\nFigure 18: Register Connector—Azure Sentinel logs\r\nIn the Azure Management Portal under the Azure AD Connect blade, review all registered servers running\r\nPTA Agent. The Authentication Agent and IP should match your infrastructure (Figure 19).\r\nLog in to https://portal.azure.com\r\nSelect Azure AD Connect \u003e Pass-through Authentication\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 13 of 18\n\nFigure 19: Azure Active Directory Pass-through Authentication agent status\r\nMonitor and alert for \"Directory Administration Activity\" in Office 365 Security \u0026 Compliance Center’s\r\nunified audit log. When an attacker is able to create a domain federation within a compromised cloud\r\ntenant, and link this to attacker-owned infrastructure, this will generate activity in the log (Figure 21).\r\nhttps://Protections.office.com/unifiedauitlog \u003e Audit Log Search\r\nSelect Directory Administration Activates category to select all activities\r\nCreate New Alert Policy (Figure 20)\r\nFigure 20: Unified Audit Log \u003e Create new alert policy\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 14 of 18\n\nFigure 21: Unified Audit Log filtered for domain related events\r\nUsing Azure Sentinel, more granular Directory Administration Activities can be modified for suspicious\r\nactivity. This includes additions, deletions and modifications of domains and their authentication settings\r\n(Figure 22).\r\nMonitoring for OfficeActivity Operations in Azure Sentinel can allow an organization to validate if\r\nthis is normalized activity or if an attacker is working on setting up a backdoor for PTA or\r\nfederation.\r\nTable: OfficeActivity\r\nOperation: Set-AcceptedDomain\r\nOperation: Set-MsolDomainFederationSettings\r\nOperation: Add-FederatedDomain\r\nOperation: New-Accepted Domain\r\nOperation: Remove-Accepted Domain\r\nOperation: Remove-FederatedDomain\r\nFigure 22: OfficeActivity Operations Azure Sentinel logs\r\nDetection On-Premises\r\nIf an attacker is able to compromise on-premises infrastructure and access a server running AD Connect or ADFS\r\nservices with the intention of leveraging a tool such as AADInternals to expand the scope of their access to\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 15 of 18\n\ninclude cloud, timely on-premises detection and containment is key. The following methods can be leveraged to\r\nensure optimized visibility and detection for the scope of activities described in this post:\r\nTreat ADFS and Azure AD Connect servers as Tier 0 assets.\r\nUse a dedicated server for each. Do not install these roles and server in addition to other. All too\r\noften we are seeing Azure AD Connect running on a file server.\r\nEnsure PowerShell logging is optimized on AD Connect and ADFS servers\r\nReview Microsoft-Windows-PowerShell/Operational logs on ADFS and AADConnect Server Logs.\r\nIf PowerShell logging is enabled, search for Event ID 4101. This event ID will record the event\r\nwhere AADInternals was installed (Figure 23).\r\nFigure 23: EventID 410—Installed Module\r\nAdditionally, with this logging enabled, you will be able to review the PowerShell commands used by an\r\nattacker.\r\nIn PowerShell, run Get-Module -All and look for the presence of AADInternals (Figure 24).\r\nFigure 24: Get-Module command to list installed modules\r\nAlert for the presence of C:\\PTASpy and C:\\PTASpy\\PTASpy.csv.\r\nThis is the default location of the log file that contains records of all the accounts that were\r\nintercepted by the tool. Remember, an attacker may also use this to harvest credentials, so it is\r\nimportant to reset the password for these accounts (Figure 25).\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 16 of 18\n\nFigure 25: PTASpy.csv log activity\r\nMitigations\r\nIn order for this attack to be successful, an attacker must gain administrative privileges on a server running Azure\r\nAD Connect and/or gain global administrator rights within M365. Simple practices such as limiting and properly\r\nprotecting global administrator accounts as well as properly protecting Tier 0 assets can greatly reduce the risk of\r\nan attacker successfully using the AADInternals PowerShell against your organization.\r\nLimit or restrict access to Azure AD Connect servers.\r\nAny server acting as an identity provider or facilitating identity federation should be treated as a\r\nTier 0 asset.\r\nCreate separate dedicated global administrator accounts.\r\nGlobal administrators should be cloud-only accounts.\r\nThese accounts should not retain any licensing.\r\nImplement MFA on all accounts: admins, users and services.\r\nIf a particular account cannot use MFA, apply a conditional access rule that limits its logon to a\r\ntrusted network. This works particularly well for service accounts.\r\nEstablish a roadmap to block legacy authentication.\r\nLimit which accounts are synced from on-premises to the cloud.\r\nDo not sync privileged or service accounts to the cloud.\r\nUse Azure administrative roles.\r\nNot everybody or everything needs to be a global admin to administer the environment.\r\nUse password hash sync over Pass-through Authentication.\r\nMany organizations are reluctant to sync their password to Azure AD. The benefits from this service\r\ngreatly outweigh the risks. Being able to use global and custom banned passwords lists, for both the\r\ncloud and on-premises, is a tremendous benefit.\r\nForward all M365 unified audit logs and Azure logs to a SIEM and build detections.\r\nEnsure you are forwarding the logs recommended in this post and building the appropriate\r\ndetections and playbooks within your security operations teams.\r\nSpecifically monitor for:\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 17 of 18\n\nSet-AcceptedDomain\r\nSet-MsolDomainFederationSettings\r\nAdd-FederatedDomain\r\nNew-Accepted Domain\r\nRemove-Accepted Domain\r\nRemove-FederatedDomain\r\nPeriodically review all identity providers and custom domains configured in the M365 tenant.\r\nIf an attacker is successful at gaining global administrative privileges, they may choose to add their\r\nown identity provider and custom domain to maintain persistence.\r\nAcknowledgements\r\nI want to give a special thanks to Daniel Taylor, Roberto Bamberger and Jennifer Kendall at Microsoft for\r\ncollaborating with Mandiant on the creation of this blog post.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nhttps://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.mandiant.com/resources/detecting-microsoft-365-azure-active-directory-backdoors"
	],
	"report_names": [
		"detecting-microsoft-365-azure-active-directory-backdoors"
	],
	"threat_actors": [],
	"ts_created_at": 1775441572,
	"ts_updated_at": 1775791254,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/946bb44679d66b8f12f22c2ec484d8894a09f90d.pdf",
		"text": "https://archive.orkl.eu/946bb44679d66b8f12f22c2ec484d8894a09f90d.txt",
		"img": "https://archive.orkl.eu/946bb44679d66b8f12f22c2ec484d8894a09f90d.jpg"
	}
}