Log Dejargonizer

Windows Security Log · Event 4757

Event 4757: A member was removed from a universal group

An account lost membership of a forest-wide group. Removal from Enterprise Admins is usually correct housekeeping — unless it happens shortly after an addition nobody requested, which is what covering tracks looks like.

Also written as Event ID 47574757 universal group removal

What it means for you

For an analyst

Watch this in the same rule as 4729 and 4733. An attacker who adds an account to a privileged group to do a job will often remove it afterwards, and the removal is frequently the event that survives when the addition was missed.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A member was removed from 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 lost a member, such as Enterprise Admins.
MemberName
The account removed, 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.

  • Cleanup after a planned forest-wide task finished.
  • Emptying Schema Admins after a schema extension, which is the recommended practice.
  • Offboarding a forest administrator.
  • Access reviews removing membership nobody could justify.

When it is not ordinary

Removing an account added earlier during an intrusion.

What gives it awayA removal shortly after the matching 4756, by the same session, with no change record.

ATT&CK T1070

Removing a rival administrator's forest-wide access.

What gives it awayAn unexplained removal of a legitimate administrator from Enterprise Admins.

ATT&CK T1531

What to do next

  1. Check whether the same account was added recently. Add and remove within a short window is the pattern.
  2. Confirm a change record exists for the removal.
  3. Check whether the removed account belongs to a person who still needs that access.
  4. Read who made the change and whether they administer forest-level groups.

Queries to run

kql Forest-wide privilege granted and revoked inside a day. Legitimate access changes rarely look like this. 
let added = SecurityEvent | where EventID == 4756 | project AddTime = TimeGenerated, Group = TargetUserName, Member = MemberName;
let removed = SecurityEvent | where EventID == 4757 | project RemTime = TimeGenerated, Group = TargetUserName, Member = MemberName, By = SubjectUserName;
added | join kind=inner removed on Group, Member | where RemTime - AddTime < 24h

Common questions

Why watch group removals as well as additions?

Because an attacker who grants themselves privilege usually gives it back when finished, and if you only alert on additions you may have missed the one that mattered. The removal is often the surviving evidence — and an addition followed by a removal within a day, with no ticket for either, is a much stronger signal than either event alone.

What is a universal group and why does it get its own event?

Universal groups are visible across every domain in an Active Directory forest, which makes them the natural home for forest-wide privileged groups such as Enterprise Admins. Windows uses a separate event ID for each group scope — 4757 for universal, 4729 for global, 4733 for domain local — so a rule watching only one scope silently misses changes to the others.

Does the removal take effect immediately?

Not for anyone already signed in. Group membership is baked into the Kerberos ticket issued at logon, so a user removed from a group keeps the access that ticket grants until it expires — commonly up to ten hours by default. If the removal is a response to an incident rather than housekeeping, disable the account or force a ticket refresh; the removal alone does not end existing access.

How do I find out who performed the removal?

The Subject fields in the event record the account and logon ID that made the change. Take the logon ID and find the matching Event 4624 to get the source address and logon type, which tells you where the change was made from as well as by whom. On a domain controller, that pairing is usually the difference between a routine administrative action and one worth questioning.

Read next

Vendor documentation

Last reviewed 28 August 2026