TryHackMe | Windows Forensics 1

Date

17/09/2025

Read Time

5 min read

Author

Tom Page

TryHackMe | Windows Forensics 1

Tags

TryHackMe DFIR Windows Registry Explorer EZTools

Article Content

Continuing my journey through TryHackMe's DFIR learning path, I've just finished the first of two Windows Forensics rooms. Unlike the introductory DFIR room, this one finally put me in front of actual forensic artefacts, and I started to see how theory translates into practice. For someone from a software engineering background, this was my first real taste of digging through a system's internals.

Windows Forensics Isn't Just Windows Knowledge

I already knew Windows was the most widely used desktop OS, but what surprised me was just how much of a system's behaviour is quietly stored in the background. The registry in particular was fascinating. I'd always thought of it as this scary place you don't touch unless you're following a tutorial, but in forensics, it becomes a goldmine. Everything from what software has run, to what devices were connected, to what files were recently opened, it's all in there, if you know where to look.

Registry Hives and Why They Matter

I learned that Windows stores its configuration across multiple hives, each covering different aspects of the system (accounts, security policies, installed software, etc.). Accessing these hives offline showed me just how fragile but powerful this information is. For example:

  • SAM Hive: Stores account details, even things like user IDs that reveal whether an account was created by the system or by a user.
  • AmCache & ShimCache: Provide evidence of programme execution, including hashes and full paths, which means you can trace exactly what ran and when.
  • NTUSER.DAT: Contains user-specific activity, such as recently accessed files and applications.

What struck me most is that as a developer, I often focus on logs for debugging. However, registry artefacts are like a deeper log of the operating system itself, often storing details the user never realises are there.

Evidence of User Behaviour

One of my favourite parts of this room was learning how to spot traces of what users had done on the machine. For example, you can find out when a file was last accessed, what programmes were launched (and how many times), or even the password hint set for an account. It felt like piecing together what someone did step by step, rebuilding their session.

External Devices Leave Their Own Fingerprints

I also hadn't appreciated how much information Windows stores about external devices like USBs. Not only can you identify the exact make and model of a device, but you can also find out the last time it was connected. This was eye-opening because in a real incident, knowing whether an attacker used removable media could completely change the response strategy.

Tools and the Learning Curve

I used Registry Explorer in this room, and honestly, the hardest part for me wasn't the analysis but just figuring out how to load the data properly. Once I got past that, I started to see why different organisations use different tools, sometimes, the challenge is just knowing how to navigate the interface. It reminded me of my first time using a complex IDE. It was overwhelming at first, but once you understand the layout, it becomes an invaluable asset.

What I Took Away

  • Windows systems leave far more forensic breadcrumbs than I realised.
  • Forensics isn't just about finding what happened but piecing together the when and how.
  • The registry, once just a scary place to avoid, is now something I see as a structured source of truth.
  • Tools like Registry Explorer have a learning curve, but the payoff is being able to reconstruct user and system activity with surprising detail.

Final Thoughts

Compared to the introductory DFIR room, this one felt much more practical. It gave me the sense that forensics is less about theory and more about patient, methodical investigation. My biggest takeaway was that every action on a system leaves a trace somewhere, and the role of a forensic analyst is to know where to look and how to interpret it. I can already see how this mindset could apply back to my software work, systems don't just fail silently, they usually tell a story. You just have to be willing to dig.