Log Dejargonizer

Windows Security Log · Event 4756

Event 4756: A member was added to a universal group

An account joined a universal group, which applies across every domain in the forest. Enterprise Admins and Schema Admins are universal groups — which makes this the widest-reaching of the three group-membership events.

Also written as Event ID 47564756 universal group

What it means for you

For an analyst

Monitor this alongside 4728 and 4732 — an attacker who knows you watch Domain Admins may reach for a universal group instead. Enterprise Admins and Schema Admins should each have a named, approved membership list and a steady-state change rate of zero.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A member was added to a security-enabled universal 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\Enterprise Admins
  Group Name:     Enterprise Admins
  Group Domain:   CORP

The fields that decide it

Everything else in the log line is context.

TargetUserName
The universal group that gained a member.
  • Enterprise AdminsControl of every domain in the forest. The highest privilege in Active Directory.
  • Schema AdminsCan alter the directory schema itself. Almost never legitimate outside a planned change.
MemberName
The account added, as a distinguished name.
MemberSid
Its security identifier.
SubjectUserName
Who made the change.

Ordinary reasons this happens

Most of the time it is one of these.

  • An approved change during a planned forest-wide administrative task.
  • Schema Admins populated temporarily for a schema extension, then emptied again.
  • Onboarding a forest administrator through your normal process.
  • Identity tooling applying an approved role.

When it is not ordinary

Forest-wide takeover.

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

ATT&CK T1098

Preparing a schema change to establish persistence.

What gives it awayAddition to Schema Admins outside a planned schema extension.

ATT&CK T1098

Choosing a universal group to avoid a rule that only watches Domain Admins.

What gives it awayAdditions to universal groups by an account that has recently been behaving unusually.

ATT&CK T1098

What to do next

  1. Confirm the change against your approval process before anything else.
  2. Treat Enterprise Admins and Schema Admins as act-now regardless of who made the change.
  3. Check whether the added account was created or modified recently.
  4. Look for privileged sign-ins by the added account afterwards.
  5. If unexplained, remove the membership and treat the change-maker's account as compromised.

Queries to run

kql All three group-membership events together. Watching only one leaves an obvious gap. 
SecurityEvent | where EventID in (4756, 4728, 4732) | where TargetUserName has_any ('Enterprise Admins','Schema Admins','Domain Admins','Administrators') | project TimeGenerated, EventID, Group = TargetUserName, Member = MemberName, By = SubjectUserName

Common questions

What is the difference between a universal, global, and local group?

Scope. A local group applies to one machine, a global group to one domain, and a universal group to every domain in the forest. That is why Enterprise Admins and Schema Admins are universal — and why an addition to one has the widest blast radius of the three.

Which group-membership events should I monitor?

All three: 4732 for local, 4728 for global, and 4756 for universal. Rules that watch only Domain Admins miss both the local Administrators group on individual machines and the forest-wide universal groups, and attackers are well aware of which one people forget.

Read next

Vendor documentation

Last reviewed 28 August 2026