AN0866: Analytic 0866
Detects unexpected use of usermod, gpasswd, or direct modification of /etc/group to elevate user group membership.
Analyst context for executives and security teams
This analytic matters because unexpected changes to Linux group membership can turn an ordinary account into a more privileged one, affecting access to systems, data, and administrative functions. For leaders, the practical question is whether the organization can see and review privileged group changes quickly enough to support incident response, audit evidence, and operational resilience.
Executive priority
Prioritize this as an identity and access governance control point for Linux environments. Security leaders should ask who is allowed to change group membership, whether those changes are logged centrally, and whether SOC or IR teams can distinguish approved administration from suspicious privilege expansion. It is especially relevant for compliance evidence around privileged access management and change accountability.
Technical view
For Linux platforms, validate monitoring for unexpected use of usermod and gpasswd, and for direct modification of /etc/group. Because no ATT&CK tactic, relationship context, or official detection logic is supplied, teams should treat this as a detection requirement rather than a complete rule. Focus on whether events capture the actor, target account, modified group, command or file-change method, host, timestamp, and whether the change was authorized.
Likely telemetry
- Linux process execution telemetry for usermod and gpasswd
- File integrity or audit telemetry for /etc/group modifications
- Authentication or session context identifying the user or process that made the change
- Centralized Linux system logs sufficient to correlate account changes with host and user activity
- Change-management or administrative approval records for privileged group membership updates
Detection direction
- Baseline expected administrative use of usermod and gpasswd on Linux hosts, then alert on unexpected users, hosts, times, or target groups.
- Monitor direct writes or changes to /etc/group, especially when not associated with approved administrative workflows.
- Tune for legitimate system administration, provisioning, configuration management, and break-glass activity to reduce false positives.
- Confirm alerts include enough context for triage: initiating user, command or file operation, target account, group added, and host.
- Because no official detection logic is provided, validate coverage through local testing and log review rather than assuming the analytic is implemented by name.
Mitigation priorities
- Define and enforce authorized paths for Linux group membership changes.
- Restrict who can run administrative account-management commands or modify account database files.
- Centralize logging for Linux account and group changes and retain it for incident response and audit needs.
- Review privileged group membership periodically and reconcile it against approved access records.
- Ensure incident response playbooks include validation and rollback of unauthorized Linux group membership changes.
Analyst notes and limits
The supplied object is a detection analytic for Linux focused on unexpected use of usermod, gpasswd, or direct modification of /etc/group to elevate user group membership. No tactics, ATT&CK relationships, aliases, labels, or official detection content were supplied, so this take frames practical validation and control direction without adding unsupported attribution or exploitation claims.
This assessment is limited to the official STIX fields, external reference, and the absence of relationship context provided. It does not establish adversary use, prevalence, impact, or existing customer detection coverage. Local environment evidence is required to define what is unexpected, which groups are sensitive, and which administrative workflows are legitimate.
Analytic 0866
Detects unexpected use of usermod, gpasswd, or direct modification of /etc/group to elevate user group membership.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | fe81f9862f4c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0866Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.