Account Access Removal (T1531) is an Impact technique. Adversaries interrupt availability by stopping legitimate users from using their accounts. MITRE lists Linux, macOS, Windows, SaaS, IaaS, Office Suite and ESXi.
How attackers use it
Accounts can be deleted, locked or changed, for example by altering credentials or revoking permissions on a SaaS platform such as SharePoint. The adversary may also log users off and trigger a System Shutdown/Reboot so changes take effect.
MITRE names several ways this is done:
- Windows: the Net utility, and the Set-LocalUser and Set-ADAccountPassword PowerShell cmdlets. Accounts can also be disabled by Group Policy.
- Linux: the passwd utility to change passwords.
- ESXi: esxcli system account set and system account remove.
The context matters. MITRE says that adversaries using ransomware or similar attacks may do this early, along with Data Destruction and Defacement, to hinder incident response and recovery before finishing with Data Encrypted for Impact. If your administrators suddenly cannot sign in, that is a reason to think about wider compromise and not only a password problem.
How to detect it
MITRE's analytics, by platform:
- Windows: account reset, disable or delete events tied to odd process lineage, for example PowerShell or net.exe from an interactive session, outside admin change windows or from non admin users.
- Linux: password changes or account deletions with passwd, userdel or chage, preceded by interactive shell or remote command execution from non privileged accounts.
- macOS: dscl or sysadminctl commands that disable, delete or change users, with unusual process ancestry.
- ESXi: esxcli system account remove from vCLI, SSH or the vSphere API by unusual users or outside maintenance windows.
- Microsoft 365: UnifiedAuditLog entries for Remove-Mailbox or Set-Mailbox that disable or delete accounts, with suspicious login locations or MFA bypass.
- Other SaaS such as Okta, Salesforce or Zoom: account deletion or disablement tied to odd admin session attributes, or many removals in a short period.
Windows event IDs worth alerting on are 4725 (account disabled), 4726 (account deleted), 4723 (password change attempt) and 4724 (password reset attempt). The pattern to flag is many of them in a short time, or any of them against privileged or break glass accounts.
How to reduce the risk
MITRE lists no mitigations for this technique. Sensible protections follow from the detections: keep emergency access accounts that are documented, monitored and tested, limit who can modify or delete accounts, require approval for bulk account changes, and keep identity provider audit logs off the systems an attacker could reach.
Check your own environment
A read only Windows query for recent disabled and deleted account events on a domain controller or server:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4725,4726} -MaxEvents 50 |
Select-Object TimeCreated, Id, Message
Then ask:
- Who can disable, delete or reset accounts, and is that list short?
- Do you alert on several account changes within minutes?
- Is there a break glass account stored offline and tested on a schedule?
- Do identity provider and SaaS admin logs reach a central system?
- Can you restore directory data from a backup you trust?
Quick check
Why do ransomware operators remove account access first?
MITRE notes that it hinders incident response and recovery, giving them time to complete later steps such as encrypting data.
