Event ID 4729: A member was removed from a security-enabled global group

Event 4729 is the direct counterpart to 4728: it fires when an account is removed from a security-enabled global group rather than added to one. The field schema mirrors 4728 almost exactly, SubjectUserSid, SubjectUserName, and SubjectLogonId for who performed the removal, MemberSid and MemberName for the account that was removed, TargetSid and TargetUserName for the group it was removed from, which makes the two events natural to correlate together despite the very different MITRE classification each one carries individually.

That classification difference is worth stating plainly: 4728, addition, maps to T1098 Account Manipulation and T1078 Valid Accounts, both escalation-flavored techniques, an attacker gaining rights they did not have. 4729, removal, maps instead to T1531, Account Access Removal, an impact-stage technique focused on denying access rather than gaining it. The same field schema, describing membership changes to the same class of group, carries an entirely different threat model depending on which direction the change runs.

Most 4729 activity is exactly what it looks like: routine offboarding, role changes that no longer require a given group's access, and periodic access-review cleanup removing memberships that accumulated past their useful need. None of this needs special scrutiny in isolation, and in most organizations the baseline volume here mirrors 4728's, a modest, steady trickle tied to normal personnel and role churn.

The pattern that turns a removal into a T1531 concern is who gets removed, not the removal mechanic itself. An attacker who has compromised an environment and wants to inhibit the response, or lock out the very administrators who would notice and undo the attacker's other changes, removes a known, legitimate administrator from a group they need for their job, Domain Admins, Group Policy Creator Owners, or a custom group tied to incident-response tooling. This is quiet sabotage: unlike disabling or deleting the admin's own account, which would be immediately obvious to that admin the next time they tried to log in, removing them from one specific group can go unnoticed for a while if the admin still has other access and does not immediately need the removed group's specific rights.

The add-then-remove pattern, covered from the addition side on the 4728 page, is detected with the identical correlation query run from this side: the same MemberSid appearing in a 4728 and then a 4729 within a short window, minutes rather than hours, indicates a transient privilege grant used for one action and then cleaned up, an attacker's attempt to minimize the window during which a point-in-time membership check would catch them.

Mass removal waves are the third pattern, and they carry a specific, less obvious threat model worth naming directly: an attacker dismantling a defensive lockout. If a security team has already responded to an earlier compromise by adding a break-glass response team to a privileged group, a wave of removals from that same group shortly afterward is the attacker actively working to undo the defenders' own containment action, which makes this pattern worth watching especially closely during and immediately after any active incident response.

Treat the baseline the same way as 4728's: routine, low volume, traceable to normal personnel and role changes, performed by a known, small population of group-management identities during business hours. Deviations from that baseline are what matter, and the two events are strong enough together that any detection built for one should query the other in the same pass.

The single highest-priority check is a removal targeting a known, currently active administrator or a member of a designated incident-response or break-glass group. Maintain that list explicitly, the same watchlist discipline used across every other privileged-account detection in this dataset, and alert on any removal touching it regardless of Subject identity or apparent justification, since a legitimate removal of an active admin from a group they still need is rare enough that a false alarm costs little compared to missing a real sabotage attempt.

The add-then-remove correlation deserves the same weight here as it does on the 4728 page, since it is the identical pattern viewed from its other half. Run it as a single query joining both event types by MemberSid rather than as two separate detections, since a MemberSid appearing in isolation in either event tells you less than the pair does together.

Mass removal waves need context-aware thresholds rather than a single fixed number: a wave during a documented offboarding project, a department closure, a contract ending for an entire vendor team, is explainable and traceable to a known Subject and a known business reason. The same volume of removals with no such explanation, particularly if it touches a group your security team relies on for incident response, or if it follows closely on the heels of a suspicious event elsewhere in the environment, should be escalated immediately rather than queued, since the entire point of this specific attack pattern is to degrade your ability to respond while you are still deciding whether to take it seriously.

Subject identity remains a useful secondary filter: removals performed by an account outside your known group-management population are worth a look on their own merits, the same standard applied to every other account-management event in this dataset. False positives cluster, predictably, around under-documented offboarding automation and legitimate but infrequent bulk access-review cleanups; document and allowlist the responsible Subject accounts once confirmed, and the residual noise from this event drops close to zero.