Privilege Escalation — Gaining Admin and Domain Access

MITRE ATT&CK

Security Relevance

Domain Admin access is the endgame for most Active Directory attacks. With it, an attacker can read all credentials from domain controllers (DCSync attack), create golden tickets for persistent access, deploy ransomware to all domain-joined systems simultaneously, and modify any object in the directory. Privilege escalation events are high-fidelity signals — unlike noisy events such as failed logons, unauthorized group membership changes and unexpected admin logons have very low false-positive rates and should always trigger immediate investigation.

Indicators of Malicious Use

• ⚑Event ID 4728: Account added to Domain Admins, Enterprise Admins, or Schema Admins — any of these is a critical alert requiring immediate investigation.
• ⚑Event ID 4732: Account added to local Administrators group on a server or domain controller — lateral movement combined with local privilege escalation.
• ⚑Event ID 4720 followed within minutes by 4728/4732 — attacker created a backdoor account and immediately escalated it.
• ⚑Event ID 4672: SeDebugPrivilege assigned to an account that is not a known administrator — allows reading and writing any process memory including LSASS.
• ⚑Event ID 4794: DSRM password changed on a domain controller — creates a persistent offline backdoor into every DC.
• ⚑Event ID 4624 Type 10 (RDP) or Type 3 (network) to a domain controller from an unexpected account or workstation.
• ⚑Multiple 4672 events from the same non-admin account across different systems in quick succession — token impersonation or pass-the-hash with a stolen admin credential.

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:  j.smith       ← the account that made the change
  Logon ID:      0x4A3F1

Member:
  Account Name:  svc-monitor   ← newly created backdoor account

Group:
  Group Name:    Domain Admins ← highest-privilege group in AD
  Group Domain:  CORP

[Preceded 3 minutes earlier by Event ID 4720: svc-monitor account created]

Investigation Steps

1. 1.Identify what was added to what — Domain Admins changes are critical, local Administrators changes are high priority. Check the group name in the event.
2. 2.Check who made the change (Subject account) — if it was an unexpected account, investigate how that account gained the rights to modify group membership.
3. 3.Look for Event ID 4720 in the 30 minutes before — was the newly added account recently created? A new account immediately elevated to admin is a strong backdoor indicator.
4. 4.Check Event ID 4624 for the newly escalated account — has it already been used? What systems has it logged into and from where?
5. 5.Review all domain controller logs for 4794 (DSRM password change) — this is often the next step after achieving Domain Admin.
6. 6.Check for DCSync activity — a Domain Admin account making unusual LDAP queries or triggering 4662 events with replication GUIDs indicates credential harvesting from AD.
7. 7.Audit all current members of Domain Admins, Enterprise Admins, and Schema Admins — compare against your known baseline.

Common False Positives

• ◎Planned IT provisioning — new admin accounts and group membership changes should match open helpdesk tickets. Always verify with the change management system.
• ◎Automated provisioning systems (ServiceNow, Okta, SailPoint) — identity management platforms modify group memberships automatically. Verify the Subject account matches the automation service account.
• ◎Active Directory migration or restructuring — domain migrations involve large volumes of group membership changes. Verify against the project plan.
• ◎Testing environments — AD labs and non-production domains may have more permissive account management. Ensure production DC logs are not mixed with test environment data.

Remediation

• ✓Remove any unauthorized accounts from privileged groups immediately using Active Directory Users and Computers or PowerShell.
• ✓Disable any unauthorized or backdoor accounts (4720 — newly created accounts added to admin groups) pending investigation.
• ✓Reset credentials for all accounts that were added to privileged groups during the suspected compromise window — assume they are known to the attacker.
• ✓Enable Protected Users security group for all Tier 0 accounts — this prevents NTLM authentication, credential caching, and Kerberos delegation for the highest-privilege accounts.
• ✓Deploy a Just-in-Time (JIT) privileged access solution — admin rights should be time-limited and require approval, not permanently assigned.
• ✓Alert on all changes to Domain Admins, Enterprise Admins, and Schema Admins in your SIEM — these events should page an analyst 24/7.
• ✓Conduct a full AD security assessment if unauthorized privilege escalation is confirmed — assume the attacker has had full domain access and begin incident response.

Related Event IDs

Related Detection Guides

Frequently Asked Questions

Which event IDs are the most reliable indicators of Domain Admin escalation?

Event ID 4728 (member added to global security group) is the primary signal — filter specifically for Group Name = 'Domain Admins', 'Enterprise Admins', or 'Schema Admins'. Event ID 4732 covers local Administrators group additions on individual systems. Event ID 4720 followed within minutes by 4728 is the backdoor account creation pattern. Event ID 4794 (DSRM password change on a domain controller) is a separate escalation vector that creates a persistent offline admin backdoor on every DC.

What is SeDebugPrivilege and why does it matter for privilege escalation?

SeDebugPrivilege allows a process to read and write the memory of any other process on the system — including LSASS, which holds credential hashes. It is assigned to members of the local Administrators group by default. When Event ID 4672 shows SeDebugPrivilege being granted to a non-admin account, it means that account has somehow obtained a capability reserved for administrators. Mimikatz requires SeDebugPrivilege before dumping LSASS (privilege::debug is the first command), making 4672 with SeDebugPrivilege a reliable pre-credential-dump indicator.

How do I tell if a DSRM backdoor was created on a domain controller?

Event ID 4794 ('An attempt was made to set the Directory Services Restore Mode administrator password') fires only on domain controllers when the DSRM account password is changed. Any 4794 event outside a planned DC recovery operation is suspicious. DSRM is an offline administrative account on each DC — once its password is known, an attacker can reboot the DC into Directory Services Restore Mode and access the local administrator account, bypassing all Active Directory authentication. This is detected by EventPeeker as a critical finding.

What is the difference between privilege escalation and lateral movement?

Privilege escalation is gaining higher permissions on a system you already have access to — moving from standard user to local admin, or from local admin to Domain Admin. Lateral movement is spreading access to additional systems — moving from one host to another. In practice, attackers often alternate: gain initial foothold (low privilege) → escalate locally → move laterally to a new system → escalate again. Detecting both together is important: lateral movement without escalation may stay contained; escalation on a DC is the point of no return in an Active Directory compromise.