MITRE ATT&CK T1531 Account Access Removal: Detecting Lockouts and Restoring Control

When attackers delete, disable or re-password the accounts your administrators and responders rely on, every other recovery step stalls until access is back. MITRE ATT&CK tracks this as T1531 Account Access Removal, an Impact technique in which adversaries interrupt availability by deleting, locking or manipulating legitimate accounts, for example by changing credentials or revoking SaaS permissions. It usually arrives in the last hour of an intrusion: ransomware operators lock out administrators before encryption, and extortion groups strip tenant administrators so they hold sole control. This guide covers how T1531 shows up on Windows, Linux, macOS, ESXi, Microsoft 365, SaaS and cloud platforms, the audit events and correlations that catch it, the preparations that make it survivable, and how to restore control without handing it straight back. It is written for SOC analysts, identity engineers and incident responders, and stays defensive. Protecting the cloud recovery accounts themselves is covered in depth in the Protecting Cloud Control-Plane Recovery Accounts and Credentials guide; this page does not repeat it.

Key takeaways

• T1531 is a timing signal. ATT&CK notes that adversaries using ransomware may perform it, along with T1485 Data Destruction and T1491 Defacement, to impede response before T1486 Data Encrypted for Impact. A burst of resets or deletions means encryption may be minutes away.
• Bulk is the tell, not the event. Password resets and account disables happen every day. Many of them, from one actor, in a short window, against privileged or service accounts, outside a change window, is the pattern MITRE's detection strategy DET0120 correlates.
• Prepare access that the attacker cannot see or change. Emergency accounts on separate authentication, offline-held credentials and independent recovery channels are what let you act after a lockout.
• Restoring an account is not recovering it. If the attacker still holds an administrator session, token or key, restored accounts can be removed again. Evict first, then restore.
• Service accounts are targets too. Re-passwording or deleting service accounts breaks backups, monitoring and line-of-business systems, which is exactly the outage the attacker wants.

What T1531 covers in ATT&CK v20

T1531 sits in the Impact tactic and has no sub-techniques. ATT&CK v20 lists Linux, macOS, Windows, SaaS, IaaS, Office Suite and ESXi as platforms. The technique description names the mechanics defenders should expect: on Windows the Net utility and the Set-LocalUser and Set-ADAccountPassword PowerShell cmdlets, or accounts disabled through Group Policy; on Linux the passwd utility; on ESXi esxcli system account set and system account remove; and in SaaS, revoked permissions on platforms such as SharePoint. ATT&CK adds that adversaries may then log users off or force a T1529 System Shutdown/Reboot so the changes take effect.

It is distinct from neighbouring techniques that use similar actions for a different goal:

In practice T1531 and T1098 are frequently chained: the attacker first creates or elevates an account they control, then removes everyone else. That chain is why the creation event that precedes a mass removal is often the best early warning.

What the public procedure examples show

The ATT&CK v20 procedure examples for T1531 cover crimeware, wipers and extortion groups:

• Ransomware before encryption: Akira is recorded deleting administrator accounts in victim networks prior to encryption. LockerGoga and MegaCortex are recorded changing account passwords and logging users off.
• Wipers: Meteor can change local user passwords and log users off. DEADWOOD changes the passwords of local and domain users via net.exe to a random 32 character string so they cannot log on.
• Cloud tenant takeover: LAPSUS$ is recorded removing a targeted organisation's global administrator accounts. Microsoft's 2022 write-up on the group (tracked then as DEV-0537) describes it creating global admin accounts in cloud instances and then removing all other global admins so that only the actor had control, effectively locking the organisation out. See the Lapsus$ Threat Actor Profile.

The common thread: the attacker already holds highly privileged access (domain administrator, ESXi root, Global Administrator or equivalent). T1531 is rarely the first problem. It is the moment an earlier privilege compromise becomes an outage.

Detection: the events and correlations that matter

MITRE's detection strategy DET0120, Account Access Removal via Multi-Platform Audit Correlation, pairs account change events with context that makes them suspicious: unusual process lineage, a non-administrative or unusual actor, remote sessions, anomalous sign-in locations, and bulk actions in a short window. The table maps that strategy to the log sources and events to collect.

Microsoft's guidance for events 4724 and 4726 makes two monitoring points that apply on every platform: watch every reset or deletion that targets a high-value or never-to-be-changed account (by SID or object ID), and watch all changes to local accounts, which are rarely reset or deleted on servers and administrative workstations. Microsoft documents 4725 as "A user account was disabled" and 4740 as "A user account was locked out", both in the Audit User Account Management subcategory; for 4740 it advises alerting when the subject is not SYSTEM, because lockouts are normally triggered by SYSTEM.

Rules worth building first

1. Bulk threshold: one actor resetting, disabling or deleting more than N accounts in M minutes, tuned against your help desk and joiner, mover and leaver automation (our starting point: five privileged or ten standard accounts in ten minutes).
2. Protected list: any reset, disable or delete of a member of the domain, tenant or cloud top-level admin set, an emergency access account or a named service account fires at critical severity, whatever the volume.
3. New admin then removal: a new privileged account or role assignment followed within an hour by removals of other administrators. This is the LAPSUS$ pattern and the Akira pattern in one rule.
4. Lineage: account change events whose parent process is a script host, a remote management tool or an unusual binary on a server, rather than the directory management consoles your administrators use.
5. Absence: sudden loss of authentication events from an administrator group, or a spike in failed sign-ins for administrators, can be the first visible symptom when the change events themselves were not collected.

Send these alerts somewhere that does not depend on the identities being removed. An alert routed only to a mailbox the attacker has just deleted helps nobody. For writing and testing the analytics, see the ATT&CK Detection Strategies and Analytics Guide.

Prevention: making a lockout survivable

ATT&CK v20 maps no mitigation objects to T1531, because the actions are legitimate administrative operations. Prevention therefore means limiting who can perform them and making sure that if they are performed maliciously, you still have a way in.

Platform specifics from vendor documentation

• Active Directory: enable the Active Directory Recycle Bin. Microsoft's documentation states it preserves deleted objects with all their attributes, so restored accounts keep group memberships and access rights, but only for objects deleted after it was enabled, and enabling it cannot be reversed. Plan for local administrator recovery as well: a domain-wide lockout also affects the accounts you would use to log in to domain controllers.
• AWS: AWS recommends registering MFA on the root user (up to eight MFA devices can be registered), never creating root access keys, using a group-managed recovery email address and keeping the recovery email and phone number with different people or groups. For organisations, AWS recommends centralised root access management for member accounts and alerting on root sign-in and usage.
• Google Workspace: Google recommends more than one super administrator, each managed by a separate person, separate accounts for super admin tasks and daily work, recovery phone and email on each admin account, more than one enrolled security key per admin, and printed backup codes stored securely.
• Microsoft Entra ID: Microsoft recommends at least two cloud-only emergency access accounts on the .onmicrosoft.com domain with permanent Global Administrator assignment, authentication different from normal administrators (passkey or certificate-based), exclusion from blocking Conditional Access policies, an alert on any sign-in, and a test at least every 90 days.

The cloud recovery account and break-glass designs are covered in full in the Break-Glass Account Guide and the Admin panels and super admin accounts guide.

Responding when accounts are being removed

A live T1531 event is a race. The order matters more than the speed of any single step.

1. Confirm and declare: verify the changes are not an approved bulk operation (check the change calendar and the identity team), then declare an incident. Assume encryption or destruction may follow and alert the ransomware response lead.
2. Use out-of-band access: sign in with emergency access accounts from a designated secure workstation. Do not use accounts or devices that may be under the attacker's observation, and move incident communications off any platform the attacker administers.
3. Cut the attacker's privileged access first: disable the attacker-created or attacker-used accounts, revoke their sessions and refresh tokens, delete access keys and remove role assignments they added. Then check for persistence such as new federation trusts, OAuth application grants and mail transport rules (the DEV-0537 write-up describes a tenant-level transport rule redirecting mail).
4. Contain the hosts: isolate the systems and sessions issuing the changes. If shutdowns or reboots are being forced, preserve volatile evidence where it is safe to do so.
5. Restore accounts in priority order: identity administrators and emergency accounts, then security tooling and backup service accounts, then infrastructure and line-of-business service accounts, then users. Reset restored credentials rather than reusing anything the attacker may have seen.
6. Verify: confirm that no new removals occur for at least 24 hours (our recommendation), that alerts fire on test changes, and that backups and monitoring authenticate again.

For the wider ransomware sequence see the Ransomware Response and Recovery Guide; for directory rebuild and privileged account recovery after encryption see the IAM and PAM Recovery After Ransomware Guide.

Evidence to preserve

• Directory and identity provider audit logs covering the full dwell period, exported before retention or attacker deletion removes them.
• Security event logs from domain controllers and the hosts issuing changes, plus Sysmon or EDR process trees.
• Cloud control-plane logs and SaaS admin audit logs, including sign-in logs for every account that made a change.
• The list of affected accounts with before and after state, which also drives the restoration plan.

Where identity fits

T1531 is an identity attack in its outcome, and it hits non-human identities hard. Service accounts that run backups, monitoring agents, scheduled jobs and integrations are attractive targets because re-passwording them silently breaks the systems responders need. Keep an inventory that maps each service account to what fails without it, store their credentials in a vault you can reach out of band, and prefer managed identities or group managed service accounts whose credentials the platform rotates. See the Service Account Security Guide.

Measuring readiness

• Emergency access test success: percentage of quarterly drills in which emergency accounts signed in and performed an administrative task first time (target 100%).
• Protected-list coverage: percentage of top-level admin, emergency and critical service accounts covered by the critical-severity change rule.
• Time to detect bulk removal: minutes from the first removal to an analyst acknowledging the alert in purple team tests.
• Recoverable deletions: share of directories and tenants with object recovery (Recycle Bin or soft delete) enabled and tested by a restore.
• Standing top-level administrators: number of permanently assigned top-level admins outside emergency accounts, trending down.

Framework mapping

Common failure patterns

• Emergency accounts that depend on what was removed: break-glass accounts federated to the compromised directory, or with MFA on a phone registered to an administrator whose account was deleted.
• Alerts sent to the removed identities: critical alerts route only to the administrator mailboxes or chat accounts the attacker has just disabled.
• Restoring before evicting: accounts are restored while the attacker's own Global Administrator or access key still exists, and are removed again within minutes.
• No Recycle Bin, no soft-delete plan: deleted accounts are recreated by hand with new identifiers, so permissions, group memberships and application assignments are lost.
• Service account blind spot: monitoring covers human administrators only, so re-passworded service accounts surface as backup failures hours later.
• Bulk thresholds never tuned: the rule is muted after firing on every joiner, mover and leaver run, and stays muted.

Practitioner checklist

• Collect account reset, disable, delete and lockout events from every directory, host OS, hypervisor, SaaS platform and cloud control plane in scope.
• Build the bulk, protected-list, new-admin-then-removal and lineage rules, tuned against your provisioning automation.
• Maintain at least two emergency access accounts per tenant or cloud organisation, on separate authentication, tested every 90 days.
• Keep recovery email addresses and phone numbers group-managed and split between people or teams.
• Enable the Active Directory Recycle Bin and confirm cloud soft-delete behaviour with a test restore.
• Route critical identity alerts through a channel that does not depend on the identities being monitored.
• Inventory service accounts with the systems that fail without them, and keep their credentials reachable out of band.
• Write the response order (evict, contain, restore, verify) into the ransomware playbook and rehearse it.

Standards and references

• MITRE ATT&CK: T1531 Account Access Removal
• Microsoft Learn: Event 4726 A user account was deleted
• Microsoft Learn: Event 4724 An attempt was made to reset an account's password
• Microsoft Learn: Event 4723 An attempt was made to change an account's password
• Microsoft Learn: Event 4725 A user account was disabled
• Microsoft Learn: Event 4740 A user account was locked out
• Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID
• Microsoft Learn: Active Directory Recycle Bin
• AWS: Root user best practices for your AWS account
• Google Workspace: Security best practices for administrator accounts
• Microsoft Security Blog: DEV-0537 criminal actor targeting organizations for data exfiltration and destruction

Related NHI Mgmt Group resources: Protecting Cloud Control-Plane Recovery Accounts and Credentials · Break-Glass Account Guide · Ransomware Response and Recovery Guide · ATT&CK Detection Strategies and Analytics Guide