Privileged group addition: establish rights and actual use
Investigate Windows and Active Directory group additions: actor, member, nesting, tokens and observed access before targeted containment.
Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.
An alert reports that an account has joined a sensitive group. The change deserves investigation, but several questions remain: who requested it, which member was added, what rights does the group actually provide, and were those rights used? Removing membership does not answer every question.
MITRE ATT&CK describes additional local or domain groups under T1098.007 as a possible persistence and privilege-escalation method. This reference describes potential abuse of a legitimate function; it does not make every administrative operation malicious. Source: MITRE ATT&CK, Additional Local or Domain Groups
This guide proposes a method independent of the SIEM, using Windows and Active Directory examples. Documented facts are separated from our recommendations. It describes neither a customer incident nor an available Seculogik integration.
1. Separate the actor, member and group
Microsoft's event 4732 documentation distinguishes the subject requesting addition, the added member and the destination group. It provides identifiers and notes that the member name can be absent for a local group. An empty name therefore does not establish that the member is unknown when its SID is present. Source: Microsoft, event 4732
Our recommendation is to preserve the original event and create three separate records. Capture each entity's SID, observed name and relevant domain or computer. Add the emitting host, original and receipt timestamps, and collection reference. Do not reduce the operation to “user became administrator”.
The technical identity recorded as actor does not necessarily identify the person controlling access. Check the administration context and authorisation with the appropriate owner. An approved request must match the observed member, group, scope and period, rather than a vaguely similar operation.
The subject's logon identifier concerns the actor making the change. Keep it separate from the added member's sessions, which will help investigate possible use of new access: a different question.
2. Read the group type before judging scope
Microsoft includes these events in security group management auditing:
- 4728: a member added to a domain security-enabled global group.
- 4732: a member added to a security-enabled local group; the event can occur on a domain controller, member server or workstation.
- 4756: a member added to a domain security-enabled universal group.
The definitions of 4728 and 4756 refer to 4732's fields, differing in group type. Source: Microsoft, Audit Security Group Management
We recommend confirming the group's location and scope in the directory or relevant system. “Local” does not automatically mean limited to the device displaying the alert: distinguish a domain-local group's context from a machine's own local group.
These numbers identify security-group membership changes, not a universal classification of privilege. A business group can provide highly sensitive access; an alarming name may no longer correspond to active permissions. Verify the actual function before assigning priority.
Where results are incomplete, inspect audit policy, covered systems and retention. An event absent from a search is insufficient to reconstruct membership history.
3. Follow nested membership to the resources
Microsoft describes security groups as collections that can contain accounts and other groups. Their scope constrains membership and permission assignment. The documentation also distinguishes user rights from resource permissions. Source: Microsoft, Active Directory security groups
Our recommendation is to reconstruct the relevant path between the added member and accessible resources. If a group joins another group, examine indirectly affected members rather than limiting investigation to the name in the alert. Preserve each step of that relationship and any scope restrictions encountered.
Then check what the group enables on target systems: local administration, particular rights, share access or delegation over objects, according to actual configuration. A label does not replace examination of applicable permissions and restrictions.
Present this inventory as a dated observation. Current membership and permissions do not necessarily describe the period of the addition. Seek available history before concluding that a currently visible path already existed, or that an absent path never existed.
4. Examine security context, not just current membership
Microsoft defines a Windows access token as the security context of a process or thread. It contains identity, group SIDs and privileges, among other information; the system produces a token at logon. Source: Microsoft, access tokens
Our recommendation is to distinguish directory membership, existing sessions' context and the context of a controlled new logon. Do not infer that an addition is already usable everywhere, or that removal cut every access path, merely by reading the membership list.
Have an authorised person check relevant sessions and processes. Treatment depends on the system, service and authorisation mechanism. Avoid promising a universal propagation or revocation delay; record the checks performed and what remains unverified.
Do not use the suspicious account to perform privileged production operations to “prove” its access. If testing is necessary, define a controlled identity and resource, a benign action, authorisation and an expected result. A test should reduce uncertainty without expanding the incident.
5. Investigate use without confusing capability with action
Event 4624 documents a session created on the accessed system. It provides logon context without itself demonstrating a privileged operation. Source: Microsoft, event 4624
Likewise, 4672 reports assignment of certain sensitive privileges to a new session. It does not describe their exercise and can reflect normal system activity. Source: Microsoft, event 4672
We therefore recommend two separate searches: the group-changing actor's activity and the added member's activity. Keep identity, host, relevant session and period with every correlation. Matching logon identifiers on two computers do not, by themselves, establish a relationship.
Then look for effects on relevant resources: configuration changes, administrative processing, object access or application-recorded actions, according to the evidence actually available. Distinguish possible access, an observed logon, a successful action and a denied attempt.
Document periods and categories outside coverage. “No use found in the sources examined” differs from “no use occurred”. Report search scope with the result.
6. Verify targeted response and its effect
Preserve memberships, relevant permissions and useful events before the change where urgency allows. Obtain authorisation for necessary removal or restrictions, with an owner and consideration for legitimate use. Address the access that enabled addition as well when the evidence warrants it.
After intervention, we recommend checking disappearance of the unauthorised path, treatment of relevant sessions and the outcome on the target resource separately. A successful removal command does not complete those three checks. Maintain risk-appropriate observation for recurrence as well.
Entirely fictional example: adding a support group is approved, but review discovers nested membership opening access to a resource outside scope. Approval of the addition does not remove the excessive-rights finding; that finding does not itself establish compromise. Document the legitimate change and the excessive access path separately.
The completed case should identify the operation, its authorisation, established rights, observed use, unknowns and verified measures. Our free investigation resources can help organise this evidence without conflating membership, privilege, use and attribution.