LX1.1 UAC — The Primary Linux Triage Tool

The critical advantage: UAC runs from external media. You copy it to a USB drive, mount the USB drive on the compromised system, and run it from there. The tool binary comes from your trusted media, not from the compromised system's filesystem. This matters because if the attacker has replaced system commands (replacing ps with a trojaned version that hides their processes), running the compromised system's ps gives you false results. UAC includes its own copies of essential binaries and can be configured to use them instead of the system's potentially compromised versions.

Deploying UAC

UAC requires no installation. The deployment workflow depends on your access method:

Collection profiles: ir_triage vs full

The profile determines what UAC collects and how long it takes. The choice depends on your urgency and the investigation environment.

ir_triage (3-8 minutes): Captures the most investigatively valuable artifacts: running processes with /proc deep reads, network connections with /proc/net direct reads, authentication logs (auth.log/secure + rotated copies), bash history for all users, cron jobs (user and system), SSH authorized_keys, recently modified files, loaded kernel modules, systemd service list, and volatile filesystem contents (/tmp, /dev/shm listings). Use this when the attacker is active or when you need evidence from multiple systems quickly.

full (15-30 minutes): Everything in ir_triage plus: complete /var/log copy (all log files), full /etc copy (complete configuration), full filesystem bodyfile (metadata for every file — used for timeline generation), extended /proc collection (memory maps, file descriptors for all processes), and package verification data. Use this for comprehensive single-system investigation when time permits.

The recommended approach for active attacker scenarios: Run ir_triage first to secure volatile evidence in 3-8 minutes. Then run full to capture everything else. The ir_triage output gives you enough to begin analysis immediately while the full collection runs in the background.

What UAC collects: the output directory structure

UAC organizes its output into a structured directory hierarchy. Understanding this hierarchy is essential for knowing where to look in the UAC output:

live_response/ — Volatile data captured from the running system. This is the most time-sensitive collection and the first thing UAC captures.

live_response/process/ contains process listings: ps auxf (process tree), detailed process information, and direct reads from /proc/[pid]/ for each running process (cmdline, exe link, maps, fd list, environ, status). This captures every running process with its full command line, executable path, memory maps, open files, and environment variables — even processes that a rootkit might hide from ps.

live_response/network/ contains network state: ss -tlnp (listening TCP), ss -tnp (established connections), cat /proc/net/tcp (raw kernel TCP table), ip addr, ip route, iptables-save, and DNS configuration. This captures every network connection — including connections hidden by a rootkit.

live_response/system/ contains system state: uname -a, uptime, date -u, mount, df -h, lsmod, dmesg.

live_response/user/ contains user sessions: who, w, last -50, lastb -50.

logs/ — Complete contents of /var/log/ — auth.log, syslog, kern.log, audit.log, web server logs, journal files, and all rotated copies.

system/ — System configuration: /etc/ contents, cron jobs, systemd services, sudoers configuration.

user/ — User artifacts: .bash_history, .ssh/authorized_keys, .ssh/known_hosts, .profile, .bashrc from every user's home directory.

bodyfile/ — Filesystem metadata in bodyfile format (name, timestamps, size, owner, permissions for every file). Input for timeline generation with mactime (LX2).

Forensic considerations when running UAC

Running any tool on a compromised system modifies the system. UAC is no exception. When UAC runs, it creates processes (modifying /proc), reads files (potentially updating atime if noatime is not set), writes output files (if writing to local disk), and generates network traffic (if output is written to a network share). These modifications are unavoidable — the alternative is collecting nothing.

The mitigation is documentation. Before running UAC, record the current date and time, the hostname, your identity, and the reason for collection. After running UAC, document that UAC was run, the command used, the start and end times, and the output location. This documentation becomes part of the chain of custody record.

If evidence integrity is critical (legal proceedings, law enforcement involvement), acquire a memory dump with LiME before running UAC. LiME captures the memory state as it existed before any collection tools modified the system. Then run UAC for the remaining artifacts.

Worked artifact — UAC collection log:

Complete this log every time you run UAC. It becomes part of the chain of custody record.

Case: INC-2026-XXXX System: [hostname] IP: [address]

Pre-collection: - System time verified: date -u output: ___ - Investigator: [name] Authorization: [who authorized the collection] - Memory acquired before UAC: ☐ Yes (LiME, hash: ___) ☐ No (reason: ___)

UAC execution: - Profile: ☐ ir_triage ☐ full Command: ./uac -p ___ -o ___ - Start time: ___ End time: ___ Duration: ___ - Source: ☐ USB drive ☐ SCP transfer ☐ Network share - Output location: ___

Post-collection: - Hash verification: sha256sum -c hashes.sha256 → ☐ All OK ☐ Failures (list: ___) - Output size: ___ File count: ___ - Evidence transferred to: ___ Transfer hash verified: ☐ Yes ☐ No

Modifications documented: UAC process execution modified /proc. SCP transfer (if used) created auth.log and wtmp entries at [timestamp].