What is the difference between Event ID 4735 and Event ID 4732?

Event 4732 fires when an account is added to a local security group — it is a membership change. Event 4735 fires when the group itself is modified: its name, description, or type. In practice, an attacker uses both: 4732 to establish backdoor membership, then 4735 to rename the group and make the membership harder to detect in log reviews. Monitoring only 4732 (membership additions) misses the camouflage step — monitor 4735 alongside it, especially for group renames on Administrators, Backup Operators, and Remote Desktop Users.

Is a local security group rename always suspicious?

Not always — IT teams legitimately rename groups when responsibilities or naming conventions change. The suspicious patterns are: a rename immediately following a 4732 (membership addition) for the same group, a rename of a built-in sensitive group (Administrators, Backup Operators) rather than a custom group, a rename outside of a documented change window, or a rename by an account that is not a known IT admin. A custom group being renamed from 'ITHelpers' to 'BackupSvc' in isolation is low priority; the same rename immediately after a new account was added to it is high priority.

How do attackers use group renames to evade detection?

After adding a backdoor account to a sensitive local group via Event ID 4732, an attacker may rename the group (4735) to something that appears routine in AD group membership reports — names like 'MonitorAgents', 'SvcAccounts', or 'BackupOps' blend in with legitimate service groups. When a defender reviews the backdoor account's group memberships later, they see the renamed group name rather than 'Administrators' or 'Backup Operators', reducing the likelihood of immediate detection. The rename does not change the group's actual permissions — a renamed local Administrators group still grants full machine control.

Scan your Security and Sysmon logs·Detection guides

Event ID 4735Audit SuccessSecurityT1484

Windows Event ID 4735 — Security-Enabled Local Group Changed

Logged when a local security group's properties are modified — including its name, description, or type. This event covers changes to the group object itself, not membership changes. Membership additions and removals generate Event ID 4732 and 4733 respectively.

MITRE ATT&CK

Technique

T1484 · Domain Policy Modification

Tactic

Defense Evasion

View on attack.mitre.org →

Why It Matters

Group renames are an attacker technique for camouflaging backdoor membership. An attacker who adds their account to a sensitive local group (4732) may then rename that group to something that appears benign — 'BackupSvc', 'MonitorAgents', 'ITHelpers' — to make the membership appear routine in log reviews. Scope changes (converting a local group to a domain-local or universal group) can expand the blast radius of a compromised group membership beyond the original machine. 4735 is frequently overlooked in monitoring configurations, making it a low-visibility persistence technique.

Key Fields

Group NameThe name of the changed group — check if this is a sensitive built-in group (Administrators, Backup Operators, Remote Desktop Users) or a custom group that controls access to high-value resources

Changed AttributesWhich properties were modified — SAM Account Name (rename) is the most suspicious change; Description changes may indicate the attacker is covering their tracks; Group Type changes expand scope

Subject Account NameWho made the change — should be a known IT admin. A non-admin account modifying group properties is a privilege escalation indicator.

Subject Logon IDLinks to the modifier's 4624 session — correlate to verify the admin session is legitimate

Investigation Tips

1.Group rename on a sensitive group: if a local Administrators or Backup Operators group is renamed, investigate immediately — attackers rename these to camouflage membership added via 4732. Cross-check the current group name against your baseline inventory.
2.Correlate 4735 with preceding 4732 events for the same group — a membership addition (4732) followed by a group rename (4735) within a short window is the backdoor camouflage pattern. The attacker adds their account, then obscures the group's identity.
3.Group type changes: converting a local group to a universal or domain-local group can expand which systems respect the group's membership. This is unusual for security groups on member servers and should correlate with a documented IT change.
4.On domain controllers, group changes have domain-wide impact. 4735 events on DCs for groups outside of your expected change management windows are high priority.

Related Event IDs

4732Member added to local group — membership changes for the same group

4733Member removed from local group

4728Member added to global group — equivalent for domain-wide groups

4720Account created — may precede group changes as part of backdoor setup

Frequently Asked Questions

What is the difference between Event ID 4735 and Event ID 4732?: Event 4732 fires when an account is added to a local security group — it is a membership change. Event 4735 fires when the group itself is modified: its name, description, or type. In practice, an attacker uses both: 4732 to establish backdoor membership, then 4735 to rename the group and make the membership harder to detect in log reviews. Monitoring only 4732 (membership additions) misses the camouflage step — monitor 4735 alongside it, especially for group renames on Administrators, Backup Operators, and Remote Desktop Users.
Is a local security group rename always suspicious?: Not always — IT teams legitimately rename groups when responsibilities or naming conventions change. The suspicious patterns are: a rename immediately following a 4732 (membership addition) for the same group, a rename of a built-in sensitive group (Administrators, Backup Operators) rather than a custom group, a rename outside of a documented change window, or a rename by an account that is not a known IT admin. A custom group being renamed from 'ITHelpers' to 'BackupSvc' in isolation is low priority; the same rename immediately after a new account was added to it is high priority.
How do attackers use group renames to evade detection?: After adding a backdoor account to a sensitive local group via Event ID 4732, an attacker may rename the group (4735) to something that appears routine in AD group membership reports — names like 'MonitorAgents', 'SvcAccounts', or 'BackupOps' blend in with legitimate service groups. When a defender reviews the backdoor account's group memberships later, they see the renamed group name rather than 'Administrators' or 'Backup Operators', reducing the likelihood of immediate detection. The rename does not change the group's actual permissions — a renamed local Administrators group still grants full machine control.

Full Detection Guide Available

This event ID has a full detection guide with investigation steps, remediation advice, and example log entries.

View full guide for Event ID 4735 →

See Event ID 4735 in your logs

Upload a Windows Event Log (.evtx) file — EventPeeker automatically detects security-enabled local group changed patterns, maps findings to MITRE ATT&CK, and generates an AI triage report.

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →