« Privilege Escalation via Parallels Appliance Extract Argument Injection Cloud Instance Metadata Credential Path HTTP Request »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.37

User Added to the Admin Group

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

User Added to the Admin Group

edit

Identifies users being added to the admin group. This could be an indication of privilege escalation activity.

Rule type: eql

Rule indices:

  • logs-jamf_protect*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: macOS
  • Use Case: Threat Detection
  • Tactic: Privilege Escalation
  • Data Source: Jamf Protect
  • Resources: Investigation Guide
  • Noise: Low
  • Performance: Fast
  • Rule Type: Event Correlation (EQL)
  • Platform: macOS

Version: 8

Rule authors:

  • Thijs Xhaflaire

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating User Added to the Admin Group

Members of the macOS admin group can use sudo, install software, and change system-wide settings. Adversaries who gain a foothold may add an account they control to this group, using tools such as dscl or dseditgroup, to escalate privileges or keep privileged access. This rule uses Jamf Protect telemetry to alert when a user is added to the admin group.

Possible investigation steps

  • Identify the account that was added to the admin group (user.name) and the account that performed the change (process.user.name), and confirm whether the change was requested or approved.
  • Review the process that made the change (process.executable, for example dscl, dseditgroup, sysadminctl, or System Settings), its parent (process.parent.executable), and its responsible process (process.responsible.executable) to determine whether the change was interactive or scripted.
  • !{investigate{"label":"Show events having the same responsible process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.responsible.entity_id}}","valueType":"string"}]]}}
  • !{investigate{"label":"Show events having the same parent process","providers":[[{"excluded":false,"field":"host.hostname","queryType":"phrase","value":"{{host.hostname}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.parent.entity_id}}","valueType":"string"}]]}}
  • Determine whether the added account was recently created, and whether it is hidden or has an unusual name or UID.
  • Search the timeline for activity that followed the elevation, such as new persistence items (LaunchAgents, LaunchDaemons, login items), software installation, additional user creation, or security setting changes.
  • Review authentication activity for the added account, including remote logins over SSH or Screen Sharing.
  • Review other alerts for the same host to identify the initial access or execution activity that preceded the group change.

False positive analysis

  • IT administrators, device management solutions, and privilege management tools legitimately add users to the admin group during provisioning or temporary elevation. Verify the change against change tickets or the expected management workflow.
  • When the activity is confirmed benign, create an exception for the specific management process or service account rather than for the admin group.

Response and remediation

  • Remove the account from the admin group if the change was not authorized.
  • Disable or delete the account if it was created by the attacker, and reset the credentials of any compromised legitimate account.
  • Review and revert changes made with the elevated privileges, such as persistence items, installed software, and modified security settings.
  • Isolate the host if follow-on malicious activity is identified.
  • Investigate how the attacker obtained the privileges required to modify group membership and remediate the initial access vector.
  • Escalate to the incident response team and check other macOS hosts for similar group membership changes.

Setup

edit

Setup

This rule requires data coming in from Jamf Protect.

Jamf Protect Integration Setup

Jamf Protect is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events incoming events and send data to the Elastic.

Prerequisite Requirements:

  • Fleet is required for Jamf Protect.
  • To configure Fleet Server refer to the documentation.

The following steps should be executed in order to add the Jamf Protect integration:

  • Go to the Kibana home page and click "Add integrations".
  • In the query bar, search for "Jamf Protect" and select the integration to see more details about it.
  • Click "Add Jamf Protect".
  • Configure the integration name.
  • Click "Save and Continue".

Rule query

edit
configuration where host.os.type == "macos" and event.type == "change" and
  event.action == "od_group_add" and group.name:"admin"

Framework: MITRE ATT&CKTM

« Privilege Escalation via Parallels Appliance Extract Argument Injection Cloud Instance Metadata Credential Path HTTP Request »