Hopefully, something that will become evident throughout this post, as well as other HowTo posts, is that rather than focusing on individual artifacts, we're going to start putting various artifacts into "buckets" or categories. The purpose for doing this is so that analysts don't get lost in a sea of artifacts, and are instead able to tailor their initial approach to an examination, possibly using an analysis matrix.
Okay, let's get started...
AutoStart Locations
Before we begin to look at the different artifacts that can be directly tied to a user (or not), I wanted to briefly discuss autostart locations. These are locations within the system...file system, Registry...where references to programs can reside that allow programs to be executed automatically, without any interaction from the user beyond booting the system or logging in. There are a number of such locations and techniques that can be used...Registry autostart locations, including the ubiquitous Run key, Windows services, the StartUp folder on the user's Program Menu, and even the use of the DLL Search Order functionality/vulnerability. Each of these can be (and have been) discussed in multiple blog posts, so for now, I'm simply going to present them here, under this "umbrella" heading, for completeness.
Scheduled Tasks can be, and are, used as an autostart location. Many of us may have QuickTime or iTunes installed on our system; during installation, a Scheduled Task to check for software updates is created, and we see the results of this task now and again. Further, on Windows 7 systems, a Scheduled Task creates backups of the Software, System, Security, and SAM hive files into the C:\Windows\system32\config\RegBack folder every 10 days. When considering autostart locations, be sure to check the Scheduled Tasks folder.
Tip
On a live system, you need to use both the schtasks.exe and at.exe commands to get a complete listing of all of the available Scheduled Tasks.
On a live system, you need to use both the schtasks.exe and at.exe commands to get a complete listing of all of the available Scheduled Tasks.
Tools: RegRipper plugins, MS/SysInternals AutoRuns; for XP/2003 Scheduled Task *.job files, jobparse.pl; on Vista+ systems, the files are XML
User
There are a number of artifacts within the user context that can indicate program execution. This can be very useful, as it allows analysts to correlate program execution to the user context in which the program was executed.
UserAssist
The contents of value data within a user's UserAssist subkeys can provide an excellent view into what programs the user has launched via the Explorer shell...by double-clicking icons or shortcuts, as well as by navigating via the Program Menu. Most analysts are aware that the value names are Rot-13 encoded (and hence, easily decoded), and folks like Didier Stevens have gone to great lengths to document the changes in what information is maintained within the value data, as versions of the operating systems have progressed from Windows 2000 to Windows 8.
Tools: RegRipper userassist.pl and userassist_tln.pl plugins
RunMRU
When a user clicks on the Start button on their Windows XP desktop, and then types a command into the Run box that appears, that command is added to the RunMRU key.
Interestingly, I have not found this key to be populated on Windows 7 systems, even though the key does exist. For example, I continually use the Run box to launch tools such as RegEdit and the calculator, but when I dump the hive file and run the runmru.pl RegRipper plugin against it, I don't see any entries. I have found the same to be true for other hives retrieved from Windows 7 systems.
Tools: RegRipper runmru.pl plugin
ComDlg32\CIDSizeMRU Values
The binary values located beneath this key appear to contain names of applications that the user recently launched. From my experience, the majority of the content of these values, following the name of the executable file, is largely zeros, with some remnant data (possibly window position/size settings?) at the end of the file. As one of the values is named MRUListEx, we can not only see (via a timeline) when the most recent application was launched, but we can also see when other applications were launched by examining available VSCs.
AppCompatFlags
According to MS, the Program Compatibility Assistant is used to determine if a program needs to be run in XP Compatibility Mode. Further, "PCA stores a list of programs for which it came up...even if no compatibility modes were applied", under the Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted key in the user's NTUSER.DAT hive. As such, we can query these values and retrieve a list of programs run by the user.
Tools: RegRipper appcompatflags.pl plugin (I updated the plugin, originally written by Brendan Cole, to include retrieving the values beneath the Persisted key, on 6 July 2013; as such, the plugin will be included in the next rollout)
MUICache
The contents of this key within the user hives (NTUSER.DAT for XP/2003, USRCLASS.DAT for Win7) often contains references to applications that were launched within the user context. Often times, these application will include command line interface (CLI) utilities.
Windows shortcuts/LNK files and Jump Lists
You're probably thinking..."huh?" Most analysts are familiar with how shortcuts/LNK files (and Jump Lists) can be used to demonstrate access to files or external storage devices, but they can also be used to demonstrate program execution within the context of a user.
Most of us are familiar with the LNK files found in the ..\Windows\Recent and ..\Office\Recent folders within the user profile...so, think about how those shortcuts are created. What usually happens is that the user double-clicks a file, the OS will read the file extension from the file, and then query the Registry to determine which application to launch in order to open the file. Windows will then launch the application...and this is where we have program execution.
Many times when a user installs an application on their system, a desktop shortcut may be created so that the user can easily launch the application. The presence of an icon on the desktop may indicate that the user launched an installer application.
Tools: custom Perl script, tools to parse LNK files
Java Deployment Cache Index (*.idx) Files
The beginning of 2013 saw a lot of discussion about vulnerabilities to Java, as well as reports of 0-days, and as a result, there was a small number of folks within the community looking into the use of Java deployment cache index (*.idx) files during analysis. The use of these files as artifacts during an investigation goes back to well before then, thanks to Corey Harrell. These files provide indications of downloads to the system via Java, and in some cases, those downloads might be malicious in nature. These artifacts are related specifically to Java being executed, and may lead to indications of additional programs being executed. Further, given that the path to the files is within the user profile folder, we can associate the launch of Java with a specific user context.
Tools: idxparse.pl parser
Browser History
A user's browser history not only indicates that they were browsing the web (i.e., executing the browser program), but the history can also be correlated to the *.idx files discussed above in order to determine which site they were visiting that caused Java to be launched.
System
There are a number of artifacts on the system that can provide indications of program execution
Prefetch File Analysis
Most analysts are aware of some of the metadata found within Prefetch files. Application prefetch files include metadata indicating when the application was last launched, as well as how many times it has been launched. This can provide some excellent information
Tools: pref.pl, or any other tools/scripts that parse the embedded module strings. Recent versions of scripts I've written and use incorporate an alerting mechanism to identify items within the strings and string paths found to be "suspicious" or "unusual".
AppCompatCache
This value within the System hive in the Registry was first discussed publicly by Mandiant, and has proven to be a treasure trove of information, particularly when it comes to malware detection and determining program execution, in general.
Tools: Mandiant's shim cache parser, RegRipper appcompatcache.pl plugin (appcompatcache_tln.pl plugin outputs in TLN format, for inclusion in timelines).
Legacy_* Keys
Within the System hive, most of use are familiar with the Windows services keys. What you may not realize is that there is another set of keys that can be very valuable when it comes to understanding when Windows services were run...the Enum\Root\Legacy_* keys. Beneath the ControlSet00n\Enum\Root key in the System hive, there are a number of subkeys whose names being with LEGACY_, and include the names of services.
There are a number of variants of malware (Win32/Alman.NAD, for example) that install as a service, or driver, and when launched, the operating system will create the Enum\Root\Legacy_* key for the service/driver. Also, these keys persist after the service or driver is no longer used, or even removed from the system. Malware writeups by AV vendors will indicate that the keys are created when the malware is run (in a sandbox), but it is more correct to say that the OS creates the key(s) automatically as a result of the execution of the malware. This can be an important distinction, which is better addressed in another blog post.
Tools: RegRipper legacy.pl plugin
Direct* and Tracing Keys
These keys within the Software hive can provide information regarding program execution.
The "Direct*" keys are found beneath the Microsoft key, and are keys whose names start with "Direct", such as Direct3D, DirectDraw, etc. Beneath each of these keys, you may find a MostRecentApplication key, which contains a value named Name, the data of which indicates an application that used the particular graphics functionality. Many times during an exam, I'll see "iexplore.exe" listed in the data, but during one particular exam, I found "DVDMaker.exe" listed beneath the DirectDraw key. In another case, I found "mmc.exe" listed beneath the same key.
I've found during exams that the Microsoft\Tracing key contains references to some applications that appear to have networking capabilities. I do not have any references to provide information as to which applications are subject to tracing and appear beneath this key, but I have found references to interesting applications that were installed on systems, such as Juniper and Kiwi Syslog tools (during incident response engagements, this can be very helpful and allow you collect Event Logs from the system that have since been overwritten, and included in a timeline...). Unfortunately, these artifacts have nothing more than the EXE name (no path or other information is included or available), but adding the information to a timeline can provide a bit of context and granularity for analysis.
Tip
When examining these and other keys, do not forget to check the corresponding key beneath the Wow6432Node key within the Software hive. The RegRipper plugins address this automatically.
When examining these and other keys, do not forget to check the corresponding key beneath the Wow6432Node key within the Software hive. The RegRipper plugins address this automatically.
Tools: RegRipper direct.pl and tracing.pl plugins
Event Logs
Service Control Manager events within the System Event Log, particularly those with event IDs 7035 and 7036, provide indications of services that were successfully sent controls, for either starting or stopping the service. Most often within the System Event Log, you'll see these types of events clustered around a system start or shutdown. During DFIR analysis, you're likely going to be interested in either oddly named services, services that only appear recently, or services that are started well after a boot or system startup. Also, you may want to pay close attention to services such as "PSExeSvc", "XCmdSvc", "RCmdSvc", and "AtSvc", as they may indicate lateral movement within the infrastructure.
On Windows 2008 R2 systems, I've found indications of program execution in the Application Experience Event Logs; specifically, I was examining a system that had been compromised via an easily-guessed Terminal Services password, and one of the intruders had installed Havij (and other tools) on the system. The Application-Experience/Program-Inventory Event Log contained a number of events associated with program installation (event IDs 903 and 904), application updates (event ID 905), and application removal (event IDs 907 and 908). While this doesn't provide a direct indication of a program executing, it does illustrate that the program was installed, and that an installer of some kind was run.
On my own Windows 7 system, I can open the Event Viewer, navigate to the Event Log, and view the records that illustrate when I have installed various programs knowingly (FTK Imager) and unknowningly (Google+ Chat). There are even a number of application updates to things like my ActiveState Perl and Python installations.
Tools: LogParser, evtxparse.pl
Other Indirect Artifacts
Many times, we may be able to determine program execution through the use of indirect artifacts, particularly those that persist well after the application has finished executing, or even been deleted. Many of the artifacts that we've discussed are, in fact, indirect artifacts, but there may still be others available, depending upon the program that was executed.
A number of years ago, I was...and I don't like to admit this...certified to perform PCI forensic audits. On one case, I ran into my first instance of a RAM scraper...this was a bit of malware that was installed on a point-of-sale (POS) back office server (running Windows) as a Windows service. After the system was booted, this instance of the malware would read the contents of a register, do some math, and use that value as a seed to wait a random amount of time before waking up and dumping the virtual memory from one of eight named (the names were listed in the executable file) processes. The next step was to parse the memory dump for track data, and this was accomplished via the use of Perl script that was "compiled" via Perl2Exe. I'm somewhat familiar with such executables, and one of the artifacts we found to validate our findings with respect to the actual execution of the malicious code was temporary directories created by "compiled" script. When executables "compiled" with Perl2Exe are run, any of the Perl modules (including the runtime) packed into the executable are extracted as DLLs into a temporary directory, at which time they are "available" to the running code. As the code was launched by a Windows service, the "temp" directories were found in the C:\Windows\Temp folder. The interesting thing that we found was that the temp directories used to hold the modules/DLLs are not deleted after the code completes, and they persist even if the program itself is removed from the system. In short, we had a pretty good timeline for each time the parsing code was launched.
On my own Windows 7 system, because I run a number of Perl scripts that were "compiled" with Perl2Exe within the context of my user account, the temp directories are found in the path, C:\Users\harlan\AppData\Local\Temp...the subdirectories themselves are named "p2xtmp-", and are followed by an integer, and themselves contain subdirectories that represent the Perl runtime namespace. The time stamps (creation dates) for these subdirectories provide indications of when I executed scripts that had been compiled via Perl2Exe.
Memory Dumps
During dead box analysis, memory dumps can be an excellent source of information. When an application crashes, a memory dump is created, and a log file containing information including a process list also created. When another application crash occurs, the memory dump is overwritten, but the log file is appended to, meaning that you can have a number of crash events available for analysis. I have found this historical information to be very useful during examinations because, while the information is somewhat limited, it can illustrate whether or not a program was running at some point in the past.
We're not going to discuss hibernation files here, as once you access a hibernation file and begin analysis, there really is very little difference between analyzing the hibernation file and analyzing a memory dump for a live system. Many of the techniques that you'd use, and the artifacts that you would look for, are pretty much the same.
Tools: text viewer
Malware Detection
Another use of this artifact category is that it can be extremely valuable in detecting the presence of malware on a system. However, malware detection is a topic that is best addressed in another post, as there is simply too much information to limit the topic to just a portion of a blog post.
Another use of this artifact category is that it can be extremely valuable in detecting the presence of malware on a system. However, malware detection is a topic that is best addressed in another post, as there is simply too much information to limit the topic to just a portion of a blog post.
Resources
This idea of determining program execution has been discussed before:
Timeline Analysis, and Program Execution
There Are Four Lights: Program Execution
29 comments:
I like these HowTo posts, especially this one. What about AV logs, or Windows Firewall exceptions?
What about AV logs, or Windows Firewall exceptions?
I'm including those in a different post.
Are there any other topics that you think would be of interest?
A post covering persistence mechanisms that Autoruns misses, and how to find them.
Some posts on Windows forensics that's more relevant to the larger network, such as; how to determine the scope of an incident, how to find and track lateral movement, or how to use intelligence from one victim to detect other victims on the network.
How to use Excel for analysis? I thought colorizing a timeline in the link below was creative. I wouldn't have thought of that, so if there are other creative and useful ways to use Excel for analyzing timelines or other digital evidence, a post on that would be helpful.
http://computer-forensics.sans.org/blog/2012/01/25/digital-forensic-sifting-colorized-super-timeline-template-for-log2timeline-output-files#
A post covering persistence mechanisms that Autoruns misses, and how to find them.
Do you have some particular ones in mind? I have some ideas regarding the DLL Search Order issue, but what other persistence mechanisms would you like to see addressed?
The rest are interesting...I'll see what I can come up with.
Harlan,
These posts have been amazing and a daily read for me every morning when there is a new one. As a recent grad just starting in the field, it's really helpful to not only have a recap of some topics, but also to see things from a different perspective.
I agree that a topic on advanced excel analysis would be very useful. Perhaps another interesting topic could be data exfiltration via cloud services and email, how to determine whether or not it occurred.
Looking forward to see whats next!
Harlan,
These posts have been amazing and a daily read for me every morning when there is a new one. As a recent grad just starting in the field, it's really helpful to not only have a recap of some topics, but also to see things from a different perspective.
I agree that a topic on advanced excel analysis would be very useful. Perhaps another interesting topic could be data exfiltration via cloud services and email, how to determine whether or not it occurred.
Looking forward to see whats next!
Ethan,
What do you mean by advanced excel analysis?
Thanks.
Similar to how anonymous stated,
How to use Excel for analysis? I thought colorizing a timeline in the link below was creative. I wouldn't have thought of that, so if there are other creative and useful ways to use Excel for analyzing timelines or other digital evidence, a post on that would be helpful
I personally underestimated how useful excel is. For example, a common thing I've come across so far is the need to manipulate paths to fit my encase naming convention in order to create successful conditions. Often, compressed archive paths tend to export out with >32,kdj| in the path. Importing this and using delimiters on > and |, replacing those with the appropriate name, such as \zip volume\, and concatenating these rows has been my standard method. Perhaps there is another, easier, way to do this though.
I suppose by advanced I merely mean techniques that you take advantage of and use commonly in excel, whether its tools like concatenate, vlookup, or others.
Hopefully this clarified it a little more.
... techniques that you take advantage of and use commonly in excel...
If by "you", you mean me, I don't use Excel for analysis, per se. I know of folks who use manual examination processes to locate artifacts of interest, and the add them to a spreadsheet, but this is a slow, laborious process. I also know of folks who use automated means to populate spreadsheets with timeline information, and then add color-coding, but I really don't think that you can do analysis by saying, "...find two red lines, followed by a grey one, and then a blue one..."...
DLL Search Order hijacking, MBR, binary patching (IAT hooks), rootkits that hide it, or "transient" persistence mechanisms that are placed on shutdown and removed at startup. This "Wipe the Drive" presentation has some unusual ones that I haven't heard of before:
https://www.youtube.com/watch?v=QCZ_7C9C5AU
If you don't use Excel much, that's fine. It could be less popular than I had thought. But I doubt Rob Lee and others are analyzing timelines just by "finding two red lines, followed by a grey one, and then a blue one." It's probably similar to malware analysts using IDA and looking for patterns of assembly, as well as reading line by line when necessary...
As Ethan mentioned, a how to determine if sensitive data was exfiltrated would also be interesting.
DLL Search Order hijacking, MBR, binary patching (IAT hooks)...
I've already addressed those in this blog but I can see the value in consolidating them. Thanks for the input.
...or "transient" persistence mechanisms that are placed on shutdown and removed at startup
Do you have an example of this?
I doubt Rob Lee and others are analyzing timelines just by "finding two red lines...
I agree with that statement, and to be honest, I'm not really clear as to why you'd say that.
My point was about how analysis is done, in general...not how it's done by folks of expert caliber. If someone really doesn't have a detailed understanding of what artifacts and data structures are being parsed and included in a timeline, and don't understand the context of those artifacts, then putting all of that into an Excel spreadsheet and adding color-codes really isn't going to help a whole lot.
...a how to determine if sensitive data was exfiltrated...
The only way to know definitively if data was exfiltrated includes having a full network capture from the time of the incident.
Also, have you given any thought to sharing your own analysis processes?
I unfortunately forgot where I first heard about "transient" persistence mechanisms, but I later heard the term in a SANS webcast. From what I remember, I'm pretty sure it was something she has encountered at Mandiant. Then again, I could definitely be wrong.
https://www.sans.org/webcasts/detecting-persistence-mechanisms-96090
It's also technique #7 here: https://isc.sans.edu/diary/Wipe+the+drive!++Stealthy+Malware+Persistence+-+Part+4/15460
I completely misunderstood you on the color timeline. I think we're on the same page now.
I agree to definitively determine if data was exfiltrated you need full network data. From the perspective of management, it's my understanding they may need the analyst to determine if it's "reasonably" believed data was exfiltrated to comply with certain laws.
As an amateur with little experience, my own analysis processes won't do much good. Right now I'm more suited to reading your books and asking questions. =)
Okay, I have a better idea of what you're asking for. Thanks for taking the time and effort to clarify that.
Just out of curiosity, are you sure that Autoruns doesn't check the WinLogon\Notify entries?
... my understanding they may need the analyst to determine if it's "reasonably" believed data was exfiltrated to comply with certain laws.
When I was doing PCI exams, I know that unless you could determine exactly which records had been exposed, you had to report on all records. Now, PCI requirements aren't laws, but the state notification laws with respect to PII are relatively easy to check. For example, here is some information I found linked from a university web site.
As an amateur with little experience, my own analysis processes won't do much good.
That's an all-too-common comment, and I really think that viewpoint is not only entirely incorrect, but detrimental to the community at large. The fact is that no one knows everything, and withholding information because you feel that you're too junior or don't know enough simply prevents you and everyone else from developing.
I find that I don't learn as much if I'm being entirely passive...
Wait a minute, you're right about WinLogon\Notify. I guess that Wipe the Drive technique is a little different than transient persistence mechanisms. I just watched the end of that SANS presentation again (1:05:00) and she said she's heard about it, but hasn't seen it. It will apparently move registry keys to the page file, or delete keys when it detects a response tool or certain user activity.
Then a HowTo on determining which, if any, PCI data was exposed would be a good read.
You have a point about being too passive. I was thinking a while ago about starting a blog on analyzing malware. I should probably just put up a disclaimer and try it, but from what I've heard... bloggin' ain't easy.
One more thing. I don't know how many of these HowTo posts you have planned, but if they were combined they might be called the "Windows Forensic Cookbook."
@Anonymous,
...she's heard about it, but hasn't seen it.
Yeah, that makes it a little difficult to do much with.
...a HowTo on determining which, if any, PCI data was exposed would be a good read.
Ultimately, I don't want these to be just "a good read"...I'd like others to add some of their own thoughts. Comments are good, but I can also add things to the blog that someone emails to me, giving them credit, or, if they like, not giving attribution (in the case where they want to remain anonymous).
..bloggin' ain't easy.
I guess it depends on who you are. In my career, both in the military and out, I have been in positions that have required me to write, and sometimes, something like a blog is a great way to keep in practice.
...if they were combined...
That's just it...I already did this sort of thing in WFA 2/e, but most folks either missed that chapter, or just forgot.
I don't want these to be just "a good read"...I'd like others to add some of their own thoughts.
I understand. I kind of suggested adding AV logs, or Windows Firewall exceptions to your program execution list.
That's just it...I already did this sort of thing in WFA 2/e, but most folks either missed that chapter, or just forgot.
Awesome. I've had WFA 3/e for a while. I actually just got the second edition a week ago and haven't had time to read it yet. I'm looking forward to that part now, thanks.
...suggested adding AV logs, or Windows Firewall exceptions...
And I responded to that, thanking whomever (it's hard to tell when it seems as if several folks are posting as "anonymous" without signing their posts/comments...) shared that.
Thanks for purchasing the books, I hope you find them useful.
FYI, I'm currently working on an update to 3/e, and the publisher is considering using 4/e as a test case for providing updated content in near real-time.
Harlan,
First thanks for starting the "HowTo" posts. They are very useful as quick reference based on categories. I love it as it also helps refresh what I read/knew already.
Can you list or talk about program installation. I saw you discuss about it under "Event Logs" section and it is new information that I am going to look right now.
Thanks again.
Lakshmi N
Lakshmi,
Thanks for the comment.
Can you list or talk about program installation.
Sure.
Can you share what you currently do?
Great How Tos and I like the new format - the colored tip boxes etc. I think these will be a valuable resource and make a great check list while working on exams.
I did notice under the Windows shortcuts/LNK files and Jump Lists section it looks like the last sentence got cut off? Not sure if that was the last sentence or if there is supposed to be more after that?
Mari,
Good catch! After all the comments, you're apparently the only one who's actually read the post! ;-)
Sure, I work in private sector and conduct computer forensic examinations on policy violation matters. Why ? Is there an issue ?
Lakshmi,
I'm sorry, I don't follow your question...is there an issue with respect to what?
Harlan,
I was trying to answer your previous question on what I do currently. I had earlier asked you to blog about "Program Installation".
L
Lakshmi,
I was asking what you currently do to go about examining a system for program installation, not what you currently do for work.
Thanks.
As part of examining program installation or execution of setup files, I review the following areas of the registry by running the following regripper plugins,
1. Userassist
2. Appcompactcache
3. Muicache
4. Apppaths
5. Uninstall
6. Review installed apps under Microsoft\Windows\CurrentVersion\App Paths. Do the same under the Wow6432node.
7. do the same by reviewing the apps found under the Software hive and NTUser.dat\software.
8. LNK and Prefetch files that points to the applications launched to access the files.
Regards,
Lakshmi N
Lakshmi,
Great stuff, thanks for sharing. It doesn't look like you need me to write these things up...you've got a handle on it. Now, you just need to share it.
Just FYI...#4 and #6 are redundant.
Post a Comment