Announcing Google Groups Forensic Utilities Artifacts Forum

 I know this is going to be a SHOCKER to many... But here goes:

AChoir isn't the only Live Response/Triage/Live Acquisition tool.I'll wait for you to get a glass of water and sit down.There are many excellent Live Response tools/scripts, and many of them actually use the same Free and Open Source utilities to gather forensic artifacts. These are well known utility programs from SysInternals, Nirsoft, and others.

 

Asking - What else do these utilities do?

When using software to gathering digital artifacts (especially in cases where the examiner knows that there are likely to be questions), there are a number of things examiners worry about. Among them are:

• Does this program change anything on the subject drive or in then endpoint's memory?
• If it does, what exactly is added, changed, or deleted?
• How does that affect the system?
• Do these changes constitute contamination? Do they modify the artifacts or the system itself in any way?
• Can I prove that these changes don't contaminate the artifacts? How do I prove it?

The only real way to know the answer these questions is by testing the software and documenting all changes that it makes to the system. This can be a long and complex process. As it stands today, I am not aware of any central place where these tests are documented.

Just like my original reason for writing AChoir: To provide a free and open Live Acquisition scripting tool/framework, so examiners didn't have to keep re-inventing the wheel. So too, I think a common place to document each forensic tool, and what artifacts they create - will help the entire DFIR community.

What does this look like?

I think there are some standard things we should ask about each utility program:

• What is the program name?
• Where does the program come from?
• What is the Version?
• What is the Hash Value?
• What artifacts does it create? Where are they created: Memory, Registry, Files?
• What, if anything, does the program change?
• How does that impact non-repudiation?

Instead of writing a whole databasey thing to track those answers (and others). I think the best way to start is using the good old, tried and true, Discussion Forum. I have chosen Google Groups to do that. It may be that in the future a more formal system could be set up. but for now, I think it makes sense to use something simple to start testing, and sharing what we know.

Caveat Emptor: THERE IS NO SUBSTITUTE for doing your own testing.

Not necessarily because you can't trust another person's tests - but because when YOU do the tests, YOU understand the process, and can explain it when YOU are asked.

Having said that, a forum where the DFIR community can collaborate, verify, and correct forensic utility program testing will make everyone's job easier, and more accurate.

I have already seeded the forum with my favorite utilities. It can be found at: https://groups.google.com/forum/#!forum/forensic-utilities-artifacts

If you have already tested these, or other forensic utilities, please consider sharing your results and participating in the forum.


Thanks... And...
Happy Hunting!

---

Disclaimer:

The views and opinions expressed here and throughout this web site are my own. They do not reflect the views or opinions of my employer, their clients, customers, or partners. I do not speak for them and they do not speak for me. The opinions and views expressed here represent my opinions at the time of writing, and can change without notice or warning.

---

AChoir - Version 1.0 Released

Yes, I've finally decided, after 2 years of development to Release AChoir version 1.0. Besides the fact that it was already at v0.98a (and I had just about run out of decimals), it somehow feels ready to call baked. Besides the obligatory bug fixes and cosmetic changes, Version 1.0 has some very cool new features:

Setting Case Information (CSE:)

Since AChoir is typically used in an Incident Response/Acquisition/Triage situation, it may help examiners to assign Case Information to the AChoir Acquisition.

To do that I have added the CSE: Action. The CSE: Action is completely optional - If you never use it, AChoir won't care. But for those examiners used to using Case and Evidence Numbers, AChoir now has that capability. The CSE: Action will either Query for (CSE:Get) or Display Case (CSE:Say) Information, including:

• Case Number: 
• Case Description: 
• Evidence Number: 
• Examiner:
  

To ensure non-repudiation, AChoir will only let an examiner enter this information one time. And once the Examiner displays the Case information (CSE:Say) it cannot be changed. This is to prevent any confusion about Case and Evidence Numbers.

AChoir can also be told to Query for the Case information at startup by using the /CSE command line option.

Checking the Volume Format (VCK:)

I like this feature a lot. The VCK: action set the &VCK variable with the Partition Format of the queried Volume. So For instance VCK:C:\ will set the &VCK variable to NTFS, FAT32, CDFS, Other, or None (depending on the format of that Volume). This is especially useful if you have a utility that only works on FAT32, NTFS or another Volume format.

To do this, use VCK: to find out what the Volume Partition Type is, and then use the (also new in v1.0) EQU: or NEQ: functions to conditionally execute code. For example, the AChoir code below will Query the Volume that Windows is on and set &VCQ. The EQU: Action then checks if &VCQ is equal to "NTFS" and if it is, will run the AChoir Code until an END: Statement is found

VCK:&Win
EQU:&VCK NTFS
SAY: o NTFS Volume Detected....
NCP:"&Win\prefetch\*" "&Acq"
END:

 

Comparing Strings (EQU: and NEQ:)

As mentioned in the previous section, AChoir v1.0 now has string comparisons. Strings can be Equal (EQU:) or Not Equal (NEQ:). Using this Action is simple. After the EQU: or NEQ: statement simply put two strings to compare. Strings can be either a variable or a Static String. If the condition is met, the AChoir code following the statement is executed until an END: statement is found.

The two Strings are separated by a Space. If you want one or both of the strings to have spaces in them simply use Quotes, like "This is a String".

Looping Through Attached Disks (DSK:)

This functionality request came to me from an AChoir user. At first I provided some code using WMIC to accomplish the request, which was simply to loop through the attached drives on an endpoint. But the more I thought about it, the more it seemed like this should be a core feature. So now it is.

The DSK: Action is a looping object that sets the &DSK variable to all mounted/attached disk that match the requested type. Requested Types can be: Removable, Fixed, Remote, or CDROM.

For instance, to set the &DSK looping variable to all Fixed Disks use the Action - DSK:Fixed. To set the &DSK looping variable to all mapped drives, use the Action - DSK:Remote.

AChoir now supports indented statements

No programming language is complete without indentation. 'Nuff Said.

In Conclusion

I started this project 2 years ago with some pretty simple goals. But AChoir has grown and matured into a full featured Live Response/Triage/Acquisition Scripting Language and Shell. It is my hope that AChoir will be a useful tool in your forensic examination toolbox for scripting both Live Response and DeadBox analysis.

Happy Hunting!

---

Disclaimer:

The views and opinions expressed here and throughout this web site are my own. They do not reflect the views or opinions of my employer, their clients, customers, or partners. I do not speak for them and they do not speak for me. The opinions and views expressed here represent my opinions at the time of writing, and can change without notice or warning.

---

AChoir - Copying based on File Signatures

For as long as I can remember, files had both File Names and File Types. Back when I was an IBM/370 VM/CMS Systems Programmer, files were identified by a FileName, FileType, and FileMode.

When I moved over from IBM mainframes to working on PCs and LANs it was a pretty easy transition to Drive Letter, FileName and File Extension (8.3 format). FileMode was now Drive Letter, FileName remained the same, and FileType became File Extension (even though they had to be smaller).

But the truth is: It's simply a logical/convenient naming convention, which is neither enforced nor even necessary to open and use files. For example: A Microsoft Word document can have a .Doc or .Docx extension, or not. The extension is really just a way for Windows to know what files are associated with what programs (i.e. if you double-click on a .Doc file, Windows will try to open the file with MS-Word). To reinforce this nomenclature Windows will give that file a visual queue in the form of an Icon, making it appear as though the file definitely contains that type of content.

It's actually just a convenience. You can name a file's extension almost anything, or nothing at all.
Since it has become a de-facto standard on Windows, many users take this for granted, as established fact: That file extensions are somehow a trusted cue of the actual content of the that file.

As in all thing computer - Bad Guys take advantage of this ambiguity. They simply rename the files that they want to hide with an extension that is counter to the actual content of the file.

Incidentally, ambiguities exist in all sorts of ways on Operating Systems, and they are a consistent source of exploits and attacks
 
We all know this - But bear with me. I am going somewhere with this...

Forensics examiners, and their tools assume that a bad guy will do this. So forensicators go beyond just looking at a file's extension. They do this by looking inside the file to determine it's actual content. They look for additional identifying information inside the file called the "File Signature" (sometimes called "Magic Numbers"). Many files have these identifying signatures. They are typically at the very beginning (Header) and sometimes at the very end (Footer or Trailer) of files.

This fact has been used for years to "carve" deleted files from unallocated disk space: Find the Header (and Footer if applicable) signature, and everything in between is the file. Programs like PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec) and Scalpel (https://github.com/sleuthkit/scalpel) have extensive file header and footer definitions to accomplish this. If you are interested in just how many of these signatures exist, a good place to start is one of the online File Signatures databases like - https://www.filesignatures.net

What isn't common - And here is my point: Is an Open Source file copying program that copies files based on these file signatures.

I know... Right?! 

There are times, when I am triaging a compromised machine, that I need to wade through the mountain of files (for instance within a user profile directory), to find specific file types. These files often DO NOT have expected file extensions. They may be temp files, or they may have been specifically misnamed by the bad guy to prevent detection. Having a programmatic way to identify and extract/copy files based on their file signatures was something that I really wanted AChoir to have.

Now granted - like many seemingly simple ideas, it's not a simple problem to solve. Files of a certain type (e.g. Executables) can have many different legitimate file extensions (i.e. exe, dll, com), and multiple file signatures. To search and copy each different one would be time consuming and frankly inefficient. A better way to solve the problem is to load all the signatures into a table, and copy any files that match any of the extensions or signatures.

This is what I implemented in AChoir. Below is an example of how I implemented it:

*** Clear the Signature Table *** Sig:Clear

*** Load Multiple file extensions and signatures into a Signature Table *** Sig:COM=4d5a Sig:DLL=4d5a Sig:DRV=4d5a Sig:EXE=4d5a Sig:PIF=4d5a Sig:QTS=4d5a Sig:QTX=4d5a Sig:SYS=4d5a Sig:COM=e8 Sig:SYS=e8 Sig:COM=e9 Sig:SYS=e9 Sig:COM=eb Sig:SYS=eb

*** Then Raw NTFS copy all files in C:\Users that match the Signature Table *** NCS:"C:\Users\*" "&Acq"

To be honest, there are better commercial forensics tools that can do this. And if you can afford them, I highly recommend using them. Having a commercial entity maintain something like this (signature tables) is going to be much better than what I can do with my limited resources. Having said that, the AChoir copy by file signature functionality is there, and it works. And I am not aware of any other Open Source Triage scripting tool that has implemented this functionality (please let me know if I have missed any that do, and I will be glad to correct this post).

When used with AChoir's Raw Disk access capability, it's a pretty powerful live triage capability.
Included in the AChoir installation are several scripts that use this capability. To create those scripts, I used the amazing list of GPL'd file signatures maintained by Gary Kessler at:

 http://www.garykessler.net/software/index.html#filesigs
 
I want to thank him publicly for providing this great information. If you find any errors or omissions in these scripts, please let me know and I will correct them. 

AChoir is a labor of love for me - and I hope other Incident Response practitioners find it useful. In the next release of AChoir I will also expand this funtionality to non-NTFS partition/files, and I will continue to add novel functionality like this as AChoir continues to mature.

---

Disclaimer:

The views and opinions expressed here and throughout this web site are my own. They do not reflect the views or opinions of my employer, their clients, customers, or partners. I do not speak for them and they do not speak for me. The opinions and views expressed here represent my opinions at the time of writing, and can change without notice or warning.

---