Why would an attacker create a new security group instead of adding directly to an existing privileged group?

Creating a new group as an intermediary provides several evasion advantages. First, monitoring rules that alert on additions to specific privileged groups (like Domain Admins) do not fire on additions to a new, unknown group — only a second-stage 4728 when that new group is added to Domain Admins triggers the alert, and by then the access is already established. Second, adding a group to Domain Admins looks less suspicious in audit logs than adding an individual user — groups are expected members of other groups. Third, the new group can be named to blend in with legitimate service or departmental groups, surviving visual reviews of Domain Admins membership. Fourth, the attacker can add multiple users to the backdoor group with individual 4728 events that each individually look like internal provisioning, rather than one obviously suspicious bulk addition.

How do I detect backdoor group creation?

The most reliable detection is a behavioral baseline: establish which accounts are authorized to create security groups (typically limited to AD provisioning service accounts and senior AD administrators) and alert on any 4727 from outside that list. Supplement this with a correlation rule that fires when a new group (from 4727) appears as the target in a 4728 event adding it to a privileged group within 60 minutes. Additionally, alert on any new group whose name has a Levenshtein distance of 1 or 2 from an existing privileged group name — this catches typosquatting. SIEM products like Sentinel and Splunk can implement this as a watchlist-based detection where new group names are compared against a protected groups list.

Is Event 4727 logged on every domain controller?

Group creation events are logged on the domain controller that processed the LDAP write — the DC that served the creator's session. Because AD replicates the group object to all other DCs, the group becomes visible on all DCs, but the 4727 event only appears on the DC that originally created the object. This means your detection needs to aggregate Security logs from all DCs, not just a primary DC. In environments that forward logs to a SIEM, this is handled automatically. In environments that monitor individual DCs, a gap in DC coverage means 4727 events can be missed if the attacker's connection was served by an unmonitored DC.

Scan your Security and Sysmon logs·Detection guides

Event ID 4727Audit SuccessSecurityT1136

Windows Event ID 4727 — Security-Enabled Global Group Created

Logged when a new security-enabled global group is created in Active Directory. Global security groups replicate to all domain controllers and are available domain-wide, making them effective persistence vehicles. Attackers create new global groups as backdoor persistence — a new group added to Domain Admins or other privileged groups is less visible in a membership audit than a directly added user account.

MITRE ATT&CK

Technique

T1136 · Create Account

Tactic

Persistence

View on attack.mitre.org →

Why It Matters

New group creation as a persistence technique exploits the tendency of defenders to audit group memberships rather than group creation. A new group named IT_Support or SVC_Monitoring that is quietly added to Domain Admins grants all of its members domain-wide elevated access. Unlike directly adding a user to Domain Admins (4728), the 4727 event for the group creation may go unnoticed if alerting focuses only on changes to well-known privileged groups. Detecting the full provisioning chain — new group created (4727) + user added to new group (4728) + new group added to Domain Admins (4728) — is the reliable detection signature.

Key Fields

Group NameThe name of the newly created global group. Names mimicking existing groups (IT_Admins vs IT-Admins, SVC_Monitoring vs SVC-Monitoring) are a typosquatting technique designed to avoid detection during visual audits of group membership lists.

Subject Account NameThe account that created the group. Group creation should be performed only by identity management systems, AD provisioning tools, or senior administrators. Any creation by a regular user account or unexpected service account is suspicious.

Group SIDThe newly assigned Security Identifier for the group. Record this SID — if the group is later deleted as part of cleanup (4730), the SID in the deletion event links back to this creation event.

Investigation Tips

1.Check for the full backdoor provisioning chain: search for 4720 (new user created) + 4727 (new group created) + 4728 (user added to new group) + 4728 (new group added to Domain Admins) all within a short time window and performed by the same Subject Account Name. This four-event sequence in minutes is automated backdoor provisioning.
2.Correlate with 4728 immediately after 4727: if a new group is created and a member is added to it within minutes (4728 where the group matches the new 4727 group), this is the attacker loading their backdoor group. The urgency scales with which groups the new group is subsequently added to.
3.Group name typosquatting: compare the new group name against your existing group catalog. Attackers deliberately choose names that are visually similar to legitimate groups to survive a casual AD review — IT_Admins vs IT-Admins, Domain Admins vs DomainAdmins, or locale-specific character substitutions.
4.Global groups replicate to all DCs: a 4727 event on one DC means the group exists across the entire domain. Unlike local group creation (4731), which is machine-specific, a backdoor global group created once grants access everywhere — treat 4727 with the same urgency as Domain Admins membership changes.

Related Event IDs

4728Member added to global group — the follow-on event; new group added to Domain Admins immediately after 4727 is the backdoor activation

4729Member removed from global group — attacker cleanup; group emptied before deletion

4737Global group changed — group rename or attribute modification to disguise the backdoor group

4720User account created — often paired with new group creation as part of full backdoor provisioning

Frequently Asked Questions

Why would an attacker create a new security group instead of adding directly to an existing privileged group?: Creating a new group as an intermediary provides several evasion advantages. First, monitoring rules that alert on additions to specific privileged groups (like Domain Admins) do not fire on additions to a new, unknown group — only a second-stage 4728 when that new group is added to Domain Admins triggers the alert, and by then the access is already established. Second, adding a group to Domain Admins looks less suspicious in audit logs than adding an individual user — groups are expected members of other groups. Third, the new group can be named to blend in with legitimate service or departmental groups, surviving visual reviews of Domain Admins membership. Fourth, the attacker can add multiple users to the backdoor group with individual 4728 events that each individually look like internal provisioning, rather than one obviously suspicious bulk addition.
How do I detect backdoor group creation?: The most reliable detection is a behavioral baseline: establish which accounts are authorized to create security groups (typically limited to AD provisioning service accounts and senior AD administrators) and alert on any 4727 from outside that list. Supplement this with a correlation rule that fires when a new group (from 4727) appears as the target in a 4728 event adding it to a privileged group within 60 minutes. Additionally, alert on any new group whose name has a Levenshtein distance of 1 or 2 from an existing privileged group name — this catches typosquatting. SIEM products like Sentinel and Splunk can implement this as a watchlist-based detection where new group names are compared against a protected groups list.
Is Event 4727 logged on every domain controller?: Group creation events are logged on the domain controller that processed the LDAP write — the DC that served the creator's session. Because AD replicates the group object to all other DCs, the group becomes visible on all DCs, but the 4727 event only appears on the DC that originally created the object. This means your detection needs to aggregate Security logs from all DCs, not just a primary DC. In environments that forward logs to a SIEM, this is handled automatically. In environments that monitor individual DCs, a gap in DC coverage means 4727 events can be missed if the attacker's connection was served by an unmonitored DC.

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 4727 →

See Event ID 4727 in your logs

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

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →