Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software

This book is surprisingly easy to read and very informative - if you have an IT background. It is not, however, a book for beginners.At the very least, you must have a working understanding of Assembly language and the x86 architecture. With little exception, almost all advanced analysis occurs at the assembly level. The book does not spend time teaching assembly. It jumps right into the assembly code and takes off running. If you do not understand assembly code, don't even bother picking up this book (or attempting to be a malware analyst).Secondly, you will need to have a solid understanding of the C programming language. Much of the assembly code you will be analyzing originated from a disassembled program originally written in C.Your main home computer is not ideal for analyzing malware. In many cases, you have to actually run the malware to see what it does.Therefore, a virtualization environment is preferred. Unless you already have access to a virtualized lab, familiarity with VMware (or equivalent) is very helpful for setting up your own lab.Experience with the Windows API, registry, DLLs, and basic file structure is also helpful. All of the sample malware is tailored for Windows computers. There is an entire chapter on the Windows API to get you up to speed if you only have a basic knowledge.Basic knowledge of Linux is also helpful. There are a handful of analysis tools that are Linux based. You will need to have at least one Linux (virtual machine preferred) to perform some of the labs.A basic understanding of TCP/IP networks is also good to have. Many of the malware files have a networking component.Lacking any of these skill sets will make reading this book very difficult.The best parts of this book are the labs at the end of the chapters. You will work on actual malware (slightly modified to be less dangerous) using tools and techniques learned in the corresponding chapter. The labs guide you through important parts of the malware, and there is a detailed explanation at the end of the book describing, in detail, how the malware does its thing and how you, as the analyst, can discover its secrets.Most of the tools used in this book are widely available and free to use. A whole chapter is dedicated to the main tools so you get extra exposure to the important software you will be using as a professional analyst.

Before I begin, I have to disclose that I am a Mandiant employee, but I don't work directly with the authors of this book, nor do I have any sort of personal relationship with them. I have also published two books with No Starch Press. While I don't analyze malware exclusively for my job, I've done a fair amount of it as an auxiliary function of my work mostly focused on network security monitoring. I've also taken the SANS FOR610 Reverse Engineering Malware course and am GREM certified. I'd consider myself an experienced, but not expert level malware analyst.With that said, Practical Malware Analysis is one of my absolute favorite information security books. The topic of dissecting malware can be very daunting, as it requires a broad array of knowledge to be done effectively. You have to be able to interpret code, have a knowledge of internal system workings, and be able to read between the lines using an analysts intuition. I think this book does an excellent job relaying these concepts.PMA begins simply, starting with basic static and dynamic analysis. This also includes a discussion on setting up a virtual malware analysis lab. This is often enough to determine if a file malicious on its own. After this, the book quickly jumps to more advanced static and dynamic analysis concepts. PMA covers a wide away of topics, and touches on most every aspect of dissecting modern malware. If you are a beginner, then you will get plenty to sink your teeth into without feeling completely overwhelmed. If you are more experienced, you will find plenty of coverage of advanced topics, such as dealing with malware that has built in anti-debugging features.My favorite portion of PMA are the labs included with almost every chapter. The authors have taken the time to write custom "malware" and find existing malware samples that accompany each topic. These allow the reader to try out the skills they've just learned and then compare them against a set of answers in the back of the book. I wish more books did this.I work from home, and at my house I have a big bookshelf in my closet and a smaller bookshelf next to my desk. The books I've read that I don't use often are in the closet bookshelf. The books I've read that I use really often stay on the smaller shelf next to the desk. Not only does Practical Malware Analysis sit on the smaller bookshelf, it sits on the top of it along side such greats as "TCP/IP Illustrated." I think that is the best praise I can give a technical book.Simply put, If you want to learn how to analyze malware at a casual or advanced level, then PMA is THE book to purchase. Kudos to Sikorski and Honig on a job amazingly well done.

I've been working through this book over the last year and I love it. It's well-written and the format of the exercises is great. You work through a bit of theory and explanation, go through a practical exercise and then you're told to explore an executable on your own and answer some questions. The back of the book then has author-provided answers to help you get all the answers you should have.I had some experience with assembly and C/C++ already but nothing at a professional level. My primary lack of background was in networking but the author explained enough to at least tell me what to Google for when I needed more information.There's a few typos but nothing I wasn't able to figure out on my own. Luckily, the publisher is tracking these and lists them here for you: http://www.nostarch.com/malware#updates.Personally, I recommend running VMs. Set up an image with all the labs downloaded and saved somewhere. You'll want to revert to that snapshot before moving through the labs to ensure you're not mixing up potential system changes between labs. Sometimes, I like to go back to previous labs so I either saved snapshots after doing the lab or saved my altered binaries to a USB drive so I could reference them after reverting to the original snapshot.