Cybersecurity briefing
/
The Account Left Outside Automated Containment
Microsoft described an intrusion where an excluded privileged account stayed usable. Learn how to plan a manual response for exceptions to automation.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
The response system acted, but one account remained available to the attacker. In an investigation published October 30, Microsoft described an intrusion in which automated attack disruption restricted compromised identities while a privileged account excluded from that response remained usable and later supported data exfiltration. The case raises a practical question for security leaders: when an organization deliberately limits automation, who takes responsibility for the work automation will leave undone?
An exclusion can have a legitimate business rationale. It also changes the response the organization can expect during an incident. That difference needs to be understood before an attacker makes use of it.
Business continuity creates a second response path
Microsoft's exclusion documentation explains the tradeoff. Teams can exempt selected assets or actions to avoid disrupting critical operations, although Microsoft warns that exclusions can weaken protection. An account supporting an essential business process may therefore receive different treatment from an ordinary employee identity.
The risk is allowing that exception to disappear into a settings page. A team might know why it avoided automatic disruption without having decided how to contain the same identity manually. During an incident, the person seeing the alert may lack authority to interrupt the business service, while the application owner may not be available.
For a hypothetical overnight financial-processing service, the useful question is specific. If its account is suspected of compromise, can the response team restrict access without abandoning unfinished transactions? If the answer requires the application owner, the escalation route must work outside office hours. A note saying “critical account” supplies neither the decision nor the means to carry it out.
Record the permitted response alongside the reason for the exclusion. Identify who can authorize disruption, what evidence is needed and what happens if that person cannot be reached. Where no workable containment action exists, leadership should see the unresolved exposure explicitly.
Detection coverage and action coverage differ
Security reporting often describes an environment as covered because a product is deployed. Response coverage requires a more detailed account of the action available for each relevant asset.
Microsoft's attack-disruption setup guidance identifies dependencies involving deployed products, permissions and product-specific prerequisites. A signal can be available while a required response path is unavailable or restricted. Buying the appropriate license is one step in establishing that path.
A useful assessment follows a representative incident through the configured controls. Identify the affected account and device, inspect the applicable response settings and establish who can perform the next action. Compare that technical state with the organization's documented plan. Where the plan assumes an action that cannot execute, retain the discrepancy until it is resolved or explicitly accepted.
The assessment should distinguish an intentional exception from an incomplete deployment. They can produce similar operational gaps but require different decisions. An exception needs a defensible alternative; a deployment defect needs corrective work and verification.
Security workflow orchestration connects a configuration finding with the business dependency and authorized action needed to address it. Ottoguard is a security automation platform designed to coordinate work across the tools an organization already owns. It builds objective-driven workflows using connected systems and organizational context, with human approval points and outcome verification. Its configuration-assessment capabilities include evaluating security-tool settings, while its Microsoft Defender and Intune work illustrates the broader role of applying existing controls through governed workflows.
That capability is not evidence that a particular Defender exclusion can be changed automatically. Exact connector permissions and supported actions need validation. A team can begin with assessment and approved follow-up work, retaining manual steps where the required action has not been established. The underlying security products continue to supply detection and enforcement.
Credentials can survive the first cleanup action
The Microsoft case also involved abuse of Active Directory Certificate Services, which can issue certificates used for authentication. An improperly configured certificate template allowed the attacker to obtain certificates representing privileged identities. That made the access problem broader than the initially compromised workstation or password.
Microsoft notes that resetting a password does not revoke an issued authentication certificate. Certificate revocation also does not retroactively invalidate Kerberos tickets already issued. Responders must examine those access mechanisms separately instead of treating a familiar cleanup step as proof that every route has closed.
For workflow design, the consequence is a requirement for explicit completion evidence. A password-reset task may be complete while certificate and ticket review remains open. Preserve those distinctions in the incident record so the next analyst can see what was actually addressed.
Certificate investigation and revocation belong with qualified identity and public-key infrastructure teams. They should not be assumed to be native functions of an orchestration platform. The workflow must identify the responsible specialist and carry the result back into the response record.
Exercise the exception before the emergency
Choose an important excluded identity and rehearse its response path with the business owner. Use an authorized tabletop or controlled test rather than disabling a production service to discover its dependencies.
Ask the team to establish the account's current scope, locate the exclusion and obtain the required approval. Check whether the proposed alternative is technically available and whether its effect could be verified. Time spent finding an owner or obtaining permissions is part of the response delay, even when no technical command has failed.
Microsoft's device-response guidance reinforces the need to inspect action results and device state. Apply the same discipline to the exercise: distinguish a requested action from a completed one, and preserve failures for follow-up.
The business decision is whether the organization can tolerate the remaining access while arranging a safer interruption. Security and operational leaders need to make that decision together. Every retained exclusion should have a response somebody can execute, with evidence that shows when the work is done.
