Auto4n6 is a set of AChoirX Scripts coupled with several other Open Source forensics programs that automate the parsing and reporting of both Memory dumps and Forensic Triage collections.
Auto4n6 currently requires quite a bit of customised configuration to identify how a triage collection should be parsed. This is necessary to get a working version of the tool into a working Proof of Concept. Right now "it works on my machine". Future versions will focus on better ways to determine how to parse and process collection data with far less configuration, to make it flexible enough to work with more data sources and require less modification. I'm just getting started!
Automation of forensic collection and processing has always been my goal. It started with AChoir and AChoirX , which are designed to make forensic collection (live response or dead-box) consistent and reliable. I designed AChoir and AChoirX in such a way that it could also be used to post process triage collections to allow a consistent analysis experience. Allowing analysts to spend more time analyzing and less time messing with various forensic tools and options. It has been, from the very begining that, AChoir and AChoirX could be used for live response, dead-box) collection, and artifact post processing. And with AChoirX that capabilty extends to Windows, OSX, and Linux.
After creating AChoir(X) My next step was to create an automated forensic reporting tool. A tool that could read a triage collection and organise the most common artifacts into a single HTML report file for simple navigation and analysis. That was realized with AChReport.
But AChReport was written to report on AChoir(X) collections. As I ran into triage collection from other tools, I decided to change AChReport to TriageReport and allow it to report on nearly any type of triage collection.
As I began to use AChoirX to create additional forensic tools such as an automated Memory analysis tool tying volatility to LOKI, or an automated Timeliner tool that runs Plaso against a triage collection, I began to see that a completely automated and flexible forensic pipeline was possible.
This has brought me to this project: Auto4n6.
Auto4n6 uses AChoirX and several other FOSS forensic tools (Including TriageReport) to create an automated pipeline that processes both memory images and triage collections. A memory dump or triage collection is simply copied into a directory and Auto4n6 takes over, parsing and analyzing the data to create a comprehsive analysis and reporting pipeline.
Auto4n6 is currently in an Alpha (v0.03) state so it takes quite a bit of configuration to make it work. That will change as I improve the software. Essentially AChoirX runs several FOSS Forensic utilities and organizes them into a consistent set of outputs for the forensic analyst. Below I will outline the tools it uses and how to configure them so that an anlyst can customize it to their own needs and preferences.
Auto4n6 currently consists of four (4) AChoirX scripts
- The main driver script
- The memory dump processing script
- The triage collection processing script
- The Plaso timelining script
First it is important to note that AChoirX can function in "Blocked" or "UnBlocked" mode. In Blocked mode a program waits until it's previous sub-processes complete to run the next process. In UnBlocked mode a program can run multiple sub-process simultaneously. Auto4n6 works in UnBlocked mode, meaning that multiple triage and memory parsing process can run at the same time. This makes processing MUCH faster but introduces some complication. All you really need to know is that Auto4n6 can run parse multiple memory dumps and triage collections at the same time. That means that monitoring the console can be confusing as you see multiple processes executing at the same time. Auto4n6 does not have any issues with this, but it can be confusing to watch the console as it displays messages across multiple simultaneous parsing routines.
By default Auto4n6 logs to the console, to a unique individual log file (per processing routine) and to a local Syslog (127.0.0.1). If you have an external Syslog, you can change the syslog parameters to point to your centralized syslog. If you prefer not to syslog the console message, this can be commented out.
By default, Auto4n6 waits for Memory Dumps to appear in C:\Auto-Mem. This can be changed in the script to point to a different directory of your choosing.
By default, Auto4n6 waits for Triage collections to appear in C:\Auto-Col. This can be changed in the script to point to a different directory of your choosing.
Auto4n6 separates each processing run in a unique directory to ensure that one processing run doesn't step on another. Since Auto4n6 is designed to be able to process at scale, multiple processing runs can be running simultaneously. The need to understand which processing run is associated with which memory/triage collection becomes an important requirement.
To address this Auto4n6 keeps two(2) running files:
- Auto4n6.csv - Shows which processing run is associated with which memory/triage collection input in CSV format
- Auto4n6.HTML - Shows which processing run is associated with which memory/triage collection input in an HTML file
Using these files, an analyst can determine which input file is associate with which output directory. To make this clearer, I recommend that memory dumps and Triage Collections be named uniquely to help in quicker matching of where the output is located.
Once Auto4n6 detects a file in the Memory Dump directory (queue), it will create a new Auto4n6 directory and copy the memory dump to the new directory. This directory can be seen in the Main Driver script, and the default is C:\Auto-Mem. Auto4n6 will remember the memory dump file it has processed and will only process it once. The list of processed memory dump files can be found in the MemDone.dat file.
The memory dump processing script will then run several volatility commands against the memory dump to extract things like network connections and processes. Once the extraction is complete, Auto4n6 will run LOKI against all of the extracted data.
For volatility to work properly Python 3 must be installed on the system. Auto4n6 expects volatility to be installed in C:\Auto4n6\Volatility3 and for LOKI to be installed in C:\Auto4n6\Loki - These locations can be changed in the MemProcess.ACQ Script, but I recommend keeping the default locations.
Please note that both volatility and LOKI are highly configurable. You can add, change or delete their parameters in the MemProcess.ACQ script as well as configure their own unique settings (i.e. add additional YARA rules to LOKI) to fully customize your Auto4n6 parsing and analysis environment.
The Triage Collection Processing script does several things:
- Copy the Triage Collection from the queue (the default is C:\Auto-Col) to a uniquely named acquisition sub-directory
- Unzip the Triage Collection into a sub-directory called Triage
- Run TriageReport against the Triage Collection
- The Triage Report will be written to a sub-directory called TriageReport
- Run Plaso (Log2Timeline) against the Triage Collection to create a Super Timeline
Auto4n6 will remember each triage collection file it has processed and will only process it once. The list of processed triage collection files can be found in the ColDone.dat file.
Since Triage collections can be organized in many different ways, the first thing that you will need to determine is how to unzip the collection. The ColProcess.ACQ script can be modified to Unzip the collection into the directories that will then be parsed and processed. The default scripts were designed, and function with the Blue Team Village BTV5 (DEF CON 30) triage collections from Project Obsidian. These can be found on the BTV Media Server.
Once Auto4n6 is setup, these Triage Collections can be used to test it. They should work without any further modifications.
When setting up Auto4n6 for your own individual collections, you will need to edit the
TriageReport
Confiquration file to point to all the unzipped artifacts in the collection. When testing this with the
BTV Triage Collections no modifications should be necessary.
The Default Configuration File will be in &Dir\TriageReport\AChReport.cfg but that can be changed in the ColProcess.ACQ Script.
For TriageReport to work properly the following setup is necessary:
- Python 3 must be installed on the system.
- TriageReport must be installed in the \TriageReport sub-directory under the Auto4n6 Root Directory.
- Microsoft Log Parser must be installed in the Auto4n6 Root Directory.
- Chainsaw must be installed in the \Chainsaw sub-directory under the Auto4n6 Root Directory.
- RegRipper 3 must be installed in the \RRV\RegRipper3.0-master sub-directory under the Auto4n6 Root Directory.
- LECmd and SBECmd must be installed in the \Sys sub-directory under the Auto4n6 Root Directory.
- WinPrefetchView must be installed in the \Sys sub-directory under the Auto4n6 Root Directory.
- Standalone 7-Zip must be installed in the \Utils\7z sub-directory under the Auto4n6 Root Directory.
- MFTDump must be installed in the \DSK sub-directory under the Auto4n6 Root Directory.
Step 5: The Plaso Timeliner Processing Script
After running TriageReport Auto4n6 will call the PlasoX.ACQ script, this script runs Plaso Log2Timeline.exe against the Triage Collection.
When Log2Timeline is complete, Auto4n6 will then run psort.exe to convert the timeline to CSV format.
Auto4n6 expects Plaso to be installed in the \Plaso sub-directory under the Auto4n6 Root Directory.
At this time, Auto4n6 will not do any additional processing of the timeline. It is up to the analyst to decide how to use the timeline for their analysis.
Auto4n6 will happily run indefinately. To signal Auto4n6 to stop, simply create a file called Shut.Down in the Auto4n6 root folder. This will signal Auto4n6 to exit the main script. IMPORTANT NOTE: Delete the Shut.Down file before restarting Auto4n6 to make sure it runs without exiting.