Admin rights granted
An existing macOS account was granted local administrator rights, or a new account was created already holding them.
What it detects
An existing macOS account was granted local administrator rights, or a new account was created already holding them. Membership of the admin group is what separates a user who can read their own files from one who can install software, load kernel extensions, unlock other users' data and disable the endpoint's own protections — so this is the step that turns a foothold on a Mac into control of it.
Three forms, all of which appear in the sudo record as the elevated command: dseditgroup -o edit -a <user> -t user admin, dscl . -append|-merge /Groups/admin GroupMembership <user>, and sysadminctl -addUser <user> -admin.
This is deliberately distinct from account CREATION: an attacker who elevates an account that already exists leaves no new account for a joiner report to show, and the account keeps its familiar name and history.
MITRE ATT&CK mapping
- T1098Account Manipulation· Persistence
False positives and triage
Legitimate on an admin's own machine and during provisioning — IT genuinely does promote users. Confirm the actor (user_name) is someone entitled to grant admin, that the promoted account is the one they meant, and that it happened during a known onboarding or support window. A promotion performed by a service account, from a remote session, or immediately after a login from a new address is the suspicious shape.
Reading membership is not modifying it: dseditgroup -o checkmember, dscl . -read /Groups/admin and plain dscl . -list do not match. Adding a user to a non-admin group (staff, a project group) does not match either.
Where an attacker already holds a root shell, the promotion may carry no sudo record at all — absence of this alert is not evidence that no promotion happened.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 80%. Source: rules/macos/admin_rights_granted.yaml, licensed under the Apache License 2.0.
id: macos.privilege_escalation.admin_rights_granted
version: 1.0.0
status: stable
severity: high
confidence: 0.8
platforms: [macos]
mitre_techniques: [T1098]
description: |
An existing macOS account was granted local administrator rights, or a new
account was created already holding them. Membership of the `admin` group is
what separates a user who can read their own files from one who can install
software, load kernel extensions, unlock other users' data and disable the
endpoint's own protections — so this is the step that turns a foothold on a Mac
into control of it.
Three forms, all of which appear in the `sudo` record as the elevated command:
`dseditgroup -o edit -a <user> -t user admin`, `dscl . -append|-merge
/Groups/admin GroupMembership <user>`, and `sysadminctl -addUser <user> -admin`.
This is deliberately distinct from account CREATION: an attacker who elevates an
account that already exists leaves no new account for a joiner report to show,
and the account keeps its familiar name and history.
match:
# The canonical category, not just the text: a successful `sudo` normalizes to
# `privilege`, so this cannot fire on someone merely mentioning the command in
# a mail or a shell-history import.
event_category: privilege
command_line_regex: '(?i)(dseditgroup\s+-o\s+edit\s+(-a|--addUser)\s+\S+\s+-t\s+user\s+admin\b|dscl\b.*\s-(append|merge)\s+/Groups/admin\b|sysadminctl\b.*\s-addUser\b.*\s-admin\b)'
false_positive_guidance: |
Legitimate on an admin's own machine and during provisioning — IT genuinely does
promote users. Confirm the actor (`user_name`) is someone entitled to grant
admin, that the promoted account is the one they meant, and that it happened
during a known onboarding or support window. A promotion performed by a service
account, from a remote session, or immediately after a login from a new address
is the suspicious shape.
Reading membership is not modifying it: `dseditgroup -o checkmember`, `dscl
. -read /Groups/admin` and plain `dscl . -list` do not match. Adding a user to a
non-admin group (`staff`, a project group) does not match either.
Where an attacker already holds a root shell, the promotion may carry no `sudo`
record at all — absence of this alert is not evidence that no promotion happened.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.