T1531 account access removal: what it does and where it shows up in intrusions
When legitimate users suddenly cannot sign in, the SOC lead should not assume a password reset or a directory sync fault until the cause is confirmed. T1531 Account Access Removal sits under the Impact tactic (TA0040), where MITRE describes the adversary as trying to "manipulate, interrupt, or destroy your systems and data." Removing or disabling accounts is a direct way to interrupt operations, because the people who would investigate and recover systems lose the access they need. For that reason, a spike in lockouts or disabled accounts should be handled as a possible security incident until an authorized change record explains it. This page maps the technique to MITRE ATT&CK version 20.0.
At a high level, the technique works by disabling or removing accounts and credentials so that they can no longer authenticate. The affected scope can include directory accounts, local accounts on Linux, macOS and Windows hosts, and administrator accounts in SaaS consoles and cloud tenants. The impact falls on two groups at once: administrators who need access to contain and restore systems, and ordinary users who need access to do their jobs. In intrusions, this step usually comes late, after an adversary has already gained and kept access, so it can appear alongside other Impact activity. The first decision for the SOC is to ask whether the affected accounts were changed by an approved administrator, a scheduled process, or an unknown actor.
Before the next incident, confirm with your identity and platform teams which account-change and authentication events your directory services, Linux and Windows hosts, and SaaS tenants record, and whether those events reach your SIEM with usable timestamps and actor fields. Confirm that break-glass administrator accounts exist, are documented, are monitored for any change, and are not dependent on the same directory they are meant to recover. Review the ATT&CK 20.0 technique entry and its detection strategies for T1531 to decide which data components your detections will depend on. The MITRE ATT&CK tactic page for Impact is the natural starting point for mapping these checks to your environment.
Which telemetry reveals account access removal on each platform
This table maps the telemetry that reveals T1531 Account Access Removal on Linux, macOS, Windows and SaaS platforms, with the signal to look for and the open-source collector that brings it into a SIEM. Read each row as a starting point for your own logging inventory, and confirm detection strategy IDs against the ATT&CK version you target, since the page is written against Enterprise ATT&CK 20.0.
| Platform | Telemetry and signal to look for | Open-source collector or source |
|---|---|---|
| Linux | Process Creation (DC0032) and Command Execution (DC0064) for account deletion or lock utilities run by a non-administrative or unexpected parent process, plus User Account Authentication failures for locked accounts | Wazuh agent with auditd rules, forwarded to a Wazuh indexer or SIEM; Velociraptor for hunts across hosts |
| macOS | Process Creation and Command Execution for directory service or account management commands outside change windows, with User Account Authentication events showing a previously valid account suddenly failing | Wazuh agent with unified log collection where supported; Velociraptor artifacts for on-demand collection |
| Windows | Process Creation and Command Execution tied to account disable or delete actions, with Application Log Content from domain controller security events covering account changes and lockouts | Wazuh agent reading the Windows Security event channel; Sysmon for process telemetry; Velociraptor for event log hunts |
| SaaS and identity providers | Application Log Content from the native admin audit log showing user suspension, license removal, role revocation or session revocation by an unexpected actor | Native SaaS audit log forwarded to a SIEM through its export or API connector; Wazuh or Security Onion for ingestion and correlation |
| Network access and VPN | User Account Authentication outcomes showing a burst of denied logons across many accounts, with Network Traffic Content only where the protocol is visible to the sensor | Zeek logs for authentication protocols where visible; Suricata for network signatures; firewall or VPN logs forwarded to the SIEM |
| Cloud control plane (IaaS) | Application Log Content from the cloud provider audit trail showing identity deletion, policy detachment or key disablement, correlated with Process Creation on administrative hosts | Native cloud audit trail exported to a SIEM; Wazuh integrations where the provider is supported; confirm each source with the provider documentation |
| ATT&CK version and mapping | Detection strategy IDs and data component IDs should be confirmed against the Enterprise ATT&CK 20.0 STIX bundle before they are written into rules or coverage reports | Enterprise ATT&CK 20.0 STIX bundle from the attack-stix-data repository |
Detection logic for account lockouts and access removal
T1531 shows up as account state changes that are fast, broad or out of place. The ideas below look at the same activity from different angles: volume, actor, timing, SaaS admin actions and what happened to the user before the change. Each one needs a baseline built from your own identity logs before its thresholds mean anything.
Bursts of disable or lock events
Alert when a single source generates a burst of account disable, lock or deletion events in a short window, with extra weight when the targets include privileged or service accounts. Build the baseline from several weeks of directory audit events, grouped by actor and hour, and set the threshold per domain controller or identity provider. Expect offboarding batches, directory sync runs and scheduled cleanup jobs to trigger it, so tag those sources in advance. Ask your team which of these jobs are known and documented.
Account state changes by unexpected actors
Flag account disable, password reset or group removal events where the actor is not a member of the identity administration group or not on the approved automation list. Compare each actor against the role they hold in the directory, not just their username. Review service accounts that changed state outside their normal schedule, since they are a common route for bulk changes. Confirm that your audit policy records these events for every directory controller, not only the primary one.
Administrative actions outside change windows
Correlate account state changes with approved change calendars and on-call rosters. A disable event at an hour with no ticket, no pager activity and no HR offboarding record deserves review. Set the window by business unit and time zone, and treat weekend and holiday activity as a separate baseline. Keep the change calendar in a system the detection pipeline can query, otherwise this rule will rely on manual lookups during an incident.
SaaS admin removals and session revocations
In SaaS admin audit logs, look for user suspension, license removal, role removal and bulk session revocation performed by a single admin account in a short period. Map each SaaS platform's audit event names to the same detection logic so that one rule covers all of them. Confirm which admin events each vendor logs and at what retention, because gaps here leave SaaS removals invisible to the SIEM. Pull admin audit data into the same pipeline as directory events so the timeline is complete.
Failed logins before access removal
Correlate account disable or lock events with authentication failures for the same user in the preceding minutes or hours. A user who fails logins from unusual sources, followed by a disable event initiated by an admin who did not open a ticket, points to a possible unauthorized lockout. Tune the look-back window to your authentication patterns, since users who forget passwords will also generate failures. Exclude expected password policy expiry cycles, which produce many failures and lockouts at predictable times.
How to validate that the detection fires
This sequence proves that an account access removal detection works before it is trusted in production. It moves from agreed scope and controlled test identities to confirmed log arrival, alert timing and a dated evidence record that the team can re-run after tuning.
Agree test scope with account owners
The detection engineer, the identity team and the owners of the test tenant agree in writing which accounts, groups and administrative actions may be changed, which time window the exercise uses and who can stop it. Named owners approve the scope before any change is made. The step is done when the signed scope note lists the test identities, the permitted actions, the rollback contact and the ATT&CK version the rule targets.
Prepare dedicated test identities and baseline state
The team creates or designates test identities in a non-production tenant or directory, separate from any business account. They record the baseline state of each identity, including group memberships, role assignments, credential status and any active sessions, so that the exercise can be reverted. The step closes when a baseline snapshot is stored with the exercise record and a second person has checked it.
Run a controlled account state change
The exercise lead, working from the agreed scope, applies a single documented change that removes or disables a test identity's access in the way the detection is meant to catch. Each action is logged with a time, operator and purpose. The step is complete when the change is confirmed on the platform itself, so the team knows the event happened and is not relying only on the alert.
Confirm each log source reaches the SIEM
The detection engineer checks that the telemetry the rule depends on has arrived in the SIEM for the exercise window. For account access removal, this usually includes authentication and directory or identity audit records, and where the platform supports it, administrative change records. The step closes when every required source shows the test events with correct user, actor and timestamp fields, and any gaps are logged as findings.
Verify the alert fires within the expected window
The analyst confirms that the rule produces an alert for the test change and that the alert arrives within the detection latency the team has set for this use case. The team records the event time, ingestion time and alert time, and checks that the alert carries the affected identity and actor. The step is done when the timing is captured and any delay beyond the agreed window is written up as a tuning item.
Record timestamps, alert IDs and analyst actions
The analyst records the alert identifier, the rule version, the timestamps for each stage, the triage steps taken, and the decision reached. The team then reverts the test identities to the stored baseline and checks that the revert is also logged. The step closes when a single evidence record links the scope note, the baseline, the events, the alert and the revert, ready for review by the incident response and compliance owners.
Re-test after tuning and version the rule
After any change to the rule logic, thresholds or data sources, the team repeats the controlled change and compares the new results with the earlier record. The rule is stored in version control with a reference to the ATT&CK version it targets, such as the Enterprise release used in the scope note. The step is complete when the re-test passes, the change log explains the difference, and the previous version remains available for audit.
Preventive controls that limit the impact of account removal
T1531 succeeds most easily when a single identity can lock out others and nobody notices the change. The cards below cover the two ATT&CK mitigations that map to this technique, User Account Management and User Training, and the account design choices that shrink what an adversary can remove.
Privileged account governance
Mitigation User Account Management (M1018) is the primary control here. Limit which accounts can disable, delete, reset or change the credentials of other users, and keep that rights list short and reviewed. Confirm who holds directory administrator, domain administrator, tenant administrator and cloud IAM roles, and whether each grant has an owner and an expiry. Review the list on a fixed schedule and after staff changes, since stale administrator accounts are a common route to mass account removal.
Break-glass accounts kept separate
Keep at least one emergency administrator account that is not used for daily work, is excluded from routine account lifecycle jobs, and is monitored for any login at all. Store its credentials offline under dual control and test the recovery path in a non-production environment. Without this account, an adversary who removes administrator access can leave the organization unable to restore service. Confirm that the account is not synced to the same identity provider role that an attacker would compromise, where your architecture allows that separation.
Least privilege for account administration
Split the ability to create accounts from the ability to delete them and from the ability to change authentication settings. Require a second approver for bulk disables, group deletions and changes to MFA enrollment. Scope administrator roles to the organizational units, tenants or applications that each team manages, so that one compromised operator cannot remove accounts across the whole environment. Ask your identity team to show the role matrix and a sample of recent bulk operations.
Role-based user training
Mitigation User Training (M1017) addresses the human path into this technique, such as phishing that yields administrator credentials. Train help desk staff to verify identity before resetting credentials or disabling accounts, and to treat urgent requests to lock out users as a possible incident. Train identity administrators on the break-glass procedure and on how to report unexpected account changes. Training content should match the roles that hold privileged rights, and completion should be tracked for those roles.
Account lifecycle change control
Route disables, deletions and privilege changes through a ticketed workflow that records the requester, the approver and the reason. Automated joiner, mover and leaver processes should be the only normal path for account removal, so that any manual removal stands out. Confirm whether your identity platform can enforce this workflow or whether it depends on process discipline, and document the gap if it does.
Triage and response when an access removal alert fires
When an access removal alert fires, the first decision is whether the change was authorized. Check the change ticket, the HR offboarding record and any scheduled access review before touching anything else, because a legitimate offboarding and an attacker removing administrator access on the same day can produce identical log lines. Record who approved the change and when, and compare the timestamp against the approval. If no ticket or HR record explains the removal, treat the alert as a live incident and bring in your incident response lead immediately. Confirm your own escalation paths and on-call contacts now, not during the incident.
Next, identify the actor and the source. In your identity provider and directory, establish which administrator account or service principal performed the change, from which IP address, device and session, and whether that identity was itself recently authenticated or granted new rights. Then determine the blast radius: list the accounts that lost access, the applications, SaaS tenants, cloud subscriptions and privileged groups affected, and any service accounts whose credentials were disabled, since those often break automated jobs silently. Restore legitimate access through a verified break-glass path, meaning an emergency account whose credentials and multi-factor method are held offline and tested on a schedule. Do not restore access through the same administrator session that is under suspicion.
Contain the actor's session by revoking active sessions and tokens, disabling the suspicious account, and blocking the source address at the identity provider where your platform supports it. Preserve evidence before you clean up: export identity provider audit and sign-in logs, directory change history, and relevant SIEM records such as Wazuh alerts from the source host, and retain them in write-protected storage. Finally, document a single timeline covering the alert, the approval status, each containment step and each restoration, so the post-incident review can separate authorized activity from the intrusion. Confirm your retention periods for these logs with your compliance owner, because the window you need may be shorter than you expect.
Rehearsing T1531 detection in a private cyber range
A private range for this environment should contain a Windows domain controller, a Windows workstation and a Linux host that authenticates against the same directory or a separate local account store. Every host forwards authentication and account management events to the Wazuh manager or another collector in the range, so the team can see account changes as they happen. The test identities should include a standard user, a privileged administrator and a service account, each with a documented owner and a known restore path.
- Scheduled account changes: Inject a disable or expiry change at a set time for a test user, then confirm the change appears in the directory audit log and the collector within an interval the team agrees in advance.
- Unexpected administrator action: Have a test administrator remove or disable a second administrator account outside the change window, so the team must decide whether the action is authorized.
- Bulk lockout: Lock a group of test accounts in a short burst, which should trigger a correlated alert rather than individual noise.
- Good detection: Alerts name the actor, target account, host and time, and map to the relevant data components for account management events.
- Good response: The team confirms the source, restores access for affected test users through the directory's documented procedure, and records each step with a timestamp.
Check that restoration works for the service account and that the Linux host can still authenticate after the directory is restored.
The macOS environment should include a small fleet of managed endpoints bound to the range directory, along with local accounts used for recovery. Endpoint telemetry from the fleet, such as process and command execution records, should reach the collector so that account management commands can be correlated with the actor and the affected host. Confirm with your endpoint management vendor which account management events the agent records and where they are stored, because the available fields differ by product and version.
- Test identities: Use a managed standard user, a managed administrator and a local recovery account stored in a sealed location outside the exercise scope.
- Scheduled account changes: Disable a managed user from the directory side and observe whether the fleet reports the change and whether the user's session is terminated.
- Unexpected administrator action: Run an account management command from a non-administrative session on a test endpoint, so the team can check whether the attempt is logged and blocked.
- Bulk lockout: Apply a change across several endpoints at once and check whether the alert groups the events by actor and time.
- Good response: The team uses the recovery account only as a documented fallback, restores the managed user, and confirms the endpoint accepts a fresh sign-in.
Record whether the team could restore access to every test endpoint without physically touching the device, since that answer shapes the response runbook.
A SaaS tenant in the range should be a dedicated test tenant with audit logging enabled and an export path to the collector. Identity-provider audit logs usually record role changes, account suspensions and credential resets, but the event names and retention periods vary by provider, so confirm them with the vendor before the exercise. Use a tenant that is not connected to production data, and keep at least two global administrator accounts with break-glass access documented outside the tenant.
- Test identities: A standard user, a tenant administrator and a break-glass account that is excluded from the exercise injects.
- Scheduled account changes: Suspend a test user through the admin console at a set time, then confirm the audit event reaches the collector and that the user's active sessions end.
- Unexpected administrator action: Remove a role from a second test administrator, which should appear as a privilege change and not only as a user update.
- Bulk lockout: Suspend a batch of test users through the bulk tool or API, then check whether the alert identifies the acting identity and the number of affected accounts.
- Good response: The team restores the suspended users from the admin console, reassigns the removed role after approval, and verifies sign-in for each restored test identity.
Check that the break-glass account works during the exercise and that restoration steps do not depend on a single administrator who is locked out.
Questions SOC leads and detection engineers ask about T1531
How do I tell attacker-driven access removal from routine offboarding?
Start from the actor and the context, not the action alone. Offboarding runs through a known HR or identity workflow, usually under a service account or an administrator tied to a ticket, and it removes accounts that have a termination record. Attacker-driven removal tends to come from an unexpected source host, an interactive session with no matching change record, or a single identity that disables or deletes several accounts outside business patterns. Correlate the removal event with the originating session, the source address and the change or HR record. Keep an allowlist of approved automation identities and review every removal by an interactive administrator account. Confirm with your identity provider which audit fields carry the initiating principal, because some platforms record the target only.
Which fields should I normalize across Windows, Linux and SaaS logs?
Normalize around who acted, what they acted on, from where, and whether it succeeded. In practice that means mapping the initiating account, the target account, the action name, the source address, the outcome and a timestamp in UTC into one schema. On Windows, account management and process creation events carry much of this; on Linux, authentication and process records from the host audit or auth logs fill the gap; SaaS platforms expose it through administrative audit logs with their own field names. Keep the original field names alongside the normalized ones so analysts can verify mappings. Confirm with each SaaS vendor which actions, actor fields and retention periods its audit log provides before writing rules that depend on them.
How should I tune rules for bulk operations without missing an attack?
Bulk removal is normal during mergers, contractor exits and directory cleanups, so a rule that counts removals will be noisy. Tune on the combination of conditions instead of volume alone:
- The initiating identity is not on the approved automation list.
- The source host or session has no matching change or ticket reference.
- The removals occur outside the scheduled window your team has documented.
- Targets include privileged or break-glass accounts.
Route matches that meet several conditions to a high-priority queue and keep single-condition matches as enrichment. Review tuning changes with the identity team, and record each exception with an owner and an expiry date so exceptions do not persist silently.
What do I do when a SaaS platform keeps audit logs for only a short period?
Treat limited retention as a detection gap to close, not a reason to skip the technique. Confirm the exact retention period, export frequency and any API limits with the vendor in writing, because these vary by plan and product. Then forward the audit events to your own log store on a schedule shorter than the vendor's retention window, and verify that the forwarded events match the source. Where a vendor offers streaming or webhook export, test it during a cyber range exercise. Document the residual gap, including any actions the platform does not log, so the risk owner can accept or fund a compensating control.
How do I version detection rules across ATT&CK releases?
Name the ATT&CK version every mapping targets in the rule metadata, and record the detection strategy and data component IDs it relies on. ATT&CK v18 replaced technique-level detections with detection strategies and analytics, and it deprecated data sources in favor of data components, so rules written against older text need review. MITRE publishes new releases, and releases can rename, deprecate or revoke techniques. Keep rules in version control, pin the ATT&CK version in each mapping, and compare the STIX bundle for each new release against your mapping file to find changes that affect coverage. Review the MITRE ATT&CK updates page when each release arrives.
How can I test detections without locking out real users?
Test in a private cyber range that mirrors your identity provider, directory and SaaS tenant configuration, using test accounts that carry no business access. Run the removal scenarios as scripted exercises with known outcomes, then confirm that the expected alerts fire with the expected enrichment. Include negative tests such as scheduled offboarding batches to confirm that approved automation stays quiet. Keep a documented rollback path for every test account and check that production identities are excluded from any action the exercise performs. Do not run the exercise against production directories unless the change has been approved and scoped in writing.
How DeployOpen works on this
DeployOpen approaches T1531 Account access removal as a written, fixed-scope piece of work inside your own environment, covering the identity sources, log pipelines and response runbooks that reveal account lockouts, deletions and credential resets. Detection content is built on open-source tooling, tested in a private cyber range and handed over with documentation your team can maintain.
How we scope
- Confirm which identity providers, directories and SaaS tenants hold the accounts whose removal would matter to your operations.
- Agree in writing which log sources for account changes and authentication will be onboarded into your SIEM.
- Record the ATT&CK version the detection mapping targets, so later releases can be reviewed against it.
How we build
- Map account deletion, disablement and credential modification events on Linux, macOS, Windows and SaaS platforms to detection logic written in plain language.
- Express detection rules in Sigma form and translate them for your chosen open-source SIEM and endpoint tooling.
- Configure alert routing so that bulk or privileged account removals reach the on-call responder with the context needed to act.
How we hand over
- Deliver a test report showing which simulated account removals the detections caught, missed or raised as false positives.
- Provide response runbooks covering account restoration, identity provider review and evidence preservation for T1531.
- Document the data components, log fields and tuning decisions so your engineers can maintain the content after handover.
How we support
- Offer ongoing support as a retainer for tuning, detection updates and re-testing after ATT&CK releases.
- Re-run cyber range exercises after significant identity platform upgrades or new SaaS integrations are added.
- Ask your compliance lead to confirm which evidence your assessors expect, since DeployOpen prepares evidence but does not issue audit opinions.
