{“lastseen”:”2026-04-17T16:57:59″,”description”:”In this article\\n\\n 1. Predictive shielding overview\\n 2. Attack chain overview\\n 3. How predictive shielding changed the outcome\\n 4. MITRE ATT\\u0026CK\u00ae techniques observed\\n 5. Learn more\\n\\n\\n\\nIn identity-based attack campaigns, any initial access activity can turn an already serious intrusion into a critical incident once it allows a threat actor to obtain domain-administration rights. At that point, the attacker effectively controls the Active Directory domain: they can change group memberships and Access Control Lists (ACLs), mint Kerberos tickets, replicate directory secrets, and push policy through mechanisms like Group Policy Objects (GPOs), among others.\\n\\nWhat makes domain compromise especially challenging is how quickly it could happen: in many real-world cases, domain-level credentials are compromised immediately following the very first access, and once these credentials are exposed, they\u2019re often abused immediately, well before defenders can fully scope what happened. Apart from this speed gap, responding to this type of compromise could also prove difficult. For one, incident responders can\u2019t just simply \u201cturn off\u201d domain controllers, service accounts, or identity infrastructure and core services without risking business continuity. In addition, because compromised credential artifacts can spread fast and be replayed to expand access, restoring the identity infrastructure back to a trusted state usually means taking steps (for example, krbtgt rotation, GPO cleanup, and ACL validation) that could take additional time and effort in an already high-pressure situation.\\n\\nThese challenges highlight the need for a more proactive approach in disrupting and containing credential-based attacks as they happen. Microsoft Defender\u2019s predictive shielding capability in automatic attack disruption helps address this need. Its ability to predict where attacks will pivot next and apply just in time hardening actions to block credential abuse\u2014including those targeting high-privilege accounts like domain admins\u2014and lateral movement at near-real-time speed, shifting the advantageto the defenders.\\n\\nPreviously, we discussed how predictive shielding was able to disrupt a human-operated ransomware incident. In this blog post, we take a look at a real-world Active Directory domain compromise that illustrates the critical inflection point when a threat actor achieves domain -level control. We walk through the technical details of the incident to highlight attacker tradecraft, the operational challenges defenders face after domain compromise, and the value of proactive, exposure-based containment that predictive shielding provides.\\n\\n## Predictive shielding overview\\n\\nPredictive shielding is a capability in Microsoft Defender\u2019s automatic attack disruption that helps stop the spread of identity-based attacks, before an attacker fully operationalizes stolen credentials. Instead of waiting for an account to be observed doing something malicious, predictive shielding focuses on moments when credentials are likely exposed: when Defender sees high-confidence signals of credential theft activity on a device, it can proactively restrict the accounts that might have been exposed there.\\n\\nEssentially, predictive shielding works as follows:\\n\\n * Defender detects post-breach activity strongly associated with credential exposure on a device.\\n * It evaluates which high-privilege identities were likely exposed in that context.\\n * It applies **containment** to those identities to reduce the attacker\u2019s ability to pivot, limiting lateral movement paths and high-impact identity operations while the incident is being investigated and remediated. The intent is to close the \u201cspeed gap\u201d where attackers can reuse newly exposed credentials faster than responders can scope, reset, and clean up.\\n\\n\\n\\nThis capability is available as an out-of-the-box enhancement for Microsoft Defender for Endpoint P2 customers who meet the Microsoft Defender prerequisites.\\n\\nThe following section revisits a real-world domain compromise that showcases how attack disruption and predictive shielding changed the outcome by acting on exposure, rather than just observed abuse. Interestingly, this case happened just as we\u2019re rolling out the predictive shielding, so you can see the changes in both attacker tradecraft and the detection and response actions before and after this capability was deployed.\\n\\n## Attack chain overview\\n\\nIn June 2025, a public sector organization was targeted by a threat actor. This threat actor progressed methodically: initial exploitation, local escalation, directory reconnaissance, credential access, and expansion into Microsoft Exchange and identity infrastructure. \\n\\n_Figure 1. Attack diagram of the domain compromise_.\\n\\n### Initial entry: Pre-domain compromise\\n\\nThe campaign began at the edge: a file-upload flaw in an internet-facing Internet Information Services (IIS) server was abused to plant and launch a web shell. The attacker then simultaneously performed various reconnaissance activities using the compromised account through the web shell and escalated their privileges to NT AUTHORITY\\\\SYSTEM by abusing a Potato-class token impersonation primitive (for example, BadPotato).\\n\\nThe discovery commands observed in the attack include the following example:\\n\\n\\n\\nUsing the compromised IIS service account, the attacker attempted to reset the passwords of high-impact identities, a common technique used to gain control over accounts without performing credential dumping. The attacker also deployed Mimikatz to dump logon secrets (for example, MSV, LSASS, and SAM), harvesting credentials that are exposed on the device.\\n\\n \\n\\nHad predictive shielding been released at this point, automated restrictions on exposed accounts could have stopped the intrusion before it expanded beyond the single-host foothold. However, at the time of the incident, this capability hasn\u2019t been deployed to customers yet.\\n\\n**Key takeaway:** At this stage of an attack, it\u2019s important to keep the containment host\u2011scoped. Defenders should prioritize blocking credential theft and stopping escalation before it reaches the identity infrastructure.\\n\\n### First pivot: Directory credential materialization and Exchange delegation\\n\\nWithin 24 hours, the attacker abused privileged accounts and remotely created a scheduled task on a domain controller. The task initiated NTDS snapshot activity and packaged the output using makecab.exe, enabling offline access to directory credential material that\u2019s suitable for abusing credentials at scale:\\n\\n\\n\\nBecause the first malicious action by the abused account already surfaced the entire Active Directory credentials, stopping its path for total domain compromise was no longer feasible.\\n\\nThe threat actor then planted a Godzilla web shell on Exchange Server, used a privileged context to enumerate accounts with _ApplicationImpersonation_ role assignments, and granted full access to a delegated principal across mailboxes using _Add\u2011MailboxPermission_. This access allowed the threat actor to read and manipulate all mailbox contents.\\n\\nThe attack also used Impacket\u2019s _atexec.py_ to enumerate the role assignments remotely. Its use triggered the attack disruption capability in Defender, revoking the account sessions of an admin account and blocking it from further use.\\n\\n\\n\\nFollowing the abused account\u2019s disruption, the attacker attempted several additional actions, such as resetting the disrupted account\u2019s and other accounts\u2019 passwords. They also attempted to dump credentials of a Veeam backup device.\\n\\n**Key takeaway:** This pivot is a turning point. Once directory credentials and privileged delegation are in play, the scope and impact of an incident expand fast. Defenders should prioritize protecting domain controllers, privileged identities, and authentication paths.\\n\\n### Scale and speed: Tool return, spraying, and lateral movement\\n\\nWeeks later, the threat actor returned with an Impacket tooling (for example, secretsdump and PsExec) that resulted in repeated disruptions by Defender against the abused accounts that they used. These disruptions forced the attacker to pivot to other compromised accounts and exhaust their resources.\\n\\nFollowing Defender\u2019s disruptions, the threat actor then launched a broad password spray from the initially compromised IIS server, unlocking access to at least 14 servers through password reuse. They also attempted remote credential dumping against a couple of domain controllers and an additional IIS server using multiple domain and service principals.\\n\\n**Key takeaway:** Even though automatic attack disruption acted right away, the attacker already possessed multiple credentials due to the previous large-scale credential dumping. This scenario showcases the race to detect and disrupt credential abuse and is the reason we\u2019re introducing predictive shielding to preemptively disrupt exposed accounts at risk.\\n\\n### Predictive shielding breaks the chain: Exposure-centric containment\\n\\nIn the second phase of the attack, we activated predictive shielding. When exposure signals surfaced (for example, credential dumping attempts and replay from compromised hosts), automated containment blocked new sign-in attempts and interactive pivots not only for the abused accounts, but also for context-linked identities that are active on the same compromised surfaces.\\n\\nAttack disruption contained high-privileged principals to prevent these accounts from being abused. Crucially, when a high-tier Enterprise or Schema Admin credential was exposed, predictive shielding contained it pre-abuse, preventing what would normally become a catastrophic escalation.\\n\\n### Second pivot: Alternative paths to new credentials\\n\\nWith high-value identities pre-contained, the threat actor pivoted to exploiting Apache Tomcat servers. They compromised three Tomcat servers, dropped the Godzilla web shell, and launched the PowerShell-based _Invoke-Mimikatz_ command to harvest additional credentials. At one point, the attacker operated under Schema Admin:\\n\\n\\n\\nThey then used Impacket _WmiExec_ to access Microsoft Entra Connect servers and attempt to extract Entra Connect synchronization credentials. The account used for this pivot was later contained, limiting further lateral movement.\\n\\n### Last attempts and shutdown\\n\\nIn the final phase of the attack, the threat actor attempted a full LSASS dump on a file sharing server using _comsvcs.dll MiniDump_ under a domain user account, followed by additional NTDS activity:\\n\\n\\n\\nAttack disruption in Defender repeatedly severed sessions and blocked new sign-ins made by the threat actor. On July 28, 2025, the attack campaign lost momentum and stopped.\\n\\n## How predictive shielding changed the outcome\\n\\nBefore compromising a domain, attackers are mostly constrained by the hosts they control. However, even a small set of exposed credentials could remove their constraints and give them broad access through privileged authentication and delegated pathways. The blast radius spreads fast, time pressure spikes, and containment decisions become riskier because identity infrastructure and high-privilege accounts are production dependencies.\\n\\nThe incident we revisited earlier almost followed a similar pattern. It unfolded while predictive shielding was still being launched, so the automated predictive containment capability only became active at the midway of the attack campaign. During the attack\u2019s first stages, the threat actor had room to scale\u2014they returned with new tooling, launched a broad password spray attack, and expanded access across multiple servers. They also attempted remote credential dumping against domain controllers and servers.\\n\\nWhen predictive shielding went live, it helped shift the story and we then saw the change of pace\u2014instead of reacting to each newly abused account, the capability allowed Defender to act preemptively and turn credential theft attempts into blocked pivots. Defender was able to block new sign-ins and interactive pivots, not just for the single abused account, but also for context-linked identities that were active on the same compromised surfaces.\\n\\nWith high-value identities pre-contained, the adversary shifted tradecraft and chased other credential sources, but each of their subsequent attempts triggered targeted containment that limited their lateral reach until they lost momentum and stopped. How this incident concluded is the operational \u201ctell\u201d that containment is working, in that once privileged pivots get blocked, threat actors often hunt for alternate credential sources, and defenses must continue following the moving blast radius.\\n\\nAs predictive shielding matures, it will continue to expand its prediction logic and context-linked identities.\\n\\n## MITRE ATT\\u0026CK\u00ae techniques observed\\n\\nThe following table maps observed behaviors to ATT\\u0026CK\u00ae. \\n\\n_Tactics shown are per technique definition._\\n\\n**Tactic(s)**| **Technique ID**| **Technique name**| **Observed details** \\n—|—|—|— \\nInitial Access| T1190| Exploit Public-Facing Application| Exploited a file-upload vulnerability in an IIS server to drop a web shell. \\nPersistence| T1505.003| Server Software Component: Web Shell| Deployed web shells for persistent access. \\nExecution| T1059.001| Command and Scripting Interpreter: PowerShell| Used PowerShell for Exchange role queries, mailbox permission changes, and Invoke-Mimikatz. \\nPrivilege Escalation| T1068| Exploitation for Privilege Escalation| Used BadPotato to escalate to SYSTEM on an IIS server. \\nCredential Access| T1003.001| OS Credential Dumping: LSASS Memory| Dumped LSASS using Mimikatz and _comsvcs.dll MiniDump_. \\nCredential Access| T1003.003| OS Credential Dumping: NTDS| Performed NTDS-related activity using ntdsutil snapshot\/IFM workflows on a domain controller. \\nExecution; Persistence; Privilege Escalation| T1053.005| Scheduled Task\/Job: Scheduled Task| Created remote scheduled tasks to execute under SYSTEM on a domain controller. \\nDiscovery| T1087.002| Account Discovery: Domain Account| Enumerated domain groups and accounts using net group and AD Explorer. \\nLateral Movement| T1021.002| Remote Services: SMB\/Windows Admin Shares| Used admin shares\/SMB-backed tooling (for example, PsExec) for lateral movement. \\nLateral Movement| T1021.003| Remote Services: Windows Remote Management| Used WmiExec against Microsoft Entra Connect servers. \\nCredential Access| T1110.003| Brute Force: Password Spraying| Performed password spraying leading to access across at least 14 servers. \\nCollection| T1114.002| Email Collection: Remote Email Collection| Expanded mailbox access broadly through impersonation or permission changes. \\nCommand and Control| T1071.001| Application Layer Protocol: Web Protocols| Web shells communicated over HTTP\/S. \\nDefense Evasion| T1070.004| Indicator Removal on Host: File Deletion| Used cleanup scripts (for example, _del.bat_) to remove dump artifacts. \\nPersistence; Privilege Escalation| T1098| Account Manipulation| Manipulated permissions and roles to expand access and sustain control. \\nCredential Access| T1078| Valid Accounts| Reused compromised service and domain accounts for access and lateral movement. \\n \\n## Learn more\\n\\n**For more information about automatic attack disruption and predictive shielding, see the following Microsoft Learn articles:**\\n\\n * Check out our latest Ninja show showcasing how predictive shielding expands to identity centric attacks\\n * Automatic attack disruption in Microsoft Defender XDR\\n * Predictive shielding in Microsoft Defender (Preview)\\n\\n\\n\\nThe post Containing a domain compromise: How predictive shielding shut down lateral movement appeared first on Microsoft Security Blog.”,”published”:”2026-04-17T14:51:01″,”modified”:”2026-04-17T14:51:01″,”type”:”mssecure”,”title”:”Containing a domain compromise: How predictive shielding shut down lateral movement”,”source”:””,”references”:””,”id”:”MSSECURE:CD98CFEAEA319651AC7FD506BC66D993″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/www.microsoft.com\/en-us\/security\/blog\/2026\/04\/17\/domain-compromise-predictive-shielding-shut-down-lateral-movement\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-17T16:57:59″,”description”:”In this article\\n\\n 1. Predictive shielding overview\\n 2. Attack chain overview\\n 3. How predictive shielding changed the outcome\\n 4. MITRE ATT\\u0026CK\u00ae techniques observed\\n 5. Learn…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,110,13,33,7,11,5],"class_list":["post-47651","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-mssecure","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n