We verify our forensic tools, right? And once we verify them, it’s all good? But what if the application is lying? Is the forensic tool right or wrong? I was playing around with HTTP/2 to see how the protocol works. A more detailed post examining HTTP/2 is forthcoming, but as usual I went down a rabbit hole and ended up…well, writing a Chrome bug report. But I’ll take a few steps back.

There are many ways to categorise forensic artefacts. Probably the best known (and well put) is the SANS Windows Forensics Analysis poster. This poster lists artefacts by the formula of ‘Evidence of…'. It’s a great reference and training tool. But could we look at forensic artefacts differently? And why should we? By categorising data differently, we can look at problems differently. Solving complex problems is a significant part of our work.

I have a confession to make. I am part of the CyberChef cult. When you join a cult you find yourself saying things like, “Woah! How come I didn’t know about this before?” and “Where have you been all my life!” You also spend a lot of your time proselytising to other, random people about your ‘fantastic’ new life. However, most cults take your time, soul, and money, and only give you a glass of Kool Aid in return.

In my previous post I used Volatility to examine a memory image from a hypothetical Tor user accessing webmail, the internet, and a Tor hidden service. From that analysis I could ascertain with good confidence a user of the operating system connected to the Tor network from a USB on drive E:. In this post, I will continue with the same memory image but see what additional information can be revealed from data carving tools.

Memory forensics is a powerful tool. All executed code and data passes through RAM which makes it perfect for hunting malware. Most discussion on memory forensics is focused (rightly) on malware analysis, and the benefits of memory forensics for non-malware scenarios have been less publicised. Often, a lack of understanding of the benefits of memory forensics has pervaded internal investigations or law enforcement. There is a tendency to think, “we’ve got the whole box, so why would we need the memory?

Hello! This is the beginning of my digital forensics & incident response blog, bit_of_hex. This blog is born of the philosophy that everyone in the DFIR space has something to contribute, at any level or area within the community. I also realised that I have benefited for so long from other people’s research and effort that it was time I gave something back. Many times when I have searched for that particular forensic artefact or obscure problem I’ve found someone who has taken the time to publish their own research.