Event ID 4728: A member was added to a security-enabled global group

Event 4728 fires when an account is added as a member of a security-enabled global group. The global scope matters as much as the event itself: global groups can hold members from their own domain and be granted rights anywhere in the forest, which is structurally different from a local group scoped to a single machine's SAM database, that is 4732's territory, not this event's. A global-group addition is, by construction, a forest-wide reach change, not a single-machine one.

SubjectUserSid, SubjectUserName, and SubjectLogonId identify who requested the add, correlating back to their own 4624 logon session. MemberSid and MemberName identify the account being added, and TargetSid and TargetUserName identify the group receiving the new member. PrivilegeList is present in the schema but frequently shows as a dash in practice, since the specific privileges exercised during the operation are not always captured by the underlying audit subsystem; treat it as a bonus field when populated rather than something to depend on.

The group's identity is where the real severity signal lives, and Windows makes this checkable without any guesswork: the built-in high-privilege groups carry well-known relative identifiers, RIDs, that never change across domains. Domain Admins is RID 512 and Group Policy Creator Owners is RID 520. Matching TargetSid's trailing RID, or simply matching TargetUserName against those names directly, turns a generic group-membership-changed event into an unambiguous privilege-escalation signal the moment either group receives a new member. Enterprise Admins (519) and Schema Admins (518) are the groups people expect to see here, but they are universal groups in the forest root domain, so adding a member to them logs as 4756 and the alert for them belongs there.

The forest-wide reach of a global group compounds with whatever that group's rights actually grant. An addition to Domain Admins is an immediate, direct escalation to full domain control. An addition to a narrower, custom global group used to grant access to a specific application or file share is lower severity individually, but still worth tracking, since custom global groups accumulate rights over time in ways that are easy to lose track of without a periodic membership review.

One pattern is specific to global-group additions and worth calling out on its own: an add followed by a remove of the same MemberSid within a short window, minutes rather than hours. Some attack tooling and living-off-the-land scripts grant an account temporary membership in a privileged group just long enough to use the resulting elevated token for one action, a scheduled task, a remote command, a credential dump, then remove the membership immediately afterward specifically to shorten the window during which a defender reviewing current group membership would see anything out of place. This shape is invisible to a point-in-time membership audit and only shows up by correlating 4728 against its counterpart, 4729, member removed.

Additions to custom, lower-privilege global groups happen routinely as part of onboarding, project-access provisioning, and role changes, and the baseline for those groups is genuinely high volume and largely benign. The triage approach that scales is tiering groups by sensitivity rather than treating every 4728 identically: a small, explicitly tracked list of high-privilege built-in and custom groups gets alerted on every single addition, while the broader population of lower-sensitivity groups gets reviewed periodically rather than in real time.

For the tracked high-privilege tier, Domain Admins, Group Policy Creator Owners, and any custom global group your organization has designated as equivalently sensitive (keep Enterprise Admins and Schema Admins on the same list, watched through 4756), the honest baseline is that legitimate additions are rare and go through a documented change process. Any addition outside that process, from any Subject, warrants investigation before the new member does anything else, because the cost of confirming a legitimate but undocumented change is far lower than the cost of missing a real one.

Subject identity remains a strong secondary signal even within the tracked tier: additions made by a small, known group-management team during business hours carry a different prior than the same addition made by an account that has never touched group membership before, or by a service account with no documented group-administration role. An allowlist of accounts authorized to manage each sensitivity tier of group turns this into a mechanical check rather than a judgment call for every event.

The add-then-remove-in-minutes pattern deserves its own alert independent of group sensitivity tier, because the pattern itself, not just the destination group, is the signal. A membership that exists for under fifteen minutes was very likely never meant to be reviewed by anyone; that is not how legitimate access provisioning works, where memberships persist until a role changes or a project ends. Any occurrence of this pattern against a privileged group should be treated as a probable token grab regardless of which Subject account performed it, and investigated for what actions were taken during the brief window of elevated membership.

False positives in the high-privilege tier are genuinely rare precisely because legitimate changes there should already be uncommon and well documented; a false positive here is more often a real change that simply was not logged in the change-management system it should have been, which is itself worth fixing even when the addition turns out to be legitimate. In the broader tier of custom groups, false positives are the norm, and the fix is tiering by sensitivity rather than tuning thresholds on an event that, for most groups, is simply routine access administration.