Artifact Analysis: Linux Authentication Logs (auth.log & secure)

Note

Executive Summary: While binary logs like wtmp provide a basic registry of user logins and logouts, the text-based auth.log (Debian/Ubuntu) and secure (RHEL/CentOS) files act as high-definition security cameras for the operating system. They record the technical minutiae of every authentication attempt, the specific mechanisms utilized (passwords vs. public keys), privilege escalations (sudo, su), and account lifecycle events. For DFIR analysts, mastering these logs is critical for reconstructing initial access and lateral movement.

1. Artifact Location and Log Rotation

Authentication logs are stored as plain text, allowing analysts to parse them using standard Unix utilities (grep, awk, sed) directly from a mounted forensic image (e.g., /mnt/analysis/).

• Debian / Ubuntu / Kali Systems: /var/log/auth.log
• RHEL / CentOS / Fedora Systems: /var/log/secure

Overcoming Log Rotation

Linux distributions utilize logrotate to archive older logs and prevent disk exhaustion. When investigating an incident, analysts must never restrict their scope to the current active file.

Active Logs

auth.log or secure - Contains the most recent authentication events in plain text.

Archived Logs

auth.log.1 (recently rotated plain text), auth.log.2.gz (older, compressed). Analysts must utilize zgrep or zcat to search across compressed archives without altering the evidence by extracting them.

2. Analyzing SSH Connections (The Primary Vector)

Secure Shell (SSH) remains the primary initial access and lateral movement vector for threat actors targeting Linux infrastructure. Pattern matching within these logs reveals the attacker’s methodology.

A. Successful Authentications

Identifying how an attacker authenticated provides immediate insight into the compromise severity.

• Password Authentication:

  ssh_password_success.sh

  grep "Accepted password" /mnt/analysis/var/log/auth.log

  Forensic Value: Indicates the threat actor possessed or successfully brute-forced a valid credential.
• Public Key Authentication:

  ssh_pubkey_success.sh

  grep "Accepted publickey" /mnt/analysis/var/log/auth.log

  Forensic Value: Indicates the attacker possesses the corresponding private key. The log entry often reveals the key’s fingerprint, allowing analysts to tie the authentication back to a specific entry in the user’s ~/.ssh/authorized_keys file.

B. Authentication Failures (Brute Force & Spraying)

• Incorrect Passwords: grep "Failed password" reveals standard brute-force attempts.
• Unknown Users: grep "Invalid user" indicates automated scanning. A high volume of these logs targeting common administrative accounts (e.g., admin, root, oracle) strongly suggests non-targeted mass exploitation attempts.

3. Privilege Escalation and Sudo Execution

Tracking what a compromised standard user accomplished with administrative rights is a behavioral goldmine. Unless explicitly disabled in the configuration, the sudo utility logs the exact command executed.

sudo_execution_tracking.sh

grep "COMMAND=" /mnt/analysis/var/log/auth.log

Dissecting a Sudo Log Entry

A standard sudo log entry follows a strict format: Feb 6 10:00:00 server sudo: nico : TTY=pts/0 ; PWD=/home/nico ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow

• Who: nico (The compromised account)
• Where: PWD=/home/nico (Working directory at execution time)
• Target Context: USER=root (Privileges assumed)
• Action: COMMAND=/usr/bin/cat /etc/shadow (The executed binary and arguments)

Attack Indicators via Sudo

Analysts should actively hunt for:

1. Interactive Root Shells: Commands like sudo su - or sudo -i. Once an attacker spawns an interactive root shell, individual commands are no longer logged in auth.log. The investigation must immediately pivot to the Linux Shell History (.bash_history) of the root user.
2. GTFOBins Evasion: Execution of binaries that allow shell escapes, such as sudo awk, sudo find, or sudo nmap.
3. File Modification: Execution of sudo edit or sudo vi targeting critical system files.

4. Persistence and Account Manipulation

Threat actors frequently establish persistence by creating backdoor accounts or modifying group memberships. The authentication log meticulously tracks these modifications.

• Account Creation: grep "new user" helps identify backdoor accounts disguised as system services (e.g., sysadmin, backup_svc).
• Password Manipulation: grep "password changed" tracks unauthorized credential resets.
• Privilege Granting: grep "add group" reveals if an attacker added a compromised standard account to highly privileged groups like sudo, wheel, or root.

5. DFIR Triage and Correlation Strategy

To maximize the efficiency of log analysis during an incident, DFIR teams employ specific correlation strategies.

1. Identify Top Talkers: Quickly extract the top 10 IP addresses conducting brute-force attacks to feed firewall blocklists.

   extract_top_attackers.sh

   cat /mnt/analysis/var/log/auth.log | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head

2. Trace Lateral Movement: Filter successful SSH connections for internal IP addresses (e.g., 192.168.x.x or 10.x.x.x). A successful login from another internal server maps the attacker’s lateral movement path.
3. Detect Log Wiping (Anti-Forensics): Threat actors often attempt to cover their tracks by clearing logs. If the logging daemon (rsyslog or systemd-journald) exhibits suspicious restarts during the incident window, or if there are inexplicable chronological gaps in the text file, it is a high-fidelity indicator of log tampering.

---

References & Further Reading

• SANS Institute: Advanced Incident Response and Threat Hunting
• GTFOBins: Privilege Escalation via Sudo
• Related Artifact: Linux Shell History (.bash_history) Analysis