DET0120: Account Access Removal via Multi-Platform Audit Correlation
DET0120 is a detection strategy for recognizing Account Access Removal (T1531) by correlating audit evidence across environments. The business issue is ava...
Analyst context for executives and security teams
DET0120 is a detection strategy for recognizing Account Access Removal (T1531) by correlating audit evidence across environments. The business issue is availability: if legitimate users, administrators, or SaaS users lose access because accounts are deleted, locked, credential-changed, or permissions revoked, incident response and normal operations can be disrupted at the same time defenders need access most.
Executive priority
Treat this as an operational resilience and identity governance priority. Leaders should ask whether the organization can prove who removed or changed access, where it happened, and whether similar actions occurred across Windows, Linux, macOS, and SaaS environments. This matters for incident decision-making, privileged access assurance, audit evidence, and continuity planning, especially when account access changes affect administrators or critical business users.
Technical view
The supplied ATT&CK object has no official description or detection text, but its name and relationship indicate a strategy focused on multi-platform audit correlation for T1531. SOC and IR teams should validate whether account deletion, lockout, credential change, and permission or role revocation events are collected and normalized across operating systems, directory/identity systems, and SaaS audit sources. Correlation should prioritize unusual timing, volume, privileged targets, cross-platform repetition, and access-removal activity near other impact-phase signals, while accounting for legitimate help desk, IAM lifecycle, and offboarding workflows.
Likely telemetry
- Operating system account management audit logs from Windows, Linux, and macOS where available
- Directory or identity provider audit logs for account deletion, disablement, lockout, password or credential changes, and permission changes
- SaaS administrative audit logs for revoked access, changed roles, removed permissions, or account deactivation
- Privileged access management or IAM workflow records showing approved versus unapproved access-removal actions
- Service desk, HR offboarding, or change-management records needed to distinguish expected access removal from suspicious activity
Detection direction
- Confirm that audit logs for account access removal are actually retained and searchable across the platforms associated with T1531: Linux, macOS, Windows, and SaaS.
- Correlate similar access-removal events across multiple systems or accounts rather than relying on a single platform alert.
- Tune out approved lifecycle events such as normal offboarding, role changes, and help desk password resets, but preserve visibility into privileged accounts and emergency administrative access.
- Review blind spots where SaaS admin activity, local OS account changes, or identity provider events are not centrally collected.
- Use relationship context: this strategy detects an impact technique, so escalation and triage should consider business disruption and loss of defender access, not only initial compromise indicators.
Mitigation priorities
- Prioritize complete identity and account-management logging before building complex detection logic.
- Protect and monitor privileged accounts, break-glass accounts, and SaaS administrators with strong governance and review processes.
- Require traceable approval paths for account deletion, lockout, credential reset, and permission revocation actions.
- Align SOC runbooks with IAM and service desk processes so responders can rapidly validate whether an access-removal event was authorized.
- Test incident response readiness for scenarios where administrator or user access is removed during an incident.
Analyst notes and limits
This take is based on the detection strategy name, the external reference DET0120, and the relationship showing it detects T1531 Account Access Removal. Because the official detection and description fields are not provided, local detection engineering should be driven by the related technique context and the organization’s actual identity, endpoint, and SaaS audit sources.
The detection object does not specify platforms, tactics, description, or official detection logic. Platform and tactic context comes from the related T1531 technique, not from DET0120 itself. No claim is made that this strategy guarantees detection or that any specific adversary is using it.
Account Access Removal via Multi-Platform Audit Correlation
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1531 | Account Access Removal | This object detects Account Access Removal. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | feee53699b4d… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0120Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.