System-level account management activity

Threat snapshot

In Active Directory environments, group membership changes are one of the most consequential actions that can occur. Adding an account to a privileged group grants it access to sensitive systems, administrative tools, and protected data. Removing an account from a group revokes that access. Both actions are routine parts of identity lifecycle management when performed by a human administrator following an approved process.

The threat this use case addresses is different: group membership changes initiated by the SYSTEM account rather than a named human administrator. When Windows itself, or a process running as SYSTEM, modifies group memberships, it is almost always because a piece of software is manipulating identity controls programmatically. That software may be a legitimate product performing an automated task, or it may be a threat actor who has elevated to SYSTEM and is silently granting their tools or accounts elevated access without any human interaction, approval, or audit trail. Log360 covers both sides of this threat with two detection rules: one for system-initiated group additions and one for system-initiated removals.

At a glance:

How this attack works

Windows logs group membership changes under Event ID 4728 (a member was added to a security-enabled global group) and Event ID 4729 (a member was removed from a security-enabled global group), as well as the local group equivalents under Event IDs 4732 and 4733. Each event record includes a Subject field that identifies the account responsible for making the change.

In normal identity administration, the Subject will be a named human administrator or a service account documented as having group management rights. When the Subject is NT AUTHORITY\SYSTEM, the change was made by the operating system itself or by a process running under the SYSTEM security context. This is the detection anchor for both Log360 rules.

Attackers who have escalated to SYSTEM-level access on a domain controller or a privileged workstation can use this context to modify group memberships without leaving a named human account in the audit trail. Tools like PowerShell scripts, custom service binaries, or built-in Windows utilities running as SYSTEM can add accounts to Domain Admins, Administrators, or any other sensitive group with no interactive logon required and no obvious attribution to a specific user. The same technique is used in the reverse direction: an attacker removing accounts from security groups to disable defensive tooling, revoke a competitor's access, or cause operational disruption.

Attack chain

The table below maps each stage of a system-initiated group manipulation attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A financial services organisation runs a Windows Server domain environment with Active Directory managing access to its core trading platform, client data repository, and internal reporting systems. A threat actor who gained access two weeks earlier via a phishing email has been operating under a compromised standard user account, slowly mapping the environment and identifying high-value targets.

Using a known local privilege escalation vulnerability on an unpatched workstation, the attacker elevates to SYSTEM. They deploy a lightweight PowerShell script that runs as a SYSTEM-level scheduled task. The script adds the attacker's compromised standard account to the Domain Admins group using ADSI calls. Because the script runs as SYSTEM, the Subject in the resulting Event ID 4728 log entry is NT AUTHORITY\SYSTEM, not a named administrator. The change does not appear in the organisation's IAM ticketing system because no human initiated it.

With Domain Admin rights now available, the attacker accesses the domain controller directly, dumps the NTDS.dit file, and extracts credential hashes for every account in the domain. They also use the SYSTEM-running script to remove the organisation's SIEM monitoring service account from the Event Log Readers group, preventing it from collecting logs from the domain controller going forward. Both the addition and the removal generate Windows Security events, but without Log360 rules specifically targeting SYSTEM as the Subject, neither event surfaces as an alert.

Why this happens
Most group membership monitoring focuses on who was added or removed, not on what account performed the change. Alerts typically fire on additions to sensitive groups regardless of the Subject. Without a specific rule targeting SYSTEM as the initiating account, the anomaly of a non-human identity making group changes goes undetected. The absence of a named administrator in the audit trail is precisely the signal that matters, and it is the signal that most environments are not configured to look for.

Business impact: What can go wrong

Undetected system-initiated group membership changes carry compounding consequences across identity, access, and operational security:

• Silent privilege escalation: an attacker who adds their account to Domain Admins or Backup Operators via SYSTEM context gains full administrative rights across the domain without any human approving the change, without a ticket in the IAM system, and without a named administrator in the audit log.
• Credential compromise at scale: Domain Admin access enables credential dumping from Active Directory. A single successful SYSTEM-initiated group addition can result in the compromise of every account credential in the domain.
• Monitoring blind spots: system-initiated group removals that target SIEM service accounts, monitoring agents, or Event Log Readers group members directly disable the organisation's ability to collect and analyse security events, creating a window of visibility loss during which the attacker operates freely.
• Access control bypass: removing accounts from groups that enforce data access controls can grant or revoke access to regulated data outside the normal IAM process, creating a compliance gap that may not be discovered until an audit or an incident review.
• Persistence without attribution: because SYSTEM is not a human account, group changes made under this context do not trigger IAM reconciliation workflows, identity governance reviews, or access certification processes. The change persists until it is manually discovered.
• Regulatory exposure: unauthorised modifications to privileged group memberships are a direct control failure under PCI DSS Requirement 7, HIPAA 164.312(a)(1), and ISO 27001 Annex A.9.2. If the change results in unauthorised data access, breach notification obligations may be triggered.

Indicators of compromise and detection signals

 

Prerequisites for detection using Log360

Before the System-Initiated Group Membership rules can fire reliably, ensure the following are in place:

• Windows Account Management auditing is enabled on domain controllers. Enable Audit Security Group Management under Advanced Audit Policy Configuration > Account Management, set to Success. This generates Event IDs 4728, 4729, 4732, and 4733 for group membership changes. Domain controllers are the authoritative source for these events in Active Directory environments.
• Sysmon is deployed on domain controllers and high-value servers with a configuration capturing Event ID 1 (Process Create). This provides the process context needed to identify which binary running as SYSTEM initiated the group membership change, which is essential for investigation and triage.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from domain controllers to Log360 in near-real-time. Group membership events that occur on domain controllers and are not forwarded promptly create a detection delay during which the attacker may already be using the elevated access.
• A baseline of known, legitimate SYSTEM-initiated group changes has been documented for your environment. Some software products do make automated group membership changes under SYSTEM context as part of their installation or update process. Knowing which products do this in advance significantly reduces investigation time when the rules fire.

Detecting system-level account changes using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rules

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rules: System-Initiated Group Membership Addition and System-Initiated Group Membership Removal. Configure an alert profile for the same.

Step 2: Read the alert

The alert will display the domain controller hostname, the Subject account (which will be SYSTEM), the target group name, the member account added or removed, and the timestamp. The most important fields to review immediately are the target group name and the member account. A standard user account added to Domain Admins under SYSTEM context requires immediate escalation. A monitoring service account removed from Event Log Readers under SYSTEM context requires immediate escalation and an assessment of whether log collection has been interrupted.

Investigating an alert

When the alert is triggered, an L2 analyst should work through the following steps:

• Identify the process that made the change. Open the Incident Workbench and load the process tree for the affected domain controller at the time of the event. Find the process running as SYSTEM that executed the group modification. Common culprits include PowerShell, cmd.exe running a script, net.exe, dsadd.exe, or a custom service binary. An unrecognised binary running as SYSTEM and modifying group memberships is a confirmed high-severity incident.
• Assess the target group and the member. Determine how sensitive the target group is and what the affected member account is. If a standard user account has been added to Domain Admins, Backup Operators, or any group with domain-wide administrative rights, treat this as an active privilege escalation and escalate immediately. If a monitoring service account has been removed from any group, assess whether log collection or security tooling has been disrupted.
• Trace the SYSTEM process back to its origin. Determine how the process running as SYSTEM was launched: a scheduled task, a service, a vulnerability exploit, or a parent process running under a different account that elevated. If the SYSTEM-level process was launched by a non-standard parent, identify that parent process and trace it back to the original compromise vector.
• Check for correlated activity on the affected domain controller. Query Log360 for all other events on the same domain controller in the 30 minutes surrounding the group change: authentication events, process creation events, file system activity, and other group or account modification events. Determine whether the group change was an isolated automated action or part of a broader post-exploitation sequence.
• Verify whether the change was an authorised automated action. Check your change management system and your documented inventory of software products that make SYSTEM-initiated group changes. If the change is not attributable to a known, documented automated process, treat it as malicious.

Escalation trigger
Escalate immediately to L3 if the member account added is a standard user account being added to Domain Admins, Enterprise Admins, or Schema Admins; if a monitoring or SIEM service account has been removed from any group; if both an addition and a removal fired in the same session window on the same domain controller; or if the process responsible for the group change is unrecognised or cannot be attributed to a known, legitimate software product.

Responding and remediating

Immediate containment

• Revert the group membership change immediately. If an account was added to a privileged group under SYSTEM context without authorisation, remove it from that group at once. If an account was removed from a group without authorisation, restore its membership. Document the original group state before making any changes.
• If the member account added to a privileged group has already been used to authenticate or access resources since the group change, disable that account immediately and treat all credentials accessible to it as compromised.
• If a monitoring or SIEM service account was removed from a group, restore its membership and verify whether log collection has been interrupted. Identify the time window during which the service account had reduced access and flag any log gaps for manual review.
• Isolate the domain controller or host on which the SYSTEM-initiated group change occurred if the responsible process cannot be immediately attributed to a known, legitimate automated task. Domain controllers are high-value targets and an unattributed SYSTEM-level process on a domain controller warrants immediate isolation.

Forensic preservation

• Export the Windows Security event log from the affected domain controller covering the full period from the first unusual event to the time of containment. This log is the primary record of all group changes, authentication events, and account modifications during the incident window.
• Export the Sysmon operational log from the affected domain controller to preserve the process creation records that identify what ran as SYSTEM and what its parent process was.
• If the responsible process was a script or a custom binary, preserve a copy of the file before remediation. Submit it to a sandbox environment for behavioural analysis to determine its full capability and whether it performed additional actions beyond the group membership change.

Eradication and recovery

• Identify and remove the mechanism that allowed a process to run as SYSTEM and make unauthorised group changes. This may be a malicious scheduled task, a compromised service, an exploit payload, or a persistence mechanism established earlier in the attack chain. Review all scheduled tasks, services, and startup entries on the affected domain controller.
• Conduct a full audit of all group membership changes on all domain controllers in the preceding 72 hours. Search specifically for Event IDs 4728, 4729, 4732, and 4733 where the Subject is SYSTEM across the entire domain, not just the affected domain controller.
• Force a password reset for all accounts whose group memberships were modified without authorisation, as well as for all accounts that authenticated to any system using elevated rights derived from the unauthorised group membership.

False positive guidance

Some legitimate software products and Windows operations do initiate group membership changes under SYSTEM context .The following scenarios may produce false positive alerts:

• Software installation and configuration: certain enterprise applications, including backup software, monitoring agents, and security products, add their service accounts to specific local groups during installation or upgrade. These changes are made by the installer running as SYSTEM. Verify the process name matches a known installer and the target group is consistent with the product's documented requirements.
• Windows Update and feature installation: some Windows roles and features modify local group memberships as part of their setup process when installed via Windows Update or Server Manager. These changes will be accompanied by Windows Update event log entries and will target specific, documented groups for the feature being installed.
• Domain join operations: when a workstation joins a domain, Windows performs several automated group operations under SYSTEM context as part of the join process. If this fires on a newly joined machine, verify the timing aligns with a documented domain join event for that host.
• Documented automation: if your organisation uses scripts or automation tools that run as SYSTEM to manage group memberships as part of provisioning workflows, these will trigger the rules. Document these processes explicitly, identify the specific groups they manage and the schedule on which they run, and create scoped exclusions covering those process names and target groups.

Key differentiator

Legitimate SYSTEM-initiated group changes are predictable, scoped, and attributable to a known software process. They affect specific, documented groups, occur at expected times, and the responsible process is a recognised vendor binary with a valid digital signature. An illegitimate SYSTEM-initiated group change will target high-privilege groups, occur outside expected software deployment windows, and the responsible process will either be an unrecognised binary, a script interpreter like PowerShell or cmd.exe, or a known binary running in an unexpected context.

Hardening and prevention

Detection is most effective when paired with controls that make SYSTEM-initiated group manipulation harder to execute and easier to spot:

• Enable Protected Users security group membership for all Domain Admin and privileged accounts. Members of Protected Users cannot be delegated, cannot use NTLM, and cannot have their credentials cached, significantly limiting what an attacker can do even after a successful SYSTEM-level group addition.
• Implement Active Directory tiering (also known as the Microsoft Enterprise Access Model) to prevent SYSTEM-level processes on Tier 1 workstations from being able to affect Tier 0 domain-level groups. Credential isolation between tiers limits the blast radius of a SYSTEM-level compromise on a workstation.
• Deploy Microsoft Local Administrator Password Solution (LAPS) on all endpoints to ensure that SYSTEM-level access gained on one workstation cannot be trivially replicated to other workstations via shared local admin credentials.
• Enable and monitor Windows Defender Credential Guard on all domain controllers and Tier 0 assets to prevent credential extraction from LSASS, which is the most common path to the credentials needed to perform domain-level group manipulation.
• Use Active Directory Delegation of Control to ensure that only specific, named service accounts with documented justification have the rights to modify group memberships. Regularly audit these delegations via the Active Directory ACL report to identify any undocumented rights that could be abused by a SYSTEM-level process.
• Enable Windows Event Forwarding from all domain controllers to Log360 with a minimum forwarding latency. Group membership changes on domain controllers are the highest-value events in an Active Directory environment and should reach the SIEM within seconds, not minutes, of occurring.
• Conduct quarterly reviews of all members of privileged groups including Domain Admins, Enterprise Admins, Schema Admins, Backup Operators, and Account Operators. Any account that cannot be attributed to an approved IAM ticket should be removed and investigated.