Detection: Linux Usermod Root UID Set
Description
The following analytic detects the use of usermod to set a user's UID to 0. This functionally sets the user as a root user with full permissions. This approach can be used to bypass regular privilege escalation mechanisms, giving the attacker full control over the system while appearing as a regular user in most monitoring tools.
Search
1
2| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
3as lastTime FROM datamodel=Endpoint.Processes
4WHERE Processes.process_name="usermod"
5 AND (Processes.process IN ("* -u 0 *", "* -u 0") OR Processes.process="*--uid 0*")
6BY Processes.action Processes.dest Processes.original_file_name
7 Processes.parent_process Processes.parent_process_exec Processes.parent_process_guid
8 Processes.parent_process_id Processes.parent_process_name Processes.parent_process_path
9 Processes.process Processes.process_current_directory Processes.process_exec
10 Processes.process_guid Processes.process_hash Processes.process_id
11 Processes.process_integrity_level Processes.process_name Processes.process_path
12 Processes.user Processes.user_id Processes.vendor_product
13
14| `drop_dm_object_name(Processes)`
15
16| `security_content_ctime(firstTime)`
17
18| `security_content_ctime(lastTime)`
19
20| `linux_usermod_root_uid_set_filter`
Data Source
Macros Used
| Name |
Value |
| security_content_summariesonly |
summariesonly=summariesonly_config allow_old_summaries=oldsummaries_config fillnull_value=fillnull_config`` |
| linux_usermod_root_uid_set_filter |
search * |
linux_usermod_root_uid_set_filter is an empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.
Annotations
| ID |
Technique |
Tactic |
| T1078 |
Valid Accounts |
Initial Access |
| T1098 |
Account Manipulation |
Persistence |
| T1548.001 |
Setuid and Setgid |
Privilege Escalation |
Exploitation
Delivery
Installation
Default Configuration
This detection is configured by default in Splunk Enterprise Security to run with the following settings:
| Setting |
Value |
| Disabled |
true |
| Cron Schedule |
0 * * * * |
| Earliest Time |
-70m@m |
| Latest Time |
-10m@m |
| Schedule Window |
auto |
| Creates Finding (Notable) |
Yes |
| Rule Title |
%name% |
| Rule Description |
%description% |
| Notable Event Fields |
user, dest |
| Creates Intermediate Finding (Risk Event) |
Yes |
TTP detections generate a Finding (Notable) and may generate Intermediate Findings (Risk Events) for associated entities.
Implementation
The detection is based on data that originates from Endpoint Detection and Response (EDR) agents. These agents are designed to provide security-related telemetry from the endpoints where the agent is installed. To implement this search, you must ingest logs that contain the process GUID, process name, and parent process. Additionally, you must ingest complete command-line executions. These logs must be processed using the appropriate Splunk Technology Add-ons that are specific to the EDR product. The logs must also be mapped to the Processes node of the Endpoint data model. Use the Splunk Common Information Model (CIM) to normalize the field names and speed up the data modeling process.
Known False Positives
Setting a user's UID to 0 is extremely rare in legitimate administration — there is almost no valid operational reason to create a second root-equivalent account this way. False positives are expected to be very low. Verify any alert against change management records before dismissing.
Associated Analytic Story
Finding
| Title |
Entity Field |
Entity Type |
Risk Score |
| Linux Usermod Root UID Set identified on $dest$ by $user$ via $process_name$ |
user |
user |
50 |
| Message |
Entity Field |
Entity Type |
Risk Score |
| Potential Usermod Root UID Set by $user$ on $dest$ via $process_name$. |
dest |
system |
50 |
Threat Objects
| Field |
Type |
| process_name |
process_name |
| parent_process_name |
parent_process_name |
References
Detection Testing
| Test Type |
Status |
Dataset |
Source |
Sourcetype |
| Validation |
✅ Passing |
N/A |
N/A |
N/A |
| Unit |
✅ Passing |
Dataset |
Syslog:Linux-Sysmon/Operational |
sysmon:linux |
| Integration |
✅ Passing |
Dataset |
Syslog:Linux-Sysmon/Operational |
sysmon:linux |
Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI.
Alternatively you can replay a dataset into a Splunk Attack Range
Source: GitHub |
Version: 1