Additional Local or Domain Groups (T1098.007) is a sub-technique of Account Manipulation. MITRE files it under persistence and privilege escalation and lists Windows, macOS and Linux as platforms.
The core move is small: put an account the attacker controls into a group that carries more rights. No malware, no new service, just a membership change that can sit unnoticed for months.
How attackers use it
MITRE gives these examples of the technique at work:
- On Windows, the
net localgroupandnet groupcommands add existing users to local and domain groups. - On Linux, the
usermodcommand does the same. - Accounts may be added to the local administrators group on Windows to keep elevated privileges.
- Accounts may be added to the Remote Desktop Users group, which allows future RDP logins to the endpoint.
- Accounts may be added to VPN user groups to gain future access to the network.
- On Linux, accounts may be added to the sudoers group so they can keep using sudo and sudo caching for elevation.
- In Windows environments, machine accounts may also be added to domain groups, which lets the local SYSTEM account gain privileges on the domain.
The last one surprises people. A computer account in a privileged domain group is rarely on anyone's review list.
How to detect it
MITRE's detection strategy is titled Suspicious Addition to Local or Domain Groups, with one analytic per platform:
- Windows: unauthorized additions of users or machine accounts to privileged local or domain groups, such as Administrators and Remote Desktop Users.
- Linux: unexpected use of usermod or gpasswd, or direct modification of /etc/group, to raise group membership.
- macOS: use of dseditgroup or dscl to add users to privileged groups such as admin.
Practical log sources and signals:
- Windows Security log group membership change events, for example 4732 for a member added to a security-enabled local group and 4728 for a global group. These need the relevant account management auditing turned on.
- Process creation logs with command lines, so
net localgroup administratorswith an add action shows up with the user who ran it. - Linux auditd rules watching /etc/group and /etc/gshadow, plus execution of usermod and gpasswd.
- Machine accounts appearing in privileged domain groups.
Alert on membership changes outside a change window or made by someone who does not normally administer groups.
How to reduce the risk
MITRE does not list a formal mitigation on this page, so the steps below are general practice that follow from the description:
- Keep privileged groups small and review their membership on a schedule.
- Restrict who can modify groups, and separate that right from daily admin accounts.
- Audit group membership changes and send them to your monitoring system.
- Review VPN and Remote Desktop access groups with the same care as Administrators.
- Check that machine accounts are not members of privileged domain groups unless there is a documented reason.
Check your own environment
Read-only checks:
# Windows (cmd): list members of the local Administrators group
net localgroup administrators
# Windows (PowerShell): list members of Remote Desktop Users
Get-LocalGroupMember -Group "Remote Desktop Users"
# Linux: list members of common privileged groups (name varies by distribution)
getent group sudo
getent group wheel
# Linux (auditd): show loaded audit rules to see whether group files are watched
sudo auditctl -l
If nothing watches /etc/group, that is your first gap.
Quick check
Which Windows commands does MITRE name for adding users to groups?
net localgroup and net group, for local and domain groups respectively.
Why are machine accounts in domain groups a concern?
MITRE notes that adding machine accounts to domain groups lets the local SYSTEM account gain privileges on the domain.
