Log Dejargonizer

Windows Security Log · Event 4728

Event 4728: A member was added to a global group

An account was added to a domain global group. When the group is Domain Admins or Enterprise Admins, the account now controls the entire domain — and there is no more consequential single line in the Windows log.

Also written as 4728Event ID 4728Domain Admins added

What it means for you

On a personal computer

This is a business network event and will not appear on a home PC.

For an analyst

Recorded on the domain controller that processed the change. Domain Admins, Enterprise Admins, Schema Admins, Account Operators, and Backup Operators should each be a standing alert with a named approver. In most environments the correct steady-state rate for these is zero.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

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

Subject:
  Security ID:    CORP\jbrooks-adm
  Account Name:   jbrooks-adm
  Account Domain: CORP
  Logon ID:       0x3E9A11

Member:
  Security ID:    CORP\svc-update
  Account Name:   CN=svc-update,CN=Users,DC=corp,DC=example

Group:
  Security ID:    CORP\Domain Admins
  Group Name:     Domain Admins
  Group Domain:   CORP

The fields that decide it

Everything else in the log line is context.

TargetUserName
The global group that gained a member.
  • Domain AdminsFull control of the domain. There is no higher-value change in the log.
  • Enterprise AdminsControl of every domain in the forest.
  • Schema AdminsCan alter the directory schema itself. Almost never legitimate outside a planned change.
  • Account OperatorsCan manage most accounts and groups. Frequently overlooked, nearly as powerful.
MemberName
The account added, written as a distinguished name.
MemberSid
The security identifier of the added account.
SubjectUserName
Who made the change.

Ordinary reasons this happens

Most of the time it is one of these.

  • A planned, approved addition to an administrative group during a change window.
  • Onboarding a new administrator through your normal process.
  • Identity management tooling applying an approved role assignment.
  • Building a new domain, where these groups are populated as part of setup.

When it is not ordinary

Domain takeover after compromising a privileged account.

What gives it awayAny addition to Domain Admins or Enterprise Admins with no matching change record.

ATT&CK T1098

Persistence through a group that draws less scrutiny.

What gives it awayAdditions to Account Operators, Backup Operators, or Server Operators, which grant substantial power but are rarely monitored.

ATT&CK T1098

A newly created account elevated to domain administrator.

What gives it awayA 4720 followed by a 4728 for the same account within minutes.

ATT&CK T1136.002

What to do next

  1. Confirm the change against your approval process before doing anything else. There should be a record.
  2. Read the group name. Domain Admins and Enterprise Admins are act-now; the operator groups deserve the same treatment.
  3. Identify who made the change and whether that account is itself behaving normally.
  4. Check whether the added account was created recently.
  5. Look for privileged sign-ins by the added account afterwards, and treat anything it touched as suspect.
  6. If the change is unexplained, remove the membership and treat the change-maker's account as compromised.

Queries to run

kql The alert query. In a healthy environment it should fire only during planned changes.
SecurityEvent | where EventID == 4728 | where TargetUserName has_any ('Domain Admins','Enterprise Admins','Schema Admins','Account Operators','Server Operators','Backup Operators') | project TimeGenerated, Group = TargetUserName, Member = MemberName, AddedBy = SubjectUserName
splunk
index=wineventlog EventCode=4728 | table _time Group_Name Member_Name Account_Name

Common questions

How do I know if someone was added to Domain Admins?

Event 4728 on your domain controllers, with the Group Name field reading Domain Admins. Because the volume is essentially zero in a stable environment, this makes a reliable standing alert rather than something you have to hunt for.

Which Active Directory groups should I monitor besides Domain Admins?

Enterprise Admins and Schema Admins for equivalent or greater reach, and then the operator groups — Account Operators, Server Operators, Backup Operators, and Print Operators. Those four grant substantial control, are rarely monitored, and are a well-known route to domain compromise precisely because nobody watches them.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026