- Apr 25, 2015
- 1,845
- 2
- 2,199
- 327
Whenever I say "random forensics" or "random digital forensics", people ask me what the **** exactly I am talking about. Ever see a crime scene on a TV show and without anything scientific - you want to scream "I know what they did here!?"
Yeah, that is random forensics in my opinion. You have a guess and for whatever reason think collecting that extra random piece of string on the ground - that will be your case closer evidence so you focus on that a little extra.
Forensics on computers is not far different than this really, I mean a lot of the logs being collected have some security implication already but they are gathered oftentimes with plentiful noise. The nature of logging on systems is that they can log a little or log a lot - you choose. If you have a lot of logs, then it is like you picked up more evidence from a crime scene to inspect. When you have little logs, you can say "Oh, this here," opposed to "Oh, first he went over here then there while executing commands XYZ and running software ransomware.exe"
Sometimes there are pieces of evidence you grab that are simply not automated in their handling. For example, a lot of times if you know a very specific VM (Virtual Machine) was attacked, you may be inclined to find whatever is inside the memory (RAM). Specifically, I would snapshot the affected virtual machines with memory. This should generate a .vmem file which we can perform "Volatile Memory Analysis" on using a memory analysis tool titled Volatility. For a simple first look at Volatility, consider breezing through a beautiful Volatility article by P4N4Rd1 (formerly zemelusa).
Keep in mind that while performing any form of incident response on information systems, you will want to follow basic concepts like tracking users, any suspicious activity, and especially monitoring for malware persistence - for a quick introduction into these artifacts please consider reading about them more here. A good takeaway from their early article is "Because it is not automated, it is up to you to know which tools to run and what to look for," as with manual tools there is more work involving knowing when to use the tool AND how to use the tool.
I will now be jumping into the deep part of the swimmy pool. Put your lifejackets on! The below content is sourced from a cool book - strictly for educational purposes:
Alternate Data Streams or ADS - these were added to Windows NT 3.1+ for adding "extra" information to files without altering original format/content. This extra info (metadata) is arranged in the form of streams that are attached to main data stream (stream visible to normal user).
Amcache - may provide timeline of which program was executed, when first run, and last modified. These artifacts provide program information regarding file path, size, and hash depending on the OS version. Amcache.hve file is a registry file storing the information of executed applications. These executed applications include the execution path, first executed time, deleted time, and first installation. In Win 8, Amcache.hve replaced RecentFileCache.bcf and uses Windows NT Registry File (REGF) format. Common location for Amcache.hve is %SystemRoot%\AppCompat\Programs\Amcache.hve - important artifact for recording traces of anti-forensics programs, portable programs, and external storage devices, and can be analyzed using the amcache plugin of RegRipper.
AppCompatCache is also known as Shimcache. A component of Application Compatibility Database - created by Microsoft for use by Windows OS to identify app compatibility problems. Helps developers troubleshoot legacy functions and contains data related to Windows features. Used for search to decide if modules need shimming for compatibility or not. A "Shim" is a small library, it transparently handles the applications interworking to provide support for older APIs in a newer environment or vice-versa. Shims allow backwards and forwards compatibility for apps on different software platforms.
if the application was... launched by the user. It does not record the number of times, the parent process or user identification information.
Attributes - For each file (or directory) described in MFT record, there's linear repository of stream descriptors (also named attributes), packed together in one or more MFT records (containing the so-called attributes list), with extra padding to fill the fixed 1 KB size of every MFT record, and that fully describes the effective streams associated with that file.
Each attribute has an attribute type (a fixed-size integer mapping to an attribute definition in file $AttrDef), an optional attribute name (for example, used as the name for an alternate data stream), and a value, represented in a sequence of bytes.
For NTFS, the standard data of files, the alternate data streams, or the index data for directories are stored as attributes.
Autoruns - shows you what programs are configured to run during system bootup or login, and when you start various built-in Windows applications like Internet Explorer, Explorer and media players. These programs and drivers include ones in your startup folder, Run, RunOnce, and other Registry keys. Autoruns reports Explorer shell extensions, toolbars, browser helper objects, Winlogon notifications, auto-start services, and much more.
Autorunsc - is the command-line version of Autoruns. Its usage syntax is:
This concludes of the A list, I will be grouping different pieces together for example A, B-C, D-E, F, H-K, etc.
Yeah, that is random forensics in my opinion. You have a guess and for whatever reason think collecting that extra random piece of string on the ground - that will be your case closer evidence so you focus on that a little extra.
Forensics on computers is not far different than this really, I mean a lot of the logs being collected have some security implication already but they are gathered oftentimes with plentiful noise. The nature of logging on systems is that they can log a little or log a lot - you choose. If you have a lot of logs, then it is like you picked up more evidence from a crime scene to inspect. When you have little logs, you can say "Oh, this here," opposed to "Oh, first he went over here then there while executing commands XYZ and running software ransomware.exe"
Sometimes there are pieces of evidence you grab that are simply not automated in their handling. For example, a lot of times if you know a very specific VM (Virtual Machine) was attacked, you may be inclined to find whatever is inside the memory (RAM). Specifically, I would snapshot the affected virtual machines with memory. This should generate a .vmem file which we can perform "Volatile Memory Analysis" on using a memory analysis tool titled Volatility. For a simple first look at Volatility, consider breezing through a beautiful Volatility article by P4N4Rd1 (formerly zemelusa).
Keep in mind that while performing any form of incident response on information systems, you will want to follow basic concepts like tracking users, any suspicious activity, and especially monitoring for malware persistence - for a quick introduction into these artifacts please consider reading about them more here. A good takeaway from their early article is "Because it is not automated, it is up to you to know which tools to run and what to look for," as with manual tools there is more work involving knowing when to use the tool AND how to use the tool.
I will now be jumping into the deep part of the swimmy pool. Put your lifejackets on! The below content is sourced from a cool book - strictly for educational purposes:
Alternate Data Streams or ADS - these were added to Windows NT 3.1+ for adding "extra" information to files without altering original format/content. This extra info (metadata) is arranged in the form of streams that are attached to main data stream (stream visible to normal user).
Amcache - may provide timeline of which program was executed, when first run, and last modified. These artifacts provide program information regarding file path, size, and hash depending on the OS version. Amcache.hve file is a registry file storing the information of executed applications. These executed applications include the execution path, first executed time, deleted time, and first installation. In Win 8, Amcache.hve replaced RecentFileCache.bcf and uses Windows NT Registry File (REGF) format. Common location for Amcache.hve is %SystemRoot%\AppCompat\Programs\Amcache.hve - important artifact for recording traces of anti-forensics programs, portable programs, and external storage devices, and can be analyzed using the amcache plugin of RegRipper.
AppCompatCache is also known as Shimcache. A component of Application Compatibility Database - created by Microsoft for use by Windows OS to identify app compatibility problems. Helps developers troubleshoot legacy functions and contains data related to Windows features. Used for search to decide if modules need shimming for compatibility or not. A "Shim" is a small library, it transparently handles the applications interworking to provide support for older APIs in a newer environment or vice-versa. Shims allow backwards and forwards compatibility for apps on different software platforms.
if the application was... launched by the user. It does not record the number of times, the parent process or user identification information.
Attributes - For each file (or directory) described in MFT record, there's linear repository of stream descriptors (also named attributes), packed together in one or more MFT records (containing the so-called attributes list), with extra padding to fill the fixed 1 KB size of every MFT record, and that fully describes the effective streams associated with that file.
Each attribute has an attribute type (a fixed-size integer mapping to an attribute definition in file $AttrDef), an optional attribute name (for example, used as the name for an alternate data stream), and a value, represented in a sequence of bytes.
For NTFS, the standard data of files, the alternate data streams, or the index data for directories are stored as attributes.
Autoruns - shows you what programs are configured to run during system bootup or login, and when you start various built-in Windows applications like Internet Explorer, Explorer and media players. These programs and drivers include ones in your startup folder, Run, RunOnce, and other Registry keys. Autoruns reports Explorer shell extensions, toolbars, browser helper objects, Winlogon notifications, auto-start services, and much more.
Autorunsc - is the command-line version of Autoruns. Its usage syntax is:
This concludes of the A list, I will be grouping different pieces together for example A, B-C, D-E, F, H-K, etc.
Last edited:
