LX1.1 UAC — The Primary Linux Triage Tool

UAC: Unix Artifact Collector — Your First Tool on a Compromised System

Why you need an automated triage tool

When BASTION-NGE01 is compromised and the attacker is still logged in, you do not have time to run 40 individual commands in the correct order while documenting each one. You need a tool that runs those commands for you — collecting volatile data, log files, filesystem metadata, and system configuration in a single automated pass. The triage tool is to Linux IR what KAPE is to Windows IR: it captures the standard evidence set quickly and consistently, so you can begin analysis immediately instead of spending 45 minutes on manual collection.

UAC (Unix Artifact Collector) is the primary triage tool for Linux incident response. It is open-source, maintained on GitHub, runs as a shell script (no installation required — no package manager, no compilation, no dependencies beyond a POSIX-compliant shell), and collects over 200 artifact categories from Linux, macOS, and other Unix-like systems.

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# PREPARATION (on your forensic workstation — do this BEFORE the incident)
# Clone UAC and copy to USB drive / network share
git clone https://github.com/tclahr/uac.git ~/tools/uac
# Copy to USB drive (keep on your IR kit permanently)
cp -r ~/tools/uac /mnt/usb/uac/

# DEPLOYMENT OPTION 1: USB drive (preferred — no network contamination)
# Mount USB on the compromised system, run directly
cd /mnt/usb/uac
sudo ./uac -p ir_triage -o /mnt/usb/output/$(hostname)/
# -p ir_triage : fast profile (3-8 minutes), captures critical evidence
# -o           : output directory (on the USB, NOT on the local disk)
# $(hostname)  : creates a directory named after the system

# DEPLOYMENT OPTION 2: SCP transfer (when no physical access)
scp -r ~/tools/uac investigator@target:/tmp/uac/
# WARNING: SCP creates an entry in auth.log and wtmp — document this
ssh investigator@target "cd /tmp/uac && sudo ./uac -p ir_triage -o /tmp/uac-output/"

# DEPLOYMENT OPTION 3: Stream output to forensic workstation (zero local writes)
ssh investigator@target "cd /tmp/uac && sudo ./uac -p ir_triage -o /dev/stdout" | \
  tar xzf - -C ~/cases/INC-2026-0402/BASTION-NGE01/
# Pipes UAC output directly to your workstation — nothing written to target disk

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Two-pass collection for active attacker scenarios

# Pass 1: Triage — capture volatile evidence immediately (3-8 minutes)
sudo ./uac -p ir_triage -o /mnt/usb/output/bastion-nge01-triage/
# While this runs, you can monitor with: ls -la /mnt/usb/output/bastion-nge01-triage/

# Pass 2: Full — capture everything else (15-30 minutes)
sudo ./uac -p full -o /mnt/usb/output/bastion-nge01-full/
# This runs while you begin analyzing the triage output

# Verify output integrity
cd /mnt/usb/output/bastion-nge01-triage/
sha256sum -c hashes.sha256
# Every line should show "OK" — any failure indicates modification after collection

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].

Decision points: choosing the right UAC deployment method

Physical access available (data center, on-site): USB deployment is preferred. No network traffic, no authentication events, no SCP modifications. The cleanest deployment method.

SSH access only (remote server, cloud VM): SCP the UAC directory to the target. Accept the authentication log modification. Consider piping output directly to your workstation to avoid writing to the target’s disk.

Multiple systems compromised: Deploy UAC via SSH to all systems in parallel using a tool like pssh or a simple loop: for host in host1 host2 host3; do ssh $host "cd /tmp/uac && sudo ./uac -p ir_triage -o /tmp/uac-out/" & done. This captures triage evidence from all systems before returning for full collection on priority systems.

Container environment: UAC can run inside a container via kubectl exec or docker exec, but some modules may fail (e.g., those requiring kernel module enumeration). Use the ir_triage profile which avoids the most container-incompatible modules.

Troubleshooting: common UAC deployment issues

UAC fails with “Permission denied.” UAC must run as root to collect all artifacts. Use sudo ./uac. If sudo is not available and you cannot escalate, UAC will collect what it can with current permissions — but will miss root-owned logs, /proc deep reads for other users’ processes, and system configuration files.

UAC fails on Alpine Linux. Some UAC modules depend on GNU coreutils features not available in BusyBox. Use the ir_triage profile which uses the most portable commands. If specific modules fail, the errors are logged in UAC’s collection log — the remaining artifacts are still collected successfully.

Output directory runs out of space. A full UAC collection on a server with large log files can produce 500MB-2GB of output. Ensure the output destination (USB drive, /tmp, network share) has sufficient space before starting. Check with df -h /mnt/usb/ before running UAC.

Hash verification shows failures after transfer. The evidence file was corrupted during transfer (network error, incomplete SCP). Re-transfer the specific failed files from the UAC output directory on the target system. If the target system has been modified since collection, the re-transferred files will have different hashes — document this discrepancy.

UAC hangs during the bodyfile generation phase. Large filesystems (millions of files) can cause the bodyfile generation to take 30+ minutes. If you need results quickly, cancel UAC and restart with ir_triage (which skips the bodyfile). Run the full bodyfile generation later as a separate pass.

Beyond this investigation

UAC is the starting point of every Linux investigation in this course. In LX4 (SSH Brute Force), you will analyze the authentication logs from UAC’s logs/ directory. In LX5 (Web Application Compromise), you will analyze the web server logs. In LX7 (Persistence), you will examine the cron jobs, systemd services, and authorized_keys files from system/ and user/. In LX2 (Filesystem Forensics), you will use the bodyfile for timeline generation. The tool collects the evidence. The subsequent modules teach you to analyze it.