User or Group Creation/Modification

ELASTIC detection rule by Elastic · Elastic License v2

This rule leverages the "auditd_manager" integration to detect user or group creation or modification events on Linux systems. Threat actors may attempt to create or modify users or groups to establish persistence on the system.

[metadata]
creation_date = "2024/06/20"
integration = ["auditd_manager"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule leverages the "auditd_manager" integration to detect user or group creation or modification events on Linux
systems. Threat actors may attempt to create or modify users or groups to establish persistence on the system.
"""
from = "now-9m"
index = ["auditbeat-*", "logs-auditd_manager.auditd-*"]
language = "eql"
license = "Elastic License v2"
name = "User or Group Creation/Modification"
note = """## 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 or Group Creation/Modification

In Linux environments, user and group management is crucial for access control and system administration. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes audit logs to monitor successful user or group changes, flagging potential persistence tactics by correlating specific actions with known threat behaviors.

### Possible investigation steps

- Review the audit logs to identify the specific user or group account that was created or modified, focusing on the event.action field values such as "changed-password", "added-user-account", or "added-group-account-to".
- Check the timestamp of the event to determine when the account change occurred and correlate it with any other suspicious activities or alerts around the same time.
- Investigate the source of the event by examining the host information, particularly the host.os.type field, to understand which system the changes were made on.
- Identify the user or process that initiated the account change by reviewing the associated user information in the audit logs, which may provide insights into whether the action was authorized or potentially malicious.
- Cross-reference the identified user or group changes with known threat actor behaviors or recent incidents to assess if the activity aligns with any known persistence tactics.

### False positive analysis

- Routine administrative tasks may trigger alerts when system administrators create or modify user or group accounts as part of regular maintenance. To manage this, consider creating exceptions for known administrative accounts or scheduled maintenance windows.
- Automated scripts or configuration management tools that manage user accounts can generate false positives. Identify these tools and exclude their actions from triggering alerts by whitelisting their processes or user accounts.
- System updates or software installations that require user or group modifications might be flagged. Review the context of these changes and exclude specific update processes or installation scripts from the rule.
- Temporary user accounts created for short-term projects or testing purposes can be mistaken for unauthorized access attempts. Implement a naming convention for temporary accounts and exclude them from the rule to reduce noise.
- Changes made by trusted third-party services or applications that integrate with the system may appear suspicious. Verify these services and add them to an exception list to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Review the audit logs to identify the specific user or group accounts that were created or modified, and disable or remove any unauthorized accounts.
- Reset passwords for any compromised or suspicious accounts to prevent further unauthorized access.
- Conduct a thorough review of system and application logs to identify any additional unauthorized changes or suspicious activities that may have occurred.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized account activities.
- Review and update access control policies and procedures to prevent similar incidents in the future, ensuring that only authorized personnel have the ability to create or modify user and group accounts."""
references = ["https://www.elastic.co/security-labs/primer-on-persistence-mechanisms"]
risk_score = 21
rule_id = "fcf733d5-7801-4eb0-92ac-8ffacf3658f2"
setup = """## Setup

This rule requires data coming in from Auditd Manager.

### Auditd Manager Integration Setup
The Auditd Manager Integration receives audit events from the Linux Audit Framework which is a part of the Linux kernel.
Auditd Manager provides a user-friendly interface and automation capabilities for configuring and monitoring system auditing through the auditd daemon. With `auditd_manager`, administrators can easily define audit rules, track system events, and generate comprehensive audit reports, improving overall security and compliance in the system.

#### The following steps should be executed in order to add the Elastic Agent System integration "auditd_manager" on a Linux System:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Auditd Manager” and select the integration to see more details about it.
- Click “Add Auditd Manager”.
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “auditd manager” to an existing or a new agent policy, and deploy the agent on a Linux system from which auditd log files are desirable.
- Click “Save and Continue”.
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/auditd_manager).

#### Rule Specific Setup Note
Auditd Manager subscribes to the kernel and receives events as they occur without any additional configuration.
However, if more advanced configuration is required to detect specific behavior, audit rules can be added to the integration in either the "audit rules" configuration box or the "auditd rule files" box by specifying a file to read the audit rules from.
For this detection rule to trigger, the following additional audit rules are required to be added to the integration:
```
-w /usr/sbin/groupadd -p x -k group_modification
-w /sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /sbin/addgroup -p x -k group_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /sbin/usermod -p x -k user_modification
-w /usr/sbin/userdel -p x -k user_modification
-w /sbin/userdel -p x -k user_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /sbin/useradd -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification
-w /sbin/adduser -p x -k user_modification
```
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Auditd Manager",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and
event.action in ("changed-password", "added-user-account", "added-group-account-to") and process.name != null
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique]]
id = "T1136"
name = "Create Account"
reference = "https://attack.mitre.org/techniques/T1136/"

[[rule.threat.technique.subtechnique]]
id = "T1136.001"
name = "Local Account"
reference = "https://attack.mitre.org/techniques/T1136/001/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.007"
name = "Additional Local or Domain Groups"
reference = "https://attack.mitre.org/techniques/T1098/007/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

532d4982-9a55-46ac-a878-fd4b49360018

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion