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

How oftenUncommon
Vendor calls itAudit Success
LogSecurity
SourceMicrosoft-Windows-Security-Auditing

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

Check whether the same account was added recently. Add and remove within a short window is the pattern.
Confirm a change record exists for the removal.
Check whether the removed account belongs to a person who still needs that access.
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.

Vendor documentation

Microsoft — Audit Security Group Management

Last reviewed 28 August 2026