Event ID 4726: A user account was deleted

Event 4726 records that an account object was permanently deleted. Unlike a disable, 4725, which leaves the account, its SID, and its history intact and reversible, deletion removes the object outright. The account's SID is never reused by Windows, which is why this event marks a genuinely final state: there is no undelete operation, and any later account with the same username is a completely new object with a new SID, no relationship to the deleted one beyond a coincidentally shared display name.

SubjectUserSid, SubjectUserName, and SubjectLogonId identify who performed the deletion, correlating back to their own 4624 logon session. TargetUserName, TargetSid, and TargetDomainName identify the account that was removed. Because the SID is never reused, TargetSid is the reliable join key for correlating this event against everything else that account ever did: its creation, its group memberships, its logon history, all of it ties back to the same SID even after the account name itself no longer exists anywhere in the directory.

Routine account deletion is a normal part of account lifecycle management: offboarding cleanup, decommissioning service accounts tied to retired systems, and periodic hygiene passes removing stale objects that were disabled long ago and are now being cleared out for good. None of that is inherently notable, and in most environments the majority of 4726 volume falls into exactly this bucket, performed by a known, narrow set of IT-admin identities as a deliberate, usually batched, cleanup step.

The pattern that turns this event from routine cleanup into an attacker signature is speed, specifically the gap between an account's creation and its deletion. An attacker who creates a backdoor account, 4720, uses it for whatever the operation required, and deletes it, 4726, the same day or within a few hours is removing the persistence artifact before a routine account-listing audit would ever notice it existed. A disposable account with a lifespan measured in hours rather than the weeks or months a legitimate account typically survives is a distinctive shape a static, point-in-time directory audit structurally cannot catch, since by the time anyone looks, the account is already gone.

A second pattern worth its own check: deletion of an account that still held privileged group membership at the moment it was removed. Legitimate offboarding processes typically remove group memberships before deleting the account, or the memberships simply drop away as a side effect of deletion, but a privileged account deleted without any preceding membership cleanup is either a shortcut in an otherwise legitimate process or, less benignly, an attacker removing evidence of an account they had already escalated, in a single step, without the intermediate cleanup a careful human administrator would typically perform.

Mass deletion waves are the third pattern, structurally identical to the mass-disable pattern covered on the 4725 page but categorically more severe, since deletion cannot be undone by simply re-enabling the account. A high-volume deletion event outside any documented decommissioning project is a strong candidate for destructive, impact-stage activity under the same MITRE T1531 umbrella as mass account disabling.

The baseline for 4726 is narrow in most organizations, similar in shape to the other administrative account-lifecycle events on this dataset: a small, known set of IT-admin accounts performing deletions as part of scheduled cleanup or documented offboarding, usually in batches, usually traceable to a specific decommissioning project or a periodic hygiene cycle.

The create-then-delete-same-day correlation is the highest-value single check available for this event, and it is worth running continuously rather than as a periodic review, since it catches exactly the disposable-account pattern that a static directory listing cannot. Join every 4726 against 4720 events for the same TargetSid within the preceding 24 hours; any match deserves investigation into what the account actually did during its brief existence, since the deletion itself was almost certainly a deliberate attempt to erase that history before anyone went looking for it.

Deletion of a currently privileged account is the second axis, and the threshold for review should be low: maintain the same privileged-account watchlist used for the reset, disable, and group-membership detections on this dataset, and treat any deletion touching that list as worth a look regardless of Subject identity, since privileged-account lifecycle changes should always have a documented trail, and their absence is informative on its own.

Mass deletion waves warrant the same volume-threshold treatment as mass disables, with an even lower tolerance given the irreversibility involved: a documented decommissioning project is easy to allowlist by Subject account and time window once identified, and any deletion volume outside that allowlist reaching a similar threshold deserves immediate escalation rather than a queued review, since the window to intervene closes the moment the deletion completes.

Subject identity remains the baseline secondary check: deletions performed by an account outside your known IT-admin or decommissioning-automation population are worth investigating on their own merits even when the Target account itself looks unremarkable, since an unfamiliar Subject exercising delete rights is itself worth understanding. False positives cluster around under-documented cleanup automation and infrequent but legitimate bulk decommissioning projects; both are best handled by explicitly allowlisting the responsible Subject accounts and time windows once confirmed, the same pattern that resolves false positives across every other account-management event in this dataset.