User Account Creation
editUser Account Creation
editIdentifies attempts to create new users. This is sometimes done by attackers to increase access or establish persistence on a system or domain.
Rule type: eql
Rule indices:
- winlogbeat-*
- logs-endpoint.events.*
- logs-windows.*
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: None
Tags:
- Elastic
- Host
- Windows
- Threat Detection
- Persistence
Version: 10
Rule authors:
- Elastic
Rule license: Elastic License v2
Investigation guide
edit## Triage and analysis ### Investigating User Account Creation Attackers may create new accounts (both local and domain) to maintain access to victim systems. This rule identifies the usage of `net.exe` to create new accounts. #### Possible investigation steps - Investigate the process execution chain (parent process tree). - Identify the user account that performed the action and whether it should perform this kind of action. - Identify if the account was added to privileged groups or assigned special privileges after creation. - Investigate other alerts related to the user/host in the last 48 hours. ### False positive analysis - Account creation is a common administrative task, so there is a high chance of the activity being legitimate. Before investigating further, verify that this activity is not benign. ### Related rules - Creation of a Hidden Local User Account - 2edc8076-291e-41e9-81e4-e3fcbc97ae5e ### Response and remediation - Initiate the incident response process based on the outcome of the triage. - Isolate the involved host to prevent further post-compromise behavior. - Delete the created account. - Reset the password for the user account leveraged to create the new account. ## Config If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
Rule query
editprocess where event.type in ("start", "process_started") and process.name : ("net.exe", "net1.exe") and not process.parent.name : "net.exe" and (process.args : "user" and process.args : ("/ad", "/add"))
Framework: MITRE ATT&CKTM
-
Tactic:
- Name: Persistence
- ID: TA0003
- Reference URL: https://attack.mitre.org/tactics/TA0003/
-
Technique:
- Name: Create Account
- ID: T1136
- Reference URL: https://attack.mitre.org/techniques/T1136/
-
Sub-technique:
- Name: Local Account
- ID: T1136.001
- Reference URL: https://attack.mitre.org/techniques/T1136/001/