Earlier this year, I wrote of my long love affair with Ruby coming to an end and my desire to get back to python in order to build additional skills for the purposes of defense and response. That first step back into python resulted in the article, Book Review: Gray Hat Python by Justin Seitz. That book was one of the more interesting ones that I’ve reviewed, so when I had the opportunity to look at his latest work, Black Hat Python: Python Programming for Hackers and Pentesters, I was really excited.
Python has been the language of choice in the pen testing universe for a while now, and so having a good reference for building attack and analysis tools for use during attack exercises is really important. The back cover of the book ponders the question of how the magic of creating these tools happens and offers that, “…you’ll explore the darker side of Python’s capabilities—writing network sniffers, manipulating packets, infecting virtual machines, creating stealthy trojans, and more.” Sounds perfect. Let’s take a closer look and see if it delivers.
After a long love affair with Ruby, I was excited to get back into more Python in the new year. One of my main goals was to build additional skills with Python, and continue to build up skills in defense and response. When “Python Forensics: A workbench for inventing and sharing digital forensic technology“ by Chet Hosmer came out, I was excited about all of the possibilities. There are a number of books about using Python for attacking, but a strong book on building forensics tools is a nice change of pace.
Python Forensics target audience is “anyone who has a desire to learn how to leverage the Python language to forensic and digital investigation problems.” Hosmer hits the target audience well by both having introductory sections that go over some Python basics as well as a number of cookbook-style chapters that have programs to perform a number of different forensic functions. Let’s take a closer look at this Syngress Publishing title.
It’s a Thursday evening, and happy hour begins in a few minutes. You’re ready to get out of the office, as quickly as possible. You’ve been working on a report, and you know you still have work to do in the morning. So you lock your machine. It’s safe enough, right? You’ve got a strong password and full disk encryption. Ophcrack or a bootable Linux distro like Kali won’t work. You’d think you’d be fine, but you’d be wrong. More and more, attackers are using blended attacks to get the good stuff, and that includes utilizing the latest in forensic techniques.
There is a single section of your computer full of unencrypted sensitive information any attacker would love to get their hands on: your active memory. The system stores all manner of valuable information in memory for easy reference. Full disk encryption mechanisms must store encryption keys within memory somewhere. The same is true for Wi-Fi encryption keys. Windows keeps the registry hives in memory, and consequently the System and SAM hives. Most clipboards are stored within memory. Many applications keep passwords within memory. The point is, memory houses much of the valuable information that the system needs at a moment’s notice. Getting to it requires using some of the same forensics techniques employed by attackers. This article helps add some of those techniques to your pentesting toolkit.
By Todd Kendall
Security professionals are often tasked with the unenviable position of wading through millions of bits of data, the review of thousands of systems, or the evaluation of hundreds of applications. At the end of the day it is their job to provide the ten thousand foot view of an organization and the highest rated findings that put it at risk. Information overload is a common theme in today’s society, and management requires the presentation of this material in a digestible manner of typically one page or less. The ability to provide this service requires what is often referred to as “seeing the forest for the trees.” In other words, don’t get distracted or bogged down by the minutiae of your discoveries at the risk of overlooking the big picture.
When it comes to computer forensics, however, the tables are flipped. When an event turns into an incident and management must answer to a board or the company’s shareholders, the ten thousand foot level is no longer adequate. At this point, every packet that ever crossed your company’s domain becomes suspect, and expectations are set whereby the answers to the questions such as, how did it happen, what damage did it do, where did it come from, when exactly did it occur, and who did it, requires the puzzle to be unraveled and presented in such excruciating detail it would make Melville take up skim-reading.