Linux Triage Collection with UAC and Velociraptor

A full disk image of every suspect server is rarely realistic. Triage collection grabs the artifacts that answer most early questions (who logged in, what is running, what persists, what changed) in minutes, in a consistent format you can parse at scale. On Linux, two tools dominate: UAC for standalone, script-based collection and Velociraptor for fleet-wide, query-driven collection. This guide shows how to use each and when to prefer one over the other.

Why triage first

Triage sits between memory capture and full imaging in the order of volatility. It captures volatile state that a disk image misses (process list, sockets, mounts, logged-in users) and copies the high-value files from disk. It is fast enough to run on dozens of hosts, which matters when you do not yet know the scope of an intrusion.

The trade-off is completeness: you only get what the collection defines. Deleted files, unallocated space and artifacts in unexpected paths are gone unless you image the disk later, as described in acquiring Linux evidence.

UAC: Unix-like Artifacts Collector

UAC (github.com/tclahr/uac) is a collection framework written in shell script. It has no dependencies beyond the tools already present on the target, which is why it runs on everything from current Ubuntu and RHEL to old appliances, and on other Unix-like systems. Artifacts are defined in YAML files, grouped into profiles.

Profiles and what they collect

The live response output includes process listings, network connections, open files, loaded kernel modules, mounts and users. Log collection copies /var/log and /run/log (rsyslog files and the binary journal, persistent or volatile, where present). The bodyfile records file metadata so you can build a timeline later with mactime or Plaso.

Running UAC

UAC must run as root to read everything. The output directory is a positional argument:

tar -xzf uac-<version>.tar.gz
cd uac-<version>
sudo ./uac -p ir_triage /tmp/uac-out

You can also collect individual artifacts or globs with -a instead of a profile:

sudo ./uac -a 'live_response/process/*' /tmp/uac-out

The result is a compressed archive named after the hostname and collection time, plus a log of what UAC executed. Hash the archive as soon as it is written and record the hash in your case notes.

ls /tmp/uac-out
sha256sum /tmp/uac-out/uac-*.tar.gz

Running from USB or remotely

Running UAC from external media keeps the host disk mostly untouched. USB media are often mounted noexec; in that case invoke the script through the shell, and point the output to the same external drive:

sudo sh /media/ir-usb/uac/uac -p ir_triage /media/ir-usb/cases/web-prod-03

For remote hosts, a common pattern is to copy UAC over SSH, run it into a temporary directory, pull the archive back, then remove the tool and output. Every step leaves traces in the target logs (SSH login, sudo entries), so note your own source IP and timestamps to exclude them later.

Remember that UAC trusts the binaries on the host. On a system with a userland rootkit, ps or ss output may be filtered. Cross-check with a memory image where possible (see the LiME and Volatility guide).

Offline mode against a mounted image

UAC can also collect from a mounted dead image with --mount-point. The mount point does not switch off live response: ir_triage or full would run ps, ss and similar commands on your analysis workstation and put that output in the evidence archive. Use offline_ir_triage or offline, which contain only file-based artifacts:

sudo mount -o ro,noload /dev/loop0p2 /mnt/evidence
sudo ./uac -p offline --mount-point /mnt/evidence /cases/2026-017/uac

This gives you the same archive layout for dead and live hosts, so your parsing pipeline does not need to care.

Velociraptor

Velociraptor (docs.velociraptor.app) is an endpoint agent and server driven by VQL, its query language. Collections are packaged as artifacts, and the built-in catalogue has a family of Linux.* artifacts alongside cross-platform Generic.* ones.

Useful Linux artifacts

A starting set for Linux triage:

• Linux.Sys.Pslist and Linux.Sys.Maps for running processes and their memory mappings.
• Linux.Sys.Users and Linux.Sys.LastUserLogin for accounts and login records.
• Linux.Sys.BashHistory for shell history.
• Linux.Sys.Crontab for cron persistence.
• Linux.Ssh.AuthorizedKeys for SSH key persistence.
• Linux.Syslog.SSHLogin for SSH authentication events from syslog files.
• Linux.Proc.Modules and Linux.Mounts for kernel modules and mounted filesystems.
• Linux.Search.FileFinder for glob-based file search and collection.

Artifacts take parameters, so you can, for example, point the file finder at /tmp/** and /dev/shm/** to hunt for dropped binaries.

Offline collector

When there is no Velociraptor deployment, build an offline collector from the server GUI (Server Artifacts, "Build offline collector") or with a local instance. Select artifacts, set parameters and the output format, and Velociraptor generates a standalone binary for Linux. On the target:

chmod +x ./Collector_velociraptor-<version>-linux-amd64
sudo ./Collector_velociraptor-<version>-linux-amd64

It writes a ZIP archive containing each artifact's results as JSON plus any uploaded files. You can import that ZIP into a server for review or process the JSON directly:

{"Pid": 4121, "Ppid": 1, "Name": "kworkerd", "Exe": "/dev/shm/.x/kworkerd", "Username": "deploy"}

(Illustrative example: a process running from /dev/shm under user deploy on web-prod-03 is an immediate lead.)

For ad hoc local use, the standard binary can collect a single artifact directly:

sudo ./velociraptor-linux-amd64 artifacts collect Linux.Sys.Users --output users.zip

Hunts across a fleet

With agents deployed, a hunt runs the same artifact on every matching client, including hosts that come online later while the hunt is active. Typical use: once one compromised host reveals an indicator (a file path, a cron line, an SSH key), hunt for it across all Linux servers with Linux.Search.FileFinder or Linux.Ssh.AuthorizedKeys and triage only the hits. Results are stored per client and can be exported as CSV or JSON.

UAC or Velociraptor?

In practice they complement each other. UAC is the reliable choice for a handful of hosts, exotic Unix systems, or when you cannot introduce an agent. Velociraptor wins when scope is unknown and the fleet is large, because hunts let you ask one question of every host.

What to collect first

Whichever tool you use, prioritise:

1. Memory, if the tool or a separate step allows it (LiME glossary).
2. Process list with full command lines, executable paths and parent PIDs.
3. Network sockets and their owning processes.
4. Logged-in users, wtmp, btmp and authentication logs (/var/log/auth.log on Debian/Ubuntu, /var/log/secure on RHEL family) and the systemd journal.
5. Persistence locations: cron, systemd units and timers, shell startup files, authorized_keys, /etc/ld.so.preload.
6. Shell histories for all users, including root.
7. A bodyfile or equivalent file metadata for timeline analysis.

Record the host's time zone and clock offset with every collection; both tools capture system information, but confirm it is there before relying on it.

To review the logs in a UAC .tar.gz or a Velociraptor .zip without extracting it, Linux Log Parser opens the archive in the browser and builds one timeline from the authentication logs, journal files, audit.log and wtmp it contains.

Key takeaways

• Triage answers early questions fast but never replaces a disk image for deep analysis.
• UAC: sudo ./uac -p ir_triage <outdir> on live hosts, -p offline or -p offline_ir_triage with --mount-point for mounted images.
• Velociraptor: offline collectors for one-off hosts, hunts to sweep a fleet for an indicator.
• Both rely on the host kernel and, for UAC, host binaries; a rootkit can hide data from them.
• Hash every output archive immediately and log your own actions to separate them from attacker activity.