(Yes that title is supposed to read like the “Hitchhiker’s Guide to the Galaxy”, but it’s a lame attempt to be funny. After your read this blog post, you should head on over to amazon to buy the book.)
I asked one of my professors in college “How do I be successful after college. I seem to be struggling with things my classmates are not.” His response was simple: “The fact that you’re standing in my office means you’ll be successful. You’re passionate.” I started out my career in Digital Forensics right out of school. I was lucky enough to attend a pretty awesome college that had an undergraduate degree in the subject, but in actuality, most of what I learned was all self taught. I wanted to write a blog post to help others figure out where to start.
Something that I’ve learned is that it’s really difficult gain practical experience until I have hands on experience. I did this two ways: I built my own images - this requires some experience in exploitation (For this I utilized Kali Linux), or l used old CTF challenges, or dummy images that are on the internet.
Here are some links to get you started. Disclaimer: None of these are mine, and I can not vouch for what is on them. So proceed at your own risk.
Now, once you identify which images you are going to use for practice, we have to understand how to tackle a case. When I was interviewing for my a previous job, it was recommended that I read Computer Forensics and Incident Response to educate myself a little bit more of how cases are actually worked. This is not something they taught me in school. Sure, we had classes where we talked about Attack Lifecycle , Cyber Kill Chain, and ATT&CK, but what wasn’t taught was all of the other things to look for evidence wise. And that's what this book outlines really well. It gives case studies from the actual cases and the authors explain in great detail how they came to those conclusions.
Breaking things down into the life cycles of an attack is helpful to understand what was able to occur. But as much fun as it is to dig through what the threat actor was doing on the system, its most important to keep a few things in mind at the very minimum:
- What was the time frame the threat actor had access to the system? And did they they obtain access/deploy any persistent mechanisms?
- What did they have access to during the time they were connected?
- Did they exfiltrate, view or delete any data that would be considered sensitive.
I'll wait until you order that book, and get through the entirety of it before we continue....
Oh good, you're back! Now, we learned about how to attack a case, we’re ready to dive into more of the fun stuff. Let's talk about artifacts. Virtually everything that happens on a computer, leaves a trail. However, some threat actors are more advanced than others, which is what makes forensics fun! But we’re just going to focus on the basics now. Let’s start with windows. I’ll do a post on Linux later, and if you want to get SUPER fancy, head on over to Sarah Edward’s website to learn about Mac Forensics. I'll leave that one to the experts (for now anyways).
But now, for the main event. Let’s talk about some artifacts! We’ll get into tools in a bit as well. But for the most part, this part is generally just there to start your curiosity.
Okay, I lied - One last thing. The most important thing about investigations - TIMESTAMPS. It's imperative that when you're learning about different artifacts, you pay close attention to the types of timestamps are associated with each artifact.
Okay now on to the main event.
I will be focusing on a few different logs this blog post. Some of them are pretty straight forward and taught in most schools, and some are not. Here we go. Generally, these are found in the C:\Windows\system32\config directory. There is a lot to learn about event logs, so I’ll just be scraping the surface. I would suggest you read up on them if you REALLY want to get your hands dirty. Here's a great starting point.
Security Logs - Security.evtx Logs are the go to logs for forensics analysts - as well as threat actors… They’re probably the first to go, maybe only second to the system logs. We’re really interested in Event IDs 4624 and 4634. These Events signify a logon (4624) and a logoff (4634). These events carry a plethora of information about the session. Some things that you should look into are: [table] Logon Type (mostly type 3 and 10), Source Network Address (Source IP), username (), Session ID.
Terminal Services Logs - This log file is probably my favorite. Especially when it comes to cases with unauthorized access. Terminal services Local Session Manager will give you all information in relation to interactive logons. In this instance, we’re really going to be interested in the event IDs 21-25.
21 - Session logon succeeded
22 - Shell start notification received
23 - Session logoff succeeded
24 - Session has been disconnected
25 - Session reconnection succeeded
I’ve come into contact with some systems that have had their Security Logs wiped, but their Terminal Service logs are still fully intact. Those days are the days we like.
System Logs - System Logs track everything that happens on the system. However, because of that, there is also a high risk of the threat actor deleting them. If they haven’t “rolled” (the allocated storage is too small, and thus there is a short timeframe worth of logs), or they haven’t been deleted (Windows 2008 and up - Event ID 1102, Below Windows 2008 - Event ID 517), you can identify if there were programs running or when services were started - again, those days are the happiest of days.
Application logs - Application logs track, you guessed it! Applications. If you’re looking for things like Logmein or Teamviewer ( remote control tools) running when they’re not supposed to be, you can sometimes catch it here.
Powershell logs - Powershell logs have saved my case a few times. Sometimes, the client that you’re working for will have logging turned on for powershell. It’s always worth it to check if there’s something there, but it's not as easy of a win as the rest of these logs. Powershell v3+ has incredible logging and has 100% saved cases for me before. Check out some additional capabilities Powershell logging has here, because Module Logging, Script Block Logging and Powershell Transcription are really baller.
Additional Windows System Artifacts
$MFT - The MFT can be used in triaging events. For lack of a better term. this is kind of like the Table of contents of the system, in the most simple explanation. It can provide a lot of value during an investigation/response of a windows system(s). You can “timeline” the creation time, modified time, and accessed time of artifacts on the system using the MFT to identify any malicious or associated files on the system at the time of collection. Something to research for your self is the concept of resident files vs non-resident files, and also understanding all of the file timestamps that are within the MFT - I'll give you a hint. There are more than 4.
$UsnJrnl - The good ol' NTFS $UsnJrnl volume change journal. This, if the system you are analyzing has a relatively large $UsnJrnl, you can obtain information about when files were opened, closed, written over, and even deleted!
ShimCache - Shimcache is such a cool artifact with a really cool history. This artifact give some additional insight into what was executed on the system, but it does have a limit, so when new data gets created, it over rights the old data, or "rolls" the data. The caution that I would throw to the wind is that this artifact only captures the last modified time. So just keep that in the back of your mind when you're building out a timeline.
AmCache - Amcache, much like Shimcache provides insight into what was run on the system. However, Amcache goes much deeper - it gives you recent processes that were run, the paths to files that were run, as well as the SHA-1 hash value of most items. As you can probably imagine... Hash values are huge when it comes to investigations.
Registry Keys - There are so many registry artifacts, and honestly they may get their own dedicated post. But for now, read up on it here. But in the system registry you can find information about services , software installed, OS information just to name a few. There is also the user profiles that provide a lot of insight about, again, you guessed it - the user!
Tools I'm fond of, and are also free/open sourced!
Collecting artifacts - Bambiraptor is a really cool live response collector that you can use in a pinch if you don't have the time or capability to collect a full image.
Exporting artifacts - FTK imager - this is great if you have an image or a live response package created by a FTK it's self.
Event logs - Using Powershell, or something like Event Log Explorer (Paid, but free trial) or Event Log Parser, which is native to Windows.
Amcache- amcacheparser.exe (Eric Zimmerman) or amcache.py (Willi Ballenthin)
Usnjrnl - NTFS Log Tracker, by Junghoon Oh
$MFT - MFTdump.exe by MalwareHunters.net or MFT2CSV by Joakim Schicht
Registry Hives - Regripper by Harlan Carvey, for wholistic view of the registries.
Shimcache - ShimcacheParser by Mandiant, or AppCompatParser.exe by Eric Zimmerman
Shellbags - ShellbagsExplorer by Eric Zimmerman
Now there is a lot of information in here, especially after reading that book. You now have some really great places to start your research. I'll be back soon with a similar write up on Linux forensics.