Monday, January 16, 2012

Automated Triage Utility

A New Utility
      Well, it has been awhile since my last post.  I have been busy finishing up Capstone course work at Davenport University.  For my Capstone project I selected to focus on digital forensics and created a workstation for evidence examination with a Windows 7 host.  On top of that, I elected to create a script that would perform basic triage functions with known commands and utilities.  I developed the script with the AutoIt language based on a recommendation from a friend.  The course allowed me to develop a proof-of-concept application that did quite a bit, but it did it very poorly.  So a few long nights later, I re-did it all and made it work a bit better and do a few more interesting things, discussed later.  After reading Corey Harrell's recent blog post about his new script, I decided I would share my tool as well since it's a small way I can contribute to the community I love.

I've posted the project on Google Code here:  http://code.google.com/p/triage-ir/

The Requirements
     As I mentioned previously, the script I created utilizes other applications to function.  First off, it utilizes your standard 'cmd.exe' from the Windows system (found at C:\Windows\System32).  Eventually, I hope to make it so it doesn't need a copy of the command prompt in the folder but the syntax in the script does not seem to be working properly at this point.So the application folder will look something like this:


You will notice that there is also a tools folder.  This, obviously, will be where I have the tools required for the script stored.  Unfortunately for licensing reasons, I do not include the tools needed.  The tools are free, so you can download them as follows:
This is the structure of the Tool folder as it should be seen, or at least similar:



The Function
     The script is designed to perform basic triage commands, as well as acquire evidence automatically on the system.  I designed the script to be ran from a flash drive, but you can really run it from anywhere.  All reports and evidence will be collected in the script directory under a Incident folder with a time stamp ("mm-dd-yy Incident").  The tool should perform the following functions:
  • Gather Information on
    • System Information
    • Running Processes
    • Services Information
    • NTFS Information
    • Mounted Disks
    • Directory Structure
    • Scheduled Tasks
    • AutoRun 
    • Account Settings
    • Logged in Users
    • IP Configuration
    • Routes
    • Active Connections
    • ARP
    • DNS
    • NETBIOS
    • Network Shares
    • Shared Files
    • Connected Sessions
    • Workgroup PCs
  • Capture Evidence
    • Prefetch
    • Recent Folder
    • Jump Lists (Windows 7)
    • SYSTEM hive
    • SECURITY hive
    • SAM hive
    • SOFTWARE hive
    • Current User NTUSER.DAT
    • All user's NTUSER.DAT
    • Random Access Memory
  • Preserve Data
    • MD5 Hashing
    • SHA1 Hashing
All of this contained in a simplified graphical user interface.  Many of the commands are modular so you can choose what commands and what items you wish to run or capture, with a simple check box.  When you run the script you should get to see something like this:



The Results
     Once you've selected your choice of modules you simply hit run and then you will see a new folder created in the script folder named "mm-dd-yy Incident".  This folder if you run everything you will see something like this:


You'll get a lot of information regarding the PC you run the tool on.  All of it sectional going to its own report.  This was the easiest way for me to setup reporting.  My hope is to someday create a centralized html file for easy access to all of the information in an easily navigated web page.  The evidence folder is where you'll find all of your stored data.  It will look a little like this:


You should find copies (used robocopy to retain metadata settings, I hope) of the Recent Folder, Prefetch Folder, and Jump List folders if you are in Windows 7.  You will also notice it can rip all of your registry hives for quick analysis with your favorite tool.  Considering adding a Reg Ripper module so you can get quicker reports from extracted registry data.  

Future
     Full disclosure, this script is a work in progress at the moment.  I can't promise it will work for everyone.  I'm hoping some of you will be kind enough to test it out and send me your feedback and errors so I can hopefully ensure reliability of it.  Also, if you have ideas that you would like to see implemented within the script just let me know and I will try to implement them properly.  As of right now, I am simply continuing to work on getting the script to run without the copied command prompt and adjusting the tool to a better order of volatility when executing the commands.  Also I need to add some sort of progress monitoring and clean up execution windows a bit.  Any and all suggestions are welcomed!  You may contact me at:  michael.ahrendt@gmail.com

Again, you may download the script here.  You can choose to just use the executable or, if you have AutoIt, you can run from the source code of the same name.

Hope you enjoy.


12 comments:

  1. looks useful, will need to try it out. Will this work on a remote machine across network or VPN or is it local only?

    ReplyDelete
  2. Good question! I designed it to run off a flash drive, I have yet to test it over network connections. I will have to test it out, and let you know. Working on updating modules and a few other things as well, will hopefully have an answer next week with an updated script.

    ReplyDelete
  3. Have you crafted this to minimize the footprint on the disk for later offline forensics? Or was this created only for live capture of data without regard to later imaging of the drive. Not criticizing, just exploring what the primary purpose of the tool is. Looks interesting, I also use AutoIt.

    ReplyDelete
  4. Very good question Mark. I haven't optimized this for minimal effect to disk. I am planning on creating modules that will have set parameters to run, that will not offer a GUI. I am unsure as to the full effects the script will have to a disk, I was designing this with thought for actionable data within a short period. Perhaps with the next update I am planning I will try to do some drive comparisons to see what changes.

    ReplyDelete
  5. Hi,

    i scanned the exe using virustotal and detected by 1 AV as trojan, is this true ?
    https://www.virustotal.com/file/ab39baab40f2b00f738186f0b22c3961acaf580ef29a04c8ff8a2237a964d0fc/analysis/1334472745/

    ReplyDelete
    Replies
    1. Some may detect as malware because of the way the EXE is packed with UPX by the compiler (like a lot of malware). Nothing maliciously coded, you can double check in the source AU3 file.

      Thanks for bringing it up though I believe I can make it more transparent so AV doesn't wrongfully tag it.

      Delete
  6. Hi Mike,

    thanks for putting this together. How would you say your project compares to Rapier / Intel RPIER?

    ReplyDelete
    Replies
    1. Personally, I have never had first hand experience with Rapier so I only know what I see on their webpage. That being said, it seems very similar. They just have a much more developed project, and have more tools implemented at this point. Maybe one day I'll catch up. :) I really like the idea of a server though... we'll see where that goes.

      Delete
  7. Hello,

    For some reason, it did not dump memory using Dumpit,exe, any idea why ?

    Thanks
    Tamer

    ReplyDelete
    Replies
    1. I am unsure as to why. I have experienced this issue at times as well and it seemed to occur when I had a failed execution of the script prior. I've never had it occur with a compiled version, though. I will try and work some error correction into the script so I can at least run a few times if it fails. Thanks for letting me know.

      Delete
  8. Good day Michael,

    You have put together a great tool.
    It is unfortunate that you have not updated the tool since 9 Nov 2012.

    I have forked your work (triage-ir v0.851) on GitHub
    https://github.com/AJMartel/IRTriage

    I have renamed the project to "IRTriage 2" so as not to get confused with your version(s), I have named you "Michael Ahrendt" as Author, but have myself "Alain Martel" as current Forked Maintainer.

    Fixes/Changes:
    -Changed name of project from Triage-IR to IRTriage (Triage-IR is no longer under development)
    -Fixed broken command logging = Now logs all commands that were executed to TAB delimited csv file
    -Updated software = all software packages are updated 16 Feb 2016 (no longer using software from Nov 2012)
    -Using FDpro vs windd (windd is limited to 4GB crash dump, FDpro is a full memory image)
    -Fixed issues with software not running
    *Sleuthkit (icat, ifind) not functioning due to miss-matched dlls (64 vs 32bit) and known dlls (local files no first)
    **Using custom compiled executables compiled with static libraries
    *RegRipper not able to find plugins due to working directory issue
    **RegRipper's working directory is now set to .\Tools\RegRipper\
    -Separation of output from commands (no longer appending to same file from multiple commands, easier to automate parsing)
    -Using csv as output whenever possible (**Future import into database will be easier)
    -Fixed compatability now works with WinXP through to Win10

    I have plans to add retrieval of more artifacts in future editions.

    ReplyDelete
    Replies
    1. I have reached a point were I am happy with the updated version.
      Check it out https://github.com/AJMartel/IRTriage
      Thanks again for letting me fork your project!

      Delete