Lesson 63 — Do We Disable the Account?
The endpoint had been isolated.
But the user's cloud activity continued.
A suspicious session was still active.
SharePoint activity had appeared.
The account had access to finance systems.
Someone said:
“Disable the account. Problem solved.”
Agent Foskett looked at the timeline.
“Maybe. But first tell me what disabling it actually contains.”
What exactly are you trying to stop?
Assess active sessions, privilege, cloud access, persistence and business impact before choosing identity containment.
Case briefing
Investigation objective
Assess whether disabling a user account is the appropriate identity containment action by examining active access, sessions, privilege, persistence, business impact and the specific behaviour the response must stop.
Investigator's rule
Do not choose the containment action first. Define the access you need to stop first.
Stage 1 — identify the containment objective
Identity containment has layers
An identity can have credentials, active sessions, authentication methods, privileges, delegated permissions and application relationships. Effective containment considers which of those paths the attacker may be using.
Account disablement is powerful
Blocking an account can interrupt legitimate and malicious use, but the SOC still needs to understand related sessions, persistence and application access rather than assuming one control has erased the incident.
Stage 2 — establish the identity timeline
CloudAppEvents
| where Timestamp > ago(1d)
| where AccountId =~ "mia@contoso.com"
| project Timestamp,
AccountId,
Application,
ActionType,
IPAddress,
UserAgent,
RawEventData
| order by Timestamp ascLook beyond the original sign-in
The identity timeline should show what happened after authentication: application activity, mailbox interaction, file access, sharing and other cloud actions.
Endpoint isolation does not contain cloud identity
If cloud activity continues after the endpoint is isolated, the attacker may have another session, another device, application access or some other identity path that requires separate containment.
Stage 3 — ask whether the account is still being used
Separate new authentication from session use
Distinguish a fresh sign-in from activity produced through an already established session or application context. That distinction can affect which containment actions are necessary.
No new sign-in does not mean safe
Cloud activity can continue without a new interactive authentication event. Follow the activity itself rather than waiting for another sign-in alert.
Stage 4 — assess privilege and blast radius
| Account context | Why it matters |
|---|---|
| Standard user | Risk may centre on the user's data, applications and delegated access. |
| Finance / sensitive-data user | Business and confidentiality impact may be significant. |
| Privileged administrator | Attacker capability and potential tenant impact increase sharply. |
| Service-linked identity | Containment may interrupt automated processes or integrations. |
| Executive account | High-value data and impersonation risk may be present. |
| Shared or operational identity | Disabling may affect multiple users or business processes. |
Privilege increases urgency
If the identity can change security controls, manage users, access broad data or grant permissions, the cost of leaving attacker access available can rise dramatically.
Privilege also changes recovery
A privileged compromise may require broader review of changes made while access was available, not simply credential reset and re-enable.
Stage 5 — consider the containment options
| Response option | Purpose to consider |
|---|---|
| Block / disable account | Prevent normal account use while investigation and recovery continue. |
| Revoke sessions | Interrupt existing authenticated session access according to platform behaviour. |
| Reset credentials | Replace credentials believed to be exposed. |
| Review authentication methods | Identify unauthorised or attacker-controlled methods. |
| Review privileged access | Remove or control unnecessary elevated capability according to procedure. |
| Review OAuth / app relationships | Identify persistence or access that may not depend on normal user sign-in. |
| Contain related devices | Address endpoints that may still provide attacker access. |
One action may not be enough
Identity containment often uses several coordinated controls. The exact response depends on the evidence, platform behaviour and organisational playbook.
Containment and recovery are different
Stopping current access is containment. Restoring the identity safely — including credentials, methods, permissions and trusted devices — belongs to the recovery process.
Stage 6 — investigate persistence before declaring success
Password reset is not a universal reset button
If the attacker established another authentication method, application permission or persistence mechanism, changing the password alone may not address every access path.
Look for what changed after compromise
Authentication methods, application grants, mailbox configuration and privilege changes made after the suspected access time deserve particular attention.
Stage 7 — assess business impact
Business impact is part of the decision
Identity containment can interrupt work immediately. That consequence should be understood and coordinated — but it should not become a reason to leave credible attacker access active indefinitely.
High-value accounts may justify faster action
The potential impact of attacker access can outweigh the inconvenience of temporary account disruption, particularly when sensitive data or privileged capability is involved.
Stage 8 — preserve identity evidence
Record before and after
Capture enough evidence to show the identity's relevant state before containment and the actions taken during response. This helps later investigators reconstruct what changed.
Do not delay urgent containment for perfect documentation
If active access presents unacceptable risk, follow emergency response procedures. Record what could not be preserved and why.
Stage 9 — make the decision
Explain the decision
The incident record should state why identity containment was necessary, what evidence supported it, which controls were selected and what operational impact was expected.
Use the least ambiguous language
Rather than writing “user disabled because hacked,” document the actual evidence and response: “Identity containment initiated after suspicious cloud activity continued following endpoint isolation.”
Stage 10 — verify containment
Containment must be observed
After response actions, monitor the relevant telemetry for continued activity. A containment request is not the same thing as evidence that attacker access has ended.
Continued activity is a clue
If activity persists, investigate whether another identity, session, application, device or permission relationship is still providing access.
Example identity containment note
Lesson 63 key takeaways
- Define the access you need to stop before choosing the containment action.
- Identity containment can involve accounts, credentials, sessions, authentication methods, privilege and application access.
- Endpoint isolation does not automatically contain cloud identity activity.
- No new interactive sign-in does not mean cloud access has stopped.
- Privilege and access to sensitive data increase potential blast radius.
- Account disablement may need to be combined with other approved containment controls.
- Password reset alone may not address sessions, OAuth access or newly established authentication methods.
- Investigate persistence mechanisms created after suspected compromise.
- Consider business impact, but also state the risk of leaving attacker access available.
- Preserve identity evidence before state-changing actions when circumstances allow.
- Document why containment was chosen and what controls were applied.
- Verify the result through telemetry rather than assuming the incident is contained.
Module 7 — Incident Response: Containment, Evidence & Escalation
Lesson 63 contained the identity. Lesson 64 focuses on a question that must often be answered before remediation changes the environment: which evidence must be preserved?
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 7: Incident Response: Containment, Evidence & Escalation
When should a SOC disable a compromised user account?
Lesson 63 of the Agent Foskett SOC Analyst Academy teaches analysts how to assess identity containment options and consequences when a compromised account remains active across Microsoft cloud services.
Identity containment, sessions, MFA and cloud persistence
Learn how to evaluate active sessions, authentication methods, privilege, OAuth application access, business impact and cloud activity before choosing and verifying identity containment actions.
