One of my more recent cybersecurity projects was a “black box” test where a virtual environment had experienced some type of “cyber incident,” and our team was tasked with securing the environment, diagnosing (and eradicating) the compromise, and hardening the systems against further compromises. I may go into more detail about this specific project in a later blog post, but one of the facets of the project that I found the most fun was the digital forensics part of it. After we had found the initial compromise (a Remote Access Trojan that had been spread among several machines, in this case), we needed to figure out how it initially got into the system. We had no budget, which meant most automated SIEM tools were unavailable, and our forensics mostly involved digging deep into individual computer event logs and trying to piece together a timeline. It may sound a little tedious (and, indeed, there were moments when it felt like a futile effort), but I actually found it fun to come up with theories, cross reference Event IDs, and nail down when certain moves were made and on which systems (Of course, if you have a good album to help you get in the zone, that certainly helps). I’ve always enjoyed troubleshooting and fixing software issues, and this phase combined that aspect of the project with an almost detective-like process of establishing a timetable. At a certain point, we were able to outline almost all of the actions taken on several machines over a crucial few months when the data breach had occurred.
It occurred to me recently that there are probably a variety of digital forensics challenges and examples online where I could practice and refine my techniques, so today I really quickly googled “practice digital forensics” and, boy, was I right! I decided to do a really quick exercise that I found through the Digital Forensics Association (found here), which I will share below.
The scenario was pretty basic: a teacher suspected that a student was sending her harassing emails. A packet sniffer was setup on the local wifi and run for a period of time, during which the teacher received an “auto-deleting” email from a website designed to anonymously send emails.
I downloaded the provided pcap file, which I then loaded into Wireshark. The website that sent the email no longer exists, but I was able to simply search the DNS records in the pcap file for the website’s IP address.
After that, I searched through the interactions with that website’s particular IP until I found the HTTP POST request (amusingly, none of the traffic was encrypted and the website did not run https).
At that point, I had the smoking gun, which you can see below.
For extra authentication, I backtracked and found the most recent ARP request for that computer’s IP address, so I could verify its MAC address against the one used to make the HTTP POST (that packet, of course, also contained the computer’s MAC address). Had this occurred at an actual school, all we would’ve had to do at that point would be to inspect the students’ computers and find the one that matched that MAC address (we could either confiscate the computers or just try some nmap scans, if we wanted to remain stealthy about it until we made an accusation).
Obviously, this was a pretty simple exercise — all told, it took me less than ten minutes, but it was a fun little diversion, and I will definitely be checking out some of the more complicated scenarios online in the future. For the less cybersecurity-minded readers, I hope this exercise demonstrates the very basic need for encryption when you’re on the internet — without it, everything you post is available for anyone to see, if they put in just a tiny amount of effort. (It’s also a pretty good reason why you should be wary of public WiFi networks.)
Do you have any favorite resources for practicing digital forensics? What do you like to do to keep your cybersecurity skills fresh? Share in the comments.
