Windows Security Log · Event 4733

Event 4733: A member was removed from a local group

An account lost membership of a group on one machine. Most of these are not people at all — Group Policy and privileged access tooling rewrite local group membership on a schedule, which produces steady, harmless churn that hides the removals that do matter.

Also written as Event ID 47334733 local group removal

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

What it means for you

On a personal computer

An account on this PC lost some of its permissions. If it was removed from Administrators, it can no longer install software or change system settings.

For an analyst

The dominant benign cause here is policy, not people. Restricted Groups and Group Policy Preferences both enforce local group membership at every refresh and will remove anything they do not expect, producing recurring 4732/4733 pairs on a fixed cycle. Privileged access management tooling does the same when it grants and reclaims temporary admin rights. Baseline that churn first — what remains is small and worth reading. Unlike a domain group, this takes effect at the next token creation on that machine rather than waiting on a Kerberos ticket.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample

A member was removed from a security-enabled local group.

Subject:
  Security ID:    NT AUTHORITY\SYSTEM
  Account Name:   WKS-014$
  Account Domain: CORP
  Logon ID:       0x3E7

Member:
  Security ID:    CORP\mchen
  Account Name:   -

Group:
  Security ID:    BUILTIN\Administrators
  Group Name:     Administrators
  Group Domain:   Builtin

The fields that decide it

Everything else in the log line is context.

TargetUserName: The local group that lost a member.
MemberName: The account removed. Often a SID rather than a name when the account is from another domain or no longer resolvable.
MemberSid: The security identifier. More reliable than the name, and the only usable value when the account has been deleted.
SubjectUserName: Who made the change.

Ordinary reasons this happens

Most of the time it is one of these.

Group Policy Restricted Groups or Preferences enforcing local group membership at every refresh, which is the single largest source of these.
Privileged access tooling reclaiming temporary local administrator rights after a time window expires.
Machine build and imaging processes normalising local groups.
Software uninstallation removing a service account it created.
An administrator withdrawing local admin rights that were granted for a specific task.

When it is not ordinary

Removing a local account added earlier in the same intrusion.

What gives it awayA removal shortly after the matching 4732, from the same session, on a machine with no management tooling that touches local groups.

ATT&CK T1070

Withdrawing local access from security tooling.

What gives it awayA security or backup agent's service account removed from a local group it needs on one machine, which is quieter than disabling the agent outright.

ATT&CK T1562.001

Removing an administrator from a machine being worked on.

What gives it awayA legitimate administrator removed from the local Administrators group of a single host, with no corresponding policy change.

ATT&CK T1531

What to do next

Check SubjectUserName first. SYSTEM usually means policy rather than a person, and that accounts for most of the volume.
If it looks automated, confirm which Group Policy object or tool enforces local group membership on that machine.
For a named subject, check whether the same account was added recently — add then remove is the pattern.
Scope matters: this affects one machine, so ask what is special about that host rather than assuming domain-wide intent.
Resolve the member SID if only a SID is shown; a deleted account will never resolve to a name.
Check whether the removed account belongs to a security or backup agent.

Queries to run

kql Excluding SYSTEM removes the policy-driven churn, which is most of it.

SecurityEvent | where EventID == 4733 | where SubjectUserName != 'SYSTEM' | project TimeGenerated, Computer, Group = TargetUserName, Member = MemberName, RemovedBy = SubjectUserName

kql Machines where local group membership is being rewritten repeatedly — that is policy, and worth identifying so you can exclude it.

SecurityEvent | where EventID in (4732, 4733) | summarize changes = count() by Computer, TargetUserName, bin(TimeGenerated, 1d) | where changes > 4

powershell Current local administrators on a machine, which is the check that actually answers whether the removal stuck.

Get-LocalGroupMember -Group Administrators | Select-Object Name, PrincipalSource, ObjectClass

Common questions

Why does the same account keep getting added and removed from a local group?

Almost always Group Policy. Restricted Groups and Group Policy Preferences enforce a defined membership list at every policy refresh, adding what should be there and removing what should not. If something else adds a member out of band, you get a recurring add-remove cycle on the policy interval. Find the policy that manages that group rather than chasing the events.

When does removal from a local group take effect?

At the next token creation on that machine — practically, the next sign-in. An already-signed-in user keeps the access their current token grants. This is different from a domain group, where an existing Kerberos ticket can carry stale membership for hours.

Why does Event 4733 show a SID instead of an account name?

Because the account could not be resolved to a name when the event was written. That happens when the account has been deleted, when it belongs to another domain, or when the domain controller was unreachable. The SID is still the reliable identifier — resolve it separately, and note that a SID that will not resolve at all usually means the account is gone.

Mentioned by

Event 4757: A member was removed from a universal group

Vendor documentation

Last reviewed 28 August 2026