Account Persistence — Backdoor Accounts and Unauthorized Group Changes

Attackers who gain domain admin privileges frequently create backdoor accounts or add existing accounts to privileged groups as a persistence mechanism. Even if their primary access is revoked, these hidden accounts provide re-entry. Event IDs 4720, 4728, and 4732 are the core detection signals.

Severity

Critical

ATT&CK Tactic

Persistence

Common attacker usage

Creating new domain or local accounts with administrator privileges · Adding attacker-controlled accounts to Domain Admins, Enterprise Admins, or local Administrators · Modifying existing service or system accounts to add administrative privileges · Enabling disabled accounts (4722) that can be used as backdoors · Changing account properties to hide the account from standard directory queries

Investigate immediately if

!New account created outside of normal IT provisioning windows (nights, weekends)
!Any account added to Domain Admins, Schema Admins, or Enterprise Admins
!Account created and immediately added to a privileged group (4720 + 4728 within seconds)
!A service account or system account receiving new group memberships
!Account creation or modification occurring on a domain controller from an unexpected source

MITRE ATT&CK

Technique

T1136 · Create Account

Tactic

Persistence

View on attack.mitre.org →

Security Relevance

Backdoor accounts are one of the most durable persistence techniques available to an attacker. Once a domain admin account is created or an existing account is elevated, the attacker retains access even after the initial compromise vector is closed, credentials are rotated, or the original malware is removed. These events should trigger immediate investigation rather than waiting for a SIEM alert threshold.

Indicators of Malicious Use

⚑Event ID 4720 followed within seconds by 4728 or 4732 for the same account
⚑New account with a name resembling a service account or system account (e.g. svc_update$, SUPPORT_388945a0)
⚑4728: Account added to Domain Admins, Schema Admins, Enterprise Admins, or Backup Operators
⚑Account creation from an interactive session on a domain controller
⚑4738: Account properties modified — check for changes to AdminCount, UserAccountControl, or SIDHistory

Example Log Entry

Log Name: Security
Source:    Microsoft-Windows-Security-Auditing
Event ID:  4728

A member was added to a security-enabled global group.

Subject:
  Account Name:  CORP\DomainAdmin
  Logon ID:      0x3E7

Member:
  Security ID:   CORP\svc-backup2

Group:
  Group Name:    Domain Admins
  Group Domain:  CORP

Investigation Steps

1.Check who created the account (Subject in 4720) — verify it was a legitimate IT provisioning action.
2.Check who added the account to the group (Subject in 4728/4732) — this may be a different actor.
3.Look for associated 4624 logons using the new account — if the account is already being used, escalate immediately.
4.Check for similar patterns across the domain: Get-ADUser -Filter * -Properties Created | Where-Object {$_.Created -gt (Get-Date).AddDays(-7)}
5.Review all privileged group memberships for unexpected additions: Get-ADGroupMember 'Domain Admins'
6.Check whether the Subject account itself shows signs of compromise (recent 4625 spikes, unusual logon hours).

Check your own logs for this technique — upload an EVTX file for instant detection, no account required.

Upload EVTX →See sample

Common False Positives

◎Legitimate IT provisioning of new staff accounts during onboarding
◎Temporary elevation of accounts for project work (should have a change ticket)
◎Automated provisioning systems creating service accounts
◎HR-driven account creation for contractors or temporary staff

Remediation

✓Immediately disable and rename the backdoor account: Disable-ADAccount -Identity <account>
✓Remove from all privileged groups and audit all group memberships it had.
✓Reset passwords for all accounts that were elevated during the window of compromise.
✓Enable alerting on all future 4720, 4728, 4732 events via SIEM with near-real-time notification.
✓Implement a Privileged Access Management (PAM) solution with just-in-time admin elevation.
✓Review DSRM password change (4794) — attackers often combine account persistence with DSRM backdoors.

Related Event IDs

4720User account created — the backdoor account creation event

4722Account enabled — previously disabled accounts re-enabled as backdoors

4732User added to local group — local Administrators group membership change

4738User account changed — property modifications to hide or escalate the account

Related Detection Guides

Scheduled Task Abuse→Suspicious Service Installation→WMI Persistence→Registry Run Key Persistence→Privilege Escalation→Lateral Movement→Credential Dumping→Event ID 4720 — User Account Created→Event ID 4728 / 4732 — User Added to Privileged Group→

Analyze your Windows Event Logs

Upload an .evtx file from servers, domain controllers, or endpoints — get instant detections, MITRE mappings, and an AI-generated triage report.

Detect this technique in your logs →

← All detection guides·Analyze EVTX Logs Free →