uac automates live-response artifact collection across Linux, macOS, ESXi, AIX and other Unix-like platforms, built for forensic investigators and responders on systems they are authorized to examine.
| Tool | tclahr/uac — Unix-like Artifacts Collector, an extensible live-response and forensic triage tool written in Shell |
| Category | Digital forensics and incident response (DFIR) artifact collection |
| Primary Use | Automated collection of volatile and non-volatile artifacts via profiles such as ir_triage and full during authorized incident response and forensic investigations |
| Safe Use | Intended exclusively for authorized incident response engagements, forensic investigations of systems you own or are contracted to examine, compliance audits, and lab or research environments |
| Telemetry Note | As a defensive collection tool, uac reads rather than exploits; defenders will observe process execution, filesystem reads and archive writes on the examined host, and its output bundles are the forensic evidence itself |
uac, the Unix-like Artifacts Collector from tclahr/uac, positions itself as a live-response utility for the platforms that commercial forensic suites tend to neglect. Where most DFIR tooling gravitates toward Windows, uac covers AIX, ESXi, FreeBSD, Linux, macOS, NetBSD, NetScaler, OpenBSD and Solaris from a single portable Shell codebase. The repository reports roughly 1,456 stars, an Apache-2.0 license, and Shell as the implementation language, which is itself a deliberate architectural choice rather than an accident of history. The README's phrasing — "All UAC needs is shell :)" — captures the design constraint: the tool must run on hypervisors, NAS appliances, network gear running OpenWrt, and IoT devices where no runtime, package manager, or compiler can be assumed.
The zero-dependency requirement shapes everything about how uac behaves in the field. There is no installation step; the operator downloads a release archive, uncompresses it, and executes the binary directly from the terminal. For responders walking into a compromised ESXi host or a locked-down Solaris box, this matters enormously, because the alternative is usually hand-typing collection commands under time pressure. The project backs its portability claim with CI discipline — the README shows a shellcheck workflow badge and an OpenSSF CII Best Practices badge, both signals that the codebase is held to linting and hygiene standards uncommon in ad hoc response scripts.
Internally, uac is organized around two extension points: YAML artifact definitions and YAML collection profiles. An artifact file such as artifacts/bodyfile/bodyfile.yaml or artifacts/memory_dump/avml.yaml describes one collection unit — what to gather and how — while a profile like ir_triage or full bundles many artifacts into a coherent acquisition plan. This separation is the same pattern that made tools like KAPE successful on Windows, transplanted into pure POSIX shell. It also means the community can contribute new artifact definitions without touching core logic, and the README explicitly invites exactly that: "Have you created any artifacts? Please share them with us!"
The most substantively interesting design commitment is the stated adherence to the order of volatility. The README lists it both as a key highlight and a main feature, meaning uac deliberately front-loads the evidence that evaporates first — running process listings, including processes whose binary no longer exists on disk — before touching comparatively durable material like configuration files and logs. That last detail deserves emphasis: capturing processes without an on-disk binary is a classic anti-forensic counter, since deleted malware leaves the /proc entry behind, and a collector that skips it produces an incomplete picture of a Linux intrusion.
Process collection goes beyond enumeration. uac hashes running processes and executable files, giving investigators a correlation substrate for later matching against threat intelligence or malware repositories. It also extracts file and directory status into a bodyfile, the intermediate timeline format that tools such as mactime consume, which means uac output slots directly into standard timeline-analysis workflows rather than inventing a proprietary format. For Linux targets specifically, the tool can acquire volatile memory using different methods and tools, with the avml artifact being one documented path — avml being a well-known physical memory acquisition tool, invoked through the example ./uac -a ./artifacts/memory_dump/avml.yaml -p full /tmp.
The command-line interface is compact and profile-centric. The basic invocation is ./uac -p ir_triage /tmp, which collects all artifacts defined in the ir_triage profile and writes output under the destination path. Exclusion is supported inline — ./uac -p full -a !artifacts/bodyfile/bodyfile.yaml . demonstrates negating a single artifact with a ! prefix — and additional artifact directories can be merged into a run with -a /my_custom_artifacts/*. Profiles themselves are just YAML files, so -p /my_custom_uac_data/my_custom_uac_profile.yaml points the tool at an entirely bespoke collection plan. That is the full documented CLI surface, and it is enough: destination, profile, artifact include/exclude.
Output handling shows the project thinking about operational realities beyond the acquisition itself. Among the main features is support for writing output to various cloud platforms, which addresses the awkward middle step of many engagements — the collector runs on an isolated or compromised host, and getting terabytes of evidence off it without reintroducing USB media is a real logistical problem. The README does not enumerate which platforms are supported, deferring to the project documentation site at tclahr.github.io/uac-docs, so operators evaluating uac for a specific environment should verify their destination is covered before relying on it during an incident.
It is worth being precise about what uac is not. It is a collection tool, not an analysis platform: there is no built-in parsing, scoring, or detection logic in the README's feature list. Its value is in standardizing and accelerating the acquisition phase so that downstream tools — timeline analyzers, hash searchers, memory forensics suites — receive consistent, volatility-ordered input. In an authorized workflow, that means running it early in engagement, on hosts within scope, ideally before remediation actions disturb the evidence. The compliance-check use case the README mentions also fits: many of the same configuration and log artifacts serve audit purposes as well as incident response.
From a defensive-evidence standpoint, everything uac does is observable and benign in nature: it reads files, enumerates processes, computes hashes, and writes archives. There is no persistence mechanism, no network exploitation, and no obfuscation in its documented behavior. An organization that sees uac execution on a host should treat it as an indicator of an authorized response activity — or, if unexplained, as a signal worth investigating, since the tool itself is equally available to anyone with shell access. Its transparency is a feature for chain-of-custody purposes, not a stealth weakness, because forensic soundness favors auditable collection over covert collection.
Project health looks solid for its niche: active releases tracked on GitHub, a shellcheck CI gate, an OpenSSF best-practices badge, a CONTRIBUTING.md guide, a Discord community for live support, and documentation split out to a dedicated site rather than crammed into the README. The documentation split is the right call given how many platforms and artifact types the tool covers; the README functions as a capabilities overview while the docs site presumably carries per-OS detail. The one caveat for adopters is the usual one for shell-based tooling — behavior can vary with the target's shell and userland — but the breadth of officially supported platforms suggests the team tests against that variance rather than assuming a uniform bash environment.
For teams responsible for Unix estates, especially those running mixed fleets of Linux servers, macOS endpoints, and ESXi or NetScaler infrastructure, uac addresses a genuine gap: repeatable, scripted, volatility-respecting triage that requires nothing from the target except a shell. The YAML extension model means an organization can encode its own collection priorities once and reuse them across every incident, which converts improvised responder judgment into a reviewed, versionable procedure. That is the difference between a collection script and an incident-response capability, and it is the strongest argument for uac beyond its impressive platform coverage.
tclahr/uac.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.