This book has popped up on a few posts around here, looks like Mandiant is doing a Fresh Prints webinar featuring info about the book from the authors as well as a 40% off code to purchase it and a free chapter for review. They will also be featuring a new free tool called FakeNet, which I assume is a sort of Sandboxing environment.

So quick review of the book so far... I like it. It is very informative and it is pretty easy to follow. I am not that far into it but it does a good job covering some of the preliminary stuff. The book did not come with the DVD but if you were listening to the Webinar, they did make the labs available on their site:

Also on the Webinar, they went over using their new tool FakeNet. You can load it on a standard XP install and run it similar to WebGoat. It will load a dummy site as well as respond to DNS requests and even serve up requests for files if the malware is looking for such things. The DNS works similarly to FakeDNS or ApateDNS.

Knowing a bit about programming can always help you but it is not a requirement. If you know programming concepts, it should be enough. You do get a primer on Assembly. The deeper you go into the analysis, the more assembly you will need to sort through, then if you get to a higher level of reverse engineering, you are doing much more disassembly than before.

Jamie.R wrote:Cool so would you say this book is good for someone who has never done any malware analysis ?

I've been reading about malware analysis for a while, but this is the first time I'm actually putting it to use. The book starts off easy and gets more technical. I'm on chapter 17 and have done a few labs and so far it is easy to understand, except for chapter 15 on anti-disassembly. That was tough for me.

I'd say it's a good book to start off with, but it can't teach you everything about malware analysis. You will probably need to supplement it with google searchers, questions of forums, and by reading other malware books.

It worked out for me since I had some HBGary Responder Pro training 2 weeks ago before RSA. So I was already through an Assembly primer. Malware analysis comes in a few levels. Your analysis for Incident Response will cover the first 2 levels, the What's and where's of the analysis. Here is the suspicious file, here is what happened after the file appeared and where it might be hanging out. Then there is the deeper dive, what mutexes it left behind, what system processes were involved and what other files did it drop. Then full on reverse engineering to write stronger signatures for IPS and AV. First two levels are the fastest to process in order to respond quickly. The rest require much more time and effort but are the long term fixes to prevent future outbreaks and even do some forensics on the malicious items to determine where they may have originated from and who might have created them.

I would say to become that level 4 reverse engineer, you would need to have a very strong understanding of Assembly. But I wouldn't make it your focus. You can get a lot from malicious software when you toss it into a sandbox for behavioral analysis. If the malware has VM awareness, you will then need to perform a deeper analysis using more advanced tools that will certainly involve looking at the assembly. I am currently finishing off System security section of eCPPT (reason why I haven't gone deeper into the book). And the last 3 modules of that section have involved assembly. The reason being is that you take advantage of the calls in the windows DLLs (kernel32.dll) to initiate your shellcodes. So tossing a file into a disassembler and looking for certain process calls or data moves is key to writing a decent piece of shellcode. Its also how you determine where an exploit might be possible. In the reverse, it is how you can determine what a decent piece of malware is doing to the system if it is exploiting an unknown windows flaw or taking advantage of a process that Office is calling. Pretty much all those "Remote Code Execution" flaws we see in the Microsoft Security updates.

Once I get through eCPPT, I will probably try to keep fresh on the assembly and go through the primers. The more you work with it the better you can get. I'm certainly not going to try and write an OS but being able to tear down malware to the assembly level will be handy skill when I am researching from my forest retreat staring out over the mountains ok that is wishful thinking about the mountains and such.

I think the more coding you know when dealing with malware, the better reverse engineer you can become. If that is your goal. It is a great skill to have and probably rewarding if you are in that tier 3 or 4 level of reverse engineering.

3xban wrote:I'm certainly not going to try and write an OS but being able to tear down malware to the assembly level will be handy skill when I am researching from my forest retreat staring out over the mountains ok that is wishful thinking about the mountains and such.

++1

~ hayabusa ~

"All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved." - Sun Tzu, 'The Art of War'

YuckTheFankees wrote:To become a great malware analyst, do I need to know how to read assembly language or actually know how to program in assembly language. Kind of the same question for C++ as well ?

It all boils down to what you want to do at the end of the day. Understanding Assembly helps and you WILL NEED to understand enough for performing static analysis however, the reality is... Unless you're doing it at the hobbyist level, most of the times you wouldn't need to go that far and I will explain why...

When malware infects an environment, the goal is often containment, eradication and analysis. For the most part, containment and eradication come first followed by analysis. In many arenas, you won't need to go that far in depth into analyzing from a reversed perspective. When you DO need to go this route, it is usually because something was specifically targeting you. Reversing on this scale is EXTREMELY time consuming.

Large companies and many in the gov/mil space use tools like Norman Sandbox, FireEye, etc., this drastically reduces the amount of time an analyst will spend on these things. You need to remember, time is ALWAYS money at the end of the day. So unless you can beat a machine, you're up poop's creek trying to race some of these sandboxes.

Most of the things I do when reversing come from a hybrid analysis perspective. Meaning I am performing both static and dynamic analysis' and comparing the differences. Its rare that I will go as far as dumping something in IDA pro as it is not going to yield me anything I couldn't obtain otherwise. I am not making an AV/AntiMalware signature, so little is to be gained from reversing where I can simply throw a memory dump into strings and find the same data.

So, to answer your question... You should learn Assembly for the sake of understanding as much as you can since it obviously helps however, you DO NOT NEED to learn Assembly from a programmers perspective to be a good malware analyst most times. (NOTE THE WORD MOST TIMES) It all boils down to your environment.

YuckTheFankees wrote:To become a great malware analyst, do I need to know how to read assembly language or actually know how to program in assembly language. Kind of the same question for C++ as well ?

I'm sure to be great you would have to understand assembly. When you're analyzing malware the assembly is already there so you don't really have to know how to write assembly, just read it. However, to be great in malware analysis, or security in general, you would have to know how to program in a high level languages like C++, Python, etc.