User Account Creationedit

Identifies 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 guideedit

## 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 queryedit

process 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