Presenting at SANS Institute's DFIRCON!

I am pleased to announce that I will be presenting my research on the Windows 8 Prefetch at SANS Institute's DFIRCON.  The conference will be held in Monterey, CA from March 5th to March 10th 2014.  If you have not had a chance to see the line up that will be at this conference please check out the brochure.  Thanks to Chad Tilbury and Rob Lee for giving me the opportunity to present this information to the broader audience, and to those who have read my blog and spread my research.

malsysproc

This weekend I was working on some memory analysis using Volatility, and I came across a sample that had a malicious process named svchost.exe.  Now if you have read Mandiant's M-Trends report, then you know that svchost.exe is the most common name of malware found.  If you have spent any amount of time working with Windows forensics or incident response, then you are very familiar with the reason why malware authors name their process svchost.exe.  In a normal Windows installation there are approximately 6-10 svchost processes running at any given time.  In this particular sample, it was fairly easy for me to spot the malicious process because it was exhibiting behavior that was abnormal for its name.  However, if an analyst does not have a familiarity with what behavior is "normal", then it may be difficult to determine the nature of this seemingly common process.  By then end of the analysis I had run quite a few plugins just to get the information I needed to determine the intent of this process, and I began wondering if there was some way to tie these commands together.  I first looked into writing a bash script to run multiple plugins automatically and parsing out specific information from each output, but after a few minutes Googling I realized writing my own plugin would be much cleaner.  This post describes the information I learned along the way, and will discuss the features (present and future) of the plugin I wrote.

Volatility Documentation
Upon setting out on my journey to learn how to write my own Volatility plugin, I stumbled upon the official developer's guide for Volatility 2.2.  This guide gives you all of the information you need to start writing your first plugin.  I also found a few blog posts useful, one from  Jamie Levy and one from Command Line Kung Fu where MHL shows how writing a new plugin might be a million times easier than parsing the output of multiple plugins.

malsysproc
I wrote the malsysproc plugin to be an automated method of looking at the behaviors of system processes  to look for malware hiding in plain sight.  Initially malsysproc looks at processes named svchost and lsass and determines if the process is legitimate.  This plugin will also look for processes named similarly to svchost and lsass such as lssas or scvhost.

The first test ran against each process is to check that the name of the process is actually what is expected.  I wanted to ensure the plugin doesn't overlook the lookalikes, so I initially look for processes that match a regular expression.  The regular expression is very simple, and it looks for characters to be switched around.  If a process does have letters switched around it will fail the name test.

While looking for processes named lsass.exe I keep track of each process I find, and if I find more than one lsass.exe I notify the analyst.

After running the name test, it is important to ensure that the process is running from the expected path.  Often times hackers will name their malware for a native Windows process, but they will put it in a different directory like a temp folder.  This check that the path matches the path of the native Windows process (C:\windows\system32\ for both lsass.exe and svchost.exe).

One way to spot a malicious svchost process is to run Volatility's pstree plugin.  pstree shows a graphical representation of each process' parent-child relationship.  svchost.exe should always be a child of services.exe, and if it isn't then we have a clear indicator of wrong doing.  Similarly, lsass.exe should be the child of wininit.exe for systems running Vista or better, or winlogon.exe for systems running XP or older.

Time is another valuable method to use when looking for malware posing as system processes.  In this plugin, I compare each system process' creation time to that of its parent, and if the system process was created more than 10 seconds after its parent it is flagged.  I have not done extensive testing on this test yet, but on the 3 memory samples I ran the plugin against it hasn't had any false positives.

Sometimes the Operating System gives system processes a higher base priority than that of normal user processes.  In his analysis of Stuxnet MHL notices that although Stuxnet uses the process hollowing technique to inject itself into a real lsass.exe process, it fails to properly set the base priority level of the process.  This allows us to pick out the imposter lsass.exe processes.  Unfortunately, svchost processes run at the default base priority level, so this technique cannot be used to find malicious svchost processes.

Lastly, I compare the command line arguments of each system process to a list of expect arguments.  If the process was run without or with incorrect expected arguments this test will flag the process as being suspicious.

A few future additions will be adding tests for process owner, unexpected network connections, looking for dll injection, and unexpected child processes.

Check out the code here.  Copy the file to your volatility/plugins directory, and it will be automatically added to your plugins list.

Examples

An example of running malsysproc against an image running a malicious svchost.exe process.  This process was not running out of the C:\WINDOWS\system32\ directory, did not have the correct parent process, was started much later than the other svchost.exe processes, and did not have appropriate command line parameters.

An example of malsysproc when run against a stuxnet memory image.  Because multiple lsass.exe process were found the plugin warns the analyst that this is not normal behavior.  Also, these processes do not have the correct parent process, they were started later than expected, their base priority level was at the default instead of being elevated, and they appear to have an unexpected command line (in this case it seems they have extra '\' characters to escape the '\' characters in the path itself.

There you have it.  I found a problem, researched solutions, learned the interface, and produced my first plugin in about an hour of work.  I plan to follow this post up with more detail on what a plugin requires, and how you can write your own.  Thanks for reading!

If you have any questions, comments, or concerns please let me know at [email protected].

What's New in the Prefetch for Windows 8??

I am currently working on a PowerShell module that will provide a remote forensic capability for forensicators and incident responders alike.  I know many tools that parse file based forensic artifacts (Ex: Prefetch), but none of these tools parse remote artifacts.  Remote parsing provides defenders with many advantages, including a capability called Least Frequency of Occurrence (LFO).  If a defender can aggregate data from every prefetch file on every host in a large network, they can use LFO to spot anomalies, which may in turn point out malicious activity.

While creating a cmdlet, to parse Windows Prefetch files, I realized that there were many inconsistencies between the format of prefetch files on Windows XP and Windows 7.  I also realized that little research had been done regarding the structure of Windows 8 prefetch files, and assumed there would be small inconsistencies with this version as well.  I am writing a blog series to describe the methodology I used to learn Windows 8 prefetch file format, and to document some of the interesting finds along the way.

What is Prefetch?
Simply put, application prefetching is used to store information about frequently used applications to help Windows load them more quickly in the future.  This information is stored in "prefetch" files found in the %systemroot%\Prefetch\ directory.  At any given time the system can keep up to 128 (Windows XP/2003/Vista/7/2008) or 1024 (Windows 8/8.1/2012) individual prefetch files (Each one correlates to a single application).  These files contain information about the application like how many times it was run, when was it last run, what path it was run from, what external files it loaded in its first 10 seconds of execution, etc.

Understanding the Prefetch File Format (Windows 8)

This series of examples is using a cmd.exe prefetch file from Windows 8

File Signature (Offset: 0x00 8-bytes)

The first value found in the data structure is the File Signature at Offset 0x00.  The signature is a 8-byte value containing (0x1A,0x00,0x00,0x00,0x53,0x43,0x43,0x41), the first of which represents the OS (0x11 = XP, 0x17 = 7, 0x1A = 8).  The ASCII representation of the final 4 bytes is SCCA, which is commonly recognized as the Prefetch File Signature.

Application Name (Offset: 0x10 60-bytes)

Next, at Offset 0x10, we see a Unicode Formatted String that says "CMD.EXE".  This value represents the name of the application for which this prefetch record has been created.  This name can/should be compared to the name of the prefetch file itself to ensure the file name has not been tampered with.  One important detail is that this value is represented in 60 bytes, to allow for variable lengths of application names.  The standard is for the application name to be terminated by Unicode NULL (0x0000).

File Path Hash (Offset: 0x4C 4-bytes)

Have you ever wondered about those 8 random hex values in name of prefetch files?  Interestingly enough the value is a hash of the application's file path.  Remember earlier I said that one prefetch file is created for each application run?  Well...that is not entirely truthful.  A more precise explanation is that one prefetch file is created per application from a specific file path.  When cmd.exe is run from C:\Windows\system32 one prefetch record is created.  However, if I copy cmd.exe to C:\Windows and execute it, a second prefetch file will be created.

From a detection/investigation perspective this hash can be useful in finding malware hiding in plain sight.  Often times attackers will name their malware as common Windows applications, putting their version in a different directory than the real thing (Ex: Placing svchost in C:\Windows instead of C:\Windows\system32).  If they are careless and execute the malware without cleaning up their tracks, there will be a conspicuous second prefetch record for svchost that will provide investigators with some attack details.

Similarly to the application name, the file path hash is stored inside the prefetch file.  This can again be used to check for simple manipulation of the prefetch file name.

NOTE: The majority of non-unicode values are stored in Little Endian, so when parsing/reading the values make sure you flip the bytes.

Application Run Count (Offset: 0x0D 4-bytes) 

One of the more useful pieces of information found in the prefetch file is the run count, found at Offset 0xD0).  The run count tells a forensicator how many times the application has been executed. Remember this value is stored in Little Endian, so this example shows the run count to be one.

Last Access Timestamp (Offset: 0x80 8-bytes)

The last really useful piece of information found in the main section of the prefetch file is the last accessed timestamp.  This value is of extreme importance during an investigation because it tells the investigator when the program was last executed.  This value is stored as a "FILETIME" object, which is describe by Microsoft as being "the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC)".  There are plenty of way to turn the hex value into an actual time (Ex: the hex editor I'm using automatically converts hex timestamps to the actual time, or you can use PowerShell to convert the value with .NET).

Christmas coming early...Thanks Microsoft!
Some of you may be familiar with the file structure of a prefetch file in previous versions of Windows.  If you are you are probably asking why the run count (Offset 0xD0 isn't directly following the timestamp (Offset 0x80) like it always has.  Well my friends, this is because Microsoft has decided to throw us a bone for whatever reason.  Prefetch files in Windows 8 contain not one timestamp, not two timestamps, but 8 Last File Accessed Timestamps!  Below I show a quick demonstration of how the Windows 8 prefetch files store the 8 timestamps.

2 Timestamps

Above is a screen shot of the same CMD.EXE prefetch file, except I ran the application an extra time to increase the run count (0xD0) to two times.  The important thing to notice is that the original timestamp has been shifted over to Offset 0x88, and the most recent timestamp has moved in to the 0x80 position.   Well this is interesting, but what about the other 64 bytes between the 2nd timestamp and the run count value?

8 Timstamps

After some trial and error testing I was able to determine that the Windows 8 prefetch files will store the 8 most recent last accessed timestamps.  Notice in the screenshot that the original time is still there, but it has been moved all the way down to the basement (Offset: 0xB8).  It is interesting to note that there is still 16 bytes of 0's.  What ever comes of that space?

What happens after 8?!?

Well that is a good question.  I have noticed that those 0's are changed after the timestamp slots a filled, but I have yet to determine what the value represents (If anyone knows or figures it out please let me know).  I am assuming it has something to do with the timestamps because the values seem to only appear after the 8 timestamp values have been created.

Conclusion
Well this concludes the first portion of my foray into the Windows 8 Prefetch File Structure.  My next post will discuss the different sections contained within prefetch files, and what information can be found in each section.

R2D2 Memory Sample Analysis

Introduction
One of the skills I have been learning over the past year and a half or so is memory analysis.

For those of you that don't know the Volatility's Google Code page has made quite a few memory samples available for test analysis.  I stumbled upon them this evening, and I figured I'd try to tear one apart for an hour or so, and see where that got me.

The sample I decided to begin with, at random, was the one titled R2D2 (cool sounding name)

For my analysis I used Volatility 2.2 and SANS' Ubuntu SIFT Workstation VM.


Setup
Personally I don't like to look at long command lines, so the first order of business during memory analysis is to set up my Volatility environment variables (VOLATILITY_LOCATION & VOLATILITY_PROFILE).  Initially the profile (OS/Service Pack/Architecture) is not known, so I settle for setting the location with the following command:

Once the location is set we can start using Volatility!  The great news is that Volatility already knows what image we want to analyze because of the variable we just set.  The first plugin that should be run during memory analysis is imageinfo.  imageinfo provides us with the image's profile, which is a cruicial piece of information when using Volatility.  Specifying an image tells Volatility what data structures to expect when parsing the image.  To execute the imageinfo plugin you simply type:

Now that we have found the suggested profile we can specify our VOLATILITY_PROFILE environment variable:

Analysis
Ok, we have handled all the necessary setup, and now it is time to roll up our sleeves and dig into some R2D2 memory analysis.  I like to start my analysis looking for low hanging fruit (processes, network connections, services, and drivers).  These artifacts are the most tangible artifacts, and we tend to have the most experience with them.  I began with the pstree plugin to see a hierarchical view of the processes relative to their parent process:

Initially nothing stuck out from the process tree, so I moved on to psxview.  The psxview plugin queries process data structures using 4 or 5 different methods.  The output contains a list of processes, and tells the analyst whether each method was successful in detecting the process or not.  For example, if a process is found using the pslist method (follows the linked list from one EPROCESS structure to another), but not using the psscan method (search for EPROCESS structures regardless of linked list), then it is a good indication the system has been manipulated (possibly by a rootkit using DKOM techniques).  You can use the psxview plugin like so:

This sample appears to have no hidden processes.

It is always a good idea to see what network traffic was occurring at the time of the memory capture.  The connscan plugin will parse connection information from the image.

It appears there was an established connection from the localhost on local port 1026 to 172.16.98.1 on port 6666.  This connection was established by PID 1956 or explorer.exe (correlated from pstree output).  This connection is suspicious because explorer.exe does not typically make network connections, so this connection lets us know that explorer.exe is probably our process of interest.

Using the output of pstree we see that cmd.exe is a child process of explorer.exe, and it might be nice to see what commands were issued to that cmd shell.  One cool plugin is the cmdscan (or consoles for Windows 7 and Server 2008).  The cmdscan plugin parses the command history buffer located in csrss.exe (or conhost.exe on Windows 7 and Server 2008), and returns any commands that remain in the memory buffer.  Below is the command line usage for the cmdscan:

In the command history buffer were two commands "sc query malwar" and "sc query malware" (Just what we were looking for!).  It appears the attacker was checking on the registration details for a service named malware.  At this point the service name is a good indicator of malicious activity, but I've seen some pretty strange things in the past.

To enumerate that service information we can check the HKLM\SYSTEM\ControlSet001\Services registry key for the "malware" service's registration details.  We have to first find the virtual memory address of the System hive, which we can do using the hivelist plugin.

Once we have the virtual address (0xe1018388) we can enumerate the key ControlSet001\Services\malware using the printkey plugin.

Looking at the malware service we notice the service's image path was C:\WINDOWS\system32\drivers\winsys32.sys with a start type of 1 which according to Microsoft "represents a driver to be loaded at kernel initialization", or what appears to be the persistence mechanism.

Now we need to learn more about this apparent driver, and maybe even grab a copy of it for ourselves.  Using Volatility's svcscan we can gather more information about the "malware" service.

The results show that the driver associated with this service is recognized as \driver\malware.  We can now work toward grabbing a copy of the running driver.  We must execute a driverscan to access the starting memory address of the driver.

Once the address is obtained (0xf9eb4000) we can use moddump to dump the driver at the address specified using the  -b parameter.

We now have a copy of the suspected malicious driver (winsys32.sys), which we can pass to Virus Total (if we think it has been seen before) or our reverse engineers.  I submitted the driver to Virus Total, and it was flagged by 14/35 anti-virus programs as the R2D2 backdoor.

We can perform rudimentary analysis of the driver using the strings utility.

Below is an example of view the ascii strings contained within the malicious file.

Earlier we found a suspicious network connection coming from explorer.exe.  We know explorer.exe to be a legitimate process, so we may want to look for dll injection as a possible avenue of infection. We can list explorer.exe's loaded modules using the dlllist plugin.

One module (mfc42ul.dll) seems to stand out because its virtual address is so different than other modules (0x10000000 vs 0x70000000).  I am unsure if this is a valid indicator of dll injection or just a coincidence, but I submitted the module to Virus Total, and the dll was flagged as being associated with the same R2D2 backdoor.

NOTE: In the ascii strings output of the malicious driver (winsys32.sys) we find references to the malicious module (mfc42ul.dll).

We perform some quick triage of the dll and notice some strings that indicate HTTP functionality, and we also see a string "C3P0-r2d2-POE" which appears to be the string that got this malware its name.

That wraps up my analysis of the R2D2 backdoor.  Upon completion of my analysis, I stumbled upon evild3ad's blog post documenting his analysis of the same sample.  Please check it out!

If anyone has additional details I missed, or has any feedback to improve my methodology it would be greatly appreciated.

PowerShell Intro

Before covering how Incident Responders can leverage Windows PowerShell, I thought it would be appropriate to provide a small introduction for those who are not familiar with all the cool things that can be done through PowerShell.

What is PowerShell:
Windows PowerShell is Microsoft's answer to our cries for a better scripting environment and command shell.  Scripting in PowerShell is much more intuitive than batch, and although PowerShell does have some Microsoft centric quirks it more closely resembles other interpreted languages like Python.  Microsoft has made the entire .NET framework available through PowerShell, which allows a great deal of flexibility to those who want to take on development.  Through PowerShell, Microsoft without a doubt opened many doors for Forensicators and Incident Responders.

PowerShell introduces two features which make scripting significantly more easy.  The first feature is tab completion, those readers familiar with unix will understand how nice tab completion can be.  If you do not know the exact command syntax all you have to do is press tab and PowerShell will do the work for you.  The second, and in my opinion most important, feature is the object oriented nature of PowerShell.  PowerShell commands (Cmdlets) return .NET objects, which can be manipulated to display the desired results.  These new features alone make scripting in PowerShell easier and more logical than batch or VB scripting.

PowerShell History:
To better understand Windows PowerShell's origins refer to Jeffrey Snover's Monad Manifesto. The manifesto describes Monad platform, one part of which was the Monad Shell.  The Monad Shell is the brainchild which would eventually morph into PowerShell.

Availability:
PowerShell version 2.0 is available on Windows 7 and Windows Server 2008 by default.  Depending on your patching you may have version 2.0 if you are running Windows XP SP3, Windows Vista SP1, or Windows Server 2003 SP2. If you have a pre Windows 7 host that does not have PowerShell you can find the appropriate patches here.  PowerShell version 3.0 is available on Windows 8 and Windows Server 2012, and version 4.0 will be introduced with Windows 8.1 Beta and Windows Server 2012 R2.  To learn more about the additions to PowerShell in version 3.0 and 4.0 click the links embedded in their version numbers.

Environments:

PowerShell provides users two main environments, the Command Line Interface (CLI) and the Integrated Scripting Environment (ISE).

Windows PowerShell (CLI)

Windows PowerShell ISE

The CLI is your go to interface for PowerShell.  You can treat it exactly the same as the Windows Command Shell (in fact if you enter a native Windows command, PowerShell will automatically spawn a Command Shell and execute the command for you).  The CLI's utility begins to run out when you want to introduce logic or use more than one line which is why Microsoft gives us the ISE.  The ISE is enabled by default on Windows 7, but on Server 2008 you must install the Windows PowerShell Integrated Scripting Environment (ISE) feature.  The ISE provides, as the name implies, an environment that is fairly useful for writing, testing, and debugging scripts.  As seen in the picture above the ISE has three windows.  The window on the right is the script pane, where users can author scripts using some niceties like tab completion.  The bottom left window is the console pane which has practically identical use as the Windows PowerShell CLI.  The top left windows is the output pane, which is where output is written by default (PowerShell supports many different outputs such as: text, csv, html, and xml)

Cmdlet Naming Convention:
All PowerShell cmdlets follow a standard naming convention which is called the verb-noun convention.  Each cmdlet name will consist of a verb followed by a dash (-) and a singular noun.  Some example cmdlet names are Get-Process, Stop-Service, Set-Variable, and New-Object.  MSDN has a list of each approved verb and its meaning.

3 Cmdlets to Rule them All:
There are three cmdlets that will enable new users to use every other cmdlet available in Windows PowerShell.

The first cmdlet every PowerSheller should know is Get-Command.  This cmdlet returns a list of every cmdlet available in the current shell.  Get-Command can be used alone, or if you are looking for a specific type of cmdlet you can the -Verb parameter to specifically look for cmdlets that perform a certain action, and -Noun which will show all cmdlets pertaining to a specific type of object.

The second important cmdlet is Get-Help which is the equivalent of Linux's man command.  This cmdlet returns the help file which contains syntax, parameter descriptions, and usage examples.
Once you have found the cmdlet you want to use, and have determined the proper syntax it is important to understand what output you will receive.

As mentioned earlier PowerShell is object oriented, so each cmdlet will return an object with a series of properties and methods.  The cmdlet Get-Member accepts an object as a parameter, and will return the properties and methods of the object.  The most common syntax for Get-Member is Get-Process | Get-Member which will provide the output of Get-Process as the input object for Get-Member. 

PS Drives:
One final feature readers should be aware of is how PowerShell deals with structured system data.  PowerShell has a feature known as PSDrives through which it treats structured system data (i.e. the Windows Registry) as if it were the file system.  Additionally, PSDrives do not require single letter names, so you can name you data drive "Data" instead of "D:\".

To enumerate all PSDrives on the system use the cmdlet Get-PSDrive.  Below is some example output of the Get-PSDrive cmdlet.  As you can see there are many PSDrives available in the current PowerShell session such as the Local Machine and Current User registry hives, as well as, shell variables and aliases.  PowerShell treats all data as items, and the PSDrive concept allows administrators to learn one method that will work for files, registry, environment variables, etc.

Further Reading:
For those interested in learning a little more in depth about PowerShell basics there is an excellent book written by Don Jones called Learn Windows PowerShell 3 in a Month of Lunches. Don Jones is one of, if not the most, respected minds in regard to PowerShell, and he does an excellent job introducing this application to readers through a series of 1 hour lessons or lunches (I read it over a weekend because I was in a hurry to learn as much as possible).

SANS FOR 508 Advanced Computer Forensics and Incident Response Review

Last week I was lucky enough to attend the FOR 508: Advanced Computer Forensics and Incident Response course at SANS' Digital Forensics and Incident Response Summit, as a work study student. The course (508) was taught by Chad Tilbury (Check him out!), and is the brain child of SANS Fellow Rob Lee. Not only was Chad one of if not the best instructor I have had in the Computer Security field, but the course material is second to none. 508 is without a doubt worth the time and money you (or your employer) will invest in it.

The Concept:
508 has recently been retooled to focus on battling the much maligned Advanced Persistent Threat (APT). The class motto is "APT is in your network, start hunting". The APT focus makes it 100% relevant to not just forensic investigators, but to anyone wanting to learn to defend their network. This course is up to date with the latest forensics techniques, in fact, Chad introduced us to tools that were still in beta and methodologies that are still being researched!

The Material:
SANS recommends that students attend FOR 408: Computer Forensic Investigations - Windows In-Depth before attending 508 (they recommend it for a reason), but if you have a forensics background or are willing to put in a little overtime you should be able to catch up enough to take 508 (508 has more direct application to my needs, although I look forward to attending 408 in the future). Rob Lee says the expectation of 508 students is that they understand conversational forensics (can speak to different forensics artifacts and tools). This course is a smorgasbord of valuable skills and information for incident responders, system administrators, and forensicators alike.

On day 1 they cover the physical layers of the file system (from the physical platters to the file name layer that contains file names and a directory structure), and how to properly mount images for analysis (e.g. read only). Just when you think the first day couldn't cover any more information the class jumps into the exciting world of Enterprise Analysis and Live System Incident Response (my favorite!!).  This portion teaches students about domain authentication, how to secure domain administrator credentials, and many methods of accessing system information on remote of hosts (Many of my future blog posts will revolve around utilizing PowerShell for "Live System 'Enterprise' Incident Response" for lack of a better term).

Day 2 is spent covering memory forensics. SANS offers a course on Memory Forensics that is currently 5 days long and covers the details of memory (memory structures and such), but 508 offers a very practical lesson in how to implement memory forensics TODAY. Students will learn how to acquire memory, as well as, how to provide in depth analysis of the memory once acquired (Day 1 offers insight into a method of analyzing memory without having to first complete the acquisition process...which is awesome!). Memory forensics is absolutely necessary when combating APT as it is one of the best, if not only, methods to detect rootkits (See SANS instructor and FOR 526 author Jesse Kornblum's paper regarding the rootkit paradox). The best part of Day 2 is that it doesn't focus on one method of analyzing memory. Instead 508.2 spends the time to teach students the pros and cons to different tools, and even different methods of using the same tool.

Day 3 is dedicated to timeline analysis. No one should be considered a forensicator or incident responder if they do not have an intimate knowledge of timeline analysis (Specifically using log2timeline). Log2timeline came out of a GCFA Gold Paper written by Kristinn Guðjónsson, and the community has never looked back. Log2timeline is really a cultural shift in the way we perform investigations, as it aggregates almost every forensic artifact into one timeline that truly tells the story of actions taken on a machine. This is where that 408 knowledge comes in handy... if you do not know how to interpret a specific artifact, then you lose fidelity in your timeline (possibly the opportunity to spot malicious activity).

Day 4 and 5 begin with XP Restore Point and Volume Shadow Copy analysis which can be harnessed for some really cool stuff. We can use these snapshots to add fidelity and depth to our timeline, and we can use them to recover deleted files. Next, Chad covered deep dive forensics (This is where the class dives into the weeds of file system analysis). The class dives into $MFT analysis which introduces us to a second set of timestamps ($STDINFO), and new artifacts like the NTFS TriForce (David Cowen's baby). These artifacts will not be presented in any other course!  Day 5 wraps up with methods and techniques of finding unknown malware. Assuming anti-virus fails to detect a threat, what are some methods we can use for detection? FOR 508 introduces and spends half a day discussing the concept of malware funneling which is the process of reducing data through a series of automated tasks until you have a small enough data set that you can perform manual analysis (SANS instructor Alissa Torres has an excellent webinar on the subject).

The Lab (Day 6):
The last day of the class is spent in on a team exercise.  The team investigates a set of hosts that were part of an intrusion, however this is not your normal everyday exercise....this is where it gets interesting!

Rob Lee went all out on this course developing it around an "as real as it gets" scenario. The scenario is about an R&D firm that makes a great discovery, only to be hacked by APT. Students are given four hosts to conduct forensic investigations to determine what happened.  Questions like the initial infection vector, when the initial infection occurred, what data was lost, and the current state of the network can be answered.

When we talk about this lab it is important to understand the level of detail used to create this virtual network. Not only did the network have 100s of hosts and 1000s of users, Rob Lee went out of his way to ensure this network was as real looking as possible (He basically lived with multiple personalities over the course of a year to ensure the systems were used as they would be in a real domain environment). He hired a professional Red Team and trained them up to act like APT, he hired domain architects to build the domain in a professional/secure manner, and he even loaded the systems with some of the latest security tools.  You will not find a lab this extensive anywhere else!

Overall:
All in all this course is so relevant and so practical that there is no reason not to put this one on your wishlist. If you are serious about finding bad guys in your network, cause lets face it they are there, then this course has your name on it. I learned more about forensics in one week than I have learned over the past three years!




Bonus:
At the DFIR Summit in Austin Rob Lee and his Forensicating Cohorts at SANS introduced, for the first time in the United States, a new version of SANS' famous NetWars. Following along with the 508 labs they have created a forensic version of NetWars which tests students on basic forensic artifacts, timeline, registry, file system, and memory analysis. Anyone that has participated in NetWars will agree that it is terrific learning environment and is worth the investment of time.

I was lucky enough to earn my Lethal Forensicator Coin by placing first in this NetWars competition at the DFIR Summit.

Welcome to Invoke-IR

Welcome to Invoke-IR, the blog where I (Jared Atkinson) will discuss Digital Forensics and Incident Response using Windows PowerShell.  Windows PowerShell is an excellent application that solves many of the complaints we all have about the native Windows command shell.  Unfortunately many system administrators, incident responders, and forensicators are not familiar enough with Windows PowerShell to understand its use.  Through Invoke-IR (the name is a PowerShell pun) I will introduce readers to PowerShell itself, some resources that will provide a deeper understanding of PowerShell and digital forensics, and how we can apply PowerShell to Incident Response.

Some topics I plan on covering in the near future are:
1) Intro to PowerShell
2) PowerShell Remoting
3) Windows Logon and Authentication (How it relates to PowerShell)
4) Dealing with Event Logs in PowerShell
5) Handling the Windows Registry through PowerShell
... and much much more

Thank you for visiting Invoke-IR and I am looking forward to reading your comments and questions.