Artifact Analysis: Linux Accounts & Privileges

Note

Executive Summary: Unlike Windows, which relies on the binary SAM (Security Account Manager) database, Linux operating systems store user identities, passwords, and group privileges in plain text files. For DFIR analysts performing post-mortem analysis on a disk image, auditing /etc/passwd, /etc/shadow, and /etc/group is a mandatory step to uncover backdoor accounts, identify lateral privilege escalation, and map the threat actor’s persistence mechanisms.

1. The User Directory (/etc/passwd)

This file defines all human and service accounts, their Unique Identifiers (UIDs), and their operating environments. Because it is globally readable (rw-r--r--), it is heavily targeted during the attacker’s reconnaissance phase.

Format: username:password_placeholder:UID:GID:Comment:Home_Directory:Shell

When analyzing a mounted forensic image (e.g., at /mnt/analysis/), analysts must hunt for three specific anomalies:

A. The Hidden Root (UID 0)

Only the root account should possess a User ID of 0. Threat actors often create a seemingly benign account (e.g., support or sysupdate) and assign it UID 0. The Linux kernel evaluates privileges based on the UID, not the username. Thus, this account is a covert, fully privileged backdoor.

# Hunt for any account with UID 0
awk -F: '($3 == "0") {print}' /mnt/analysis/etc/passwd

B. Suspicious Service Shells

Service accounts designed to run background daemons (www-data, apache, mysql, postgres) should never possess an interactive login shell. Their shell field should explicitly be set to /usr/sbin/nologin or /bin/false. If an analyst discovers that www-data has been assigned /bin/bash or /bin/sh, it is a near-certain indicator that the attacker modified the account to spawn an interactive reverse shell (often following a web application exploit).

C. Recent Additions

New users are appended to the bottom of the /etc/passwd file. Reviewing the last 5-10 lines rapidly exposes newly created backdoor accounts.

2. The Secrets Vault (/etc/shadow)

This file contains the actual password hashes and account expiration policies. To protect credentials, it is strictly readable only by root.

Format: username:hash:lastchg:min:max:warn:inactive:expire

A. Empty Passwords

If the hash field is entirely empty or contains invalid authentication strings allowing bypass (depending on PAM configurations), the account can be accessed via SSH or local TTY without a password. This is a critical misconfiguration or intentional backdoor.

B. Service Accounts with Hashes

Legitimate service accounts (like bin or daemon) typically have an asterisk (*) or an exclamation mark (!) in the hash field, locking them out of password-based authentication. If a service account possesses a long cryptographic hash (e.g., starting with $6$ for SHA-512 or $y$ for yescrypt), an attacker has explicitly set a password to hijack the account for persistence.

C. Hash Reuse (Cloned Passwords)

Threat actors may copy the hash of a known compromised user and paste it into the shadow entry of a newly created backdoor account. If two distinct usernames share the exact same hash string, it indicates manual, unauthorized manipulation of the shadow file.

3. Privilege Escalation (/etc/group)

This file defines group memberships. Analyzing it reveals “horizontal” or “vertical” privilege escalation.

DFIR analysts must identify which users are members of the “God Groups”—groups that grant the ability to execute commands as root (usually via sudo).

• wheel: The default administrative group on RHEL/CentOS systems.
• sudo: The default administrative group on Debian/Ubuntu systems.
• root: GID 0.
• docker: Critical Threat Vector. Any user added to the docker group essentially possesses root privileges. A threat actor in this group can spawn a privileged container, mount the host’s root file system (/), and chroot into it, bypassing all standard OS security boundaries.

# Hunt for unauthorized members in high-privileged groups
grep -E "^(wheel|sudo|root|docker|admin):" /mnt/analysis/etc/group

4. Metadata and Timeline Correlation

Before analyzing the contents of these files, analysts must evaluate their metadata, specifically the Modification Time (mtime).

ls -lart /mnt/analysis/etc/passwd /mnt/analysis/etc/shadow /mnt/analysis/etc/group

Forensic Pivot: If the incident occurred on February 12th, and the /etc/shadow file’s mtime reflects February 12th at 03:00 AM (while the rest of the /etc/ directory hasn’t been modified in months), it provides definitive proof that an account was created or a password was altered during the intrusion window.

5. DFIR Triage & Automation

To accelerate triage on a mounted forensic image, DFIR teams utilize automated bash scripts to quickly identify structural anomalies across the account configuration files.

Bash (Account Audit Script)

audit_linux_accounts.sh

#!/bin/bash
TARGET_DIR="/mnt/analysis"

echo "[+] Checking for hidden UID 0 accounts..."
awk -F: '($3 == "0" && $1 != "root") {print "ALERT: " $1 " has UID 0"}' $TARGET_DIR/etc/passwd

echo "[+] Checking for service accounts with interactive shells..."
awk -F: '($3 < 1000 && $7 ~ /(bash|sh|zsh)$/ && $1 != "root") {print "WARNING: " $1 " has shell " $7}' $TARGET_DIR/etc/passwd

echo "[+] Checking for passwordless accounts in shadow..."
awk -F: '($2 == "" || $2 == "::") {print "CRITICAL: " $1 " has no password"}' $TARGET_DIR/etc/shadow

echo "[+] Checking for unauthorized users in privileged groups..."
grep -E "^(wheel|sudo|root|docker|admin):" $TARGET_DIR/etc/group

Correlation Next Steps

If a suspicious backdoor account is identified, immediately pivot to theLinux Authentication Logs (auth.log / secure) to determine exactly when the useradd or usermod command was executed and by which compromised administrative account.

---

References & Further Reading

• SANS Institute: Linux Forensic Analysis
• GTFOBins: Docker Privilege Escalation
• Related Artifact: Linux Authentication Logs (auth.log)
• Related Artifact: Linux Shell History (.bash_history)