UPDATED: 28SEP2012 – I finally got around to taking the test 7 months after I took the training. Yes, I had to purchase an extension, which I am actually grateful that SANS offers.
Drum roll…..”I passed!”
——–break———
Caution….it’s long….and a bit late. I started writing this on the plane back in March while I was coming back from my training course. I was going to wait and post this after I took my certification, but figured some people might get some use out of it, so there really isn’t any reason for me to wait.
—-Original Post from the Airplane—-
Ok, now that I finished up SANS FOR610 – Reverse Engineering Malware on 29MAR12 I decided to start a review of the course. I have nothing better to do at 31,000 feet (airplane wifi rocks) – So does free first class upgrades, which makes me writing this possible. Thank Delta, not me.
Disclosure: I am not affiliated with SANS. I don’t really know any of them personally, and I am not being paid, receiving discounted tuition, etc. for writing this review. The only relationship I have with SANS is that my blog is on their @sansforensics twitter blog roll, and I was mentioned in one of their case leads posts. Neither of those items impact my decision to post this nor does it sway my decision to write it.
My review is based off a non-seasoned malware analyst (me). Now that we have that out of the way let’s get started.
How was it? It was intense for me, but at the same time it was awesome. I had to have a beer each night after class to get my brain back to normal. It was a lot of information covered each day, and there wasn’t any wasted time during the sessions. I’ll try not to waste yours here.
Day 1: Malware Analysis Fundamentals
We didn’t waste much time on Day 1 jumping into things, which I found to be really nice. I’ve taken SANS FOR408 before as well and it was similar. Jump right in and get learning. I hate the 1 hour intros that a lot of other training vendors do. That’s what coffee breaks are for.
We went over malware analysis fundamentals like the title says. We focused on a piece of malware called, Tnnbtib, which uses IRC as its communication mechanism.
To kick things off we went over a standard virtual lab setup, and discussed the pluses and minuses of various configurations. We discussed to pros and cons of using VMWare, Physical machines, Physical machines with DeepFreeze, etc. For the course we used VMWare and an installation of Windows XP. This is what I use at home, but I typically use Windows 7.
We also examined the registry and file system interactions of Tnnbtib by way of Procmon and regshot. We also used CaptureBat. I knew about these tools prior to the course so this wasn’t much of a learning experience; however, for those folks out there that simply use Encase/FTK for everything might get some use out of these tools. It actually requires some “hands-on” experience, and some sorting through lots of noise to get at the valuable data. It requires you to know something about how the system runs.
We also looked at gathering network details. We used wireshark for this step so we could see the network traffic. We setup Wireshark on our REMnux box and then configured the /etc/host file to resolve to our REMnux box, which enabled us to see the Tnnbtib traffic coming/going. This was pretty neat to kick things off.
After the behavioral steps we went into the code analysis portion of day one and used bintext to look at strings of the tnnbtib malware sample for “interesting” strings. We also used IDAPro, and OllyDbg in order to get a brief look at assembly. One of the things I found interesting was running strings through a deobfuscation script. Prior to this course I didn’t think much of it. I would run bintext and read whatever came out and say, “hmm…it must be encrypted or something”. In the course Lenny provided a perl script that did some deobfuscation for us: strings srvcp.exe | mydecode.pl, and then we were able to decipher many more strings that proved to be useful during the analysis portion.
We went over unpacking the file by way of UPX native unpacking (-d). After unpacking there were many more strings which continued to add to our collection of intelligence for this piece of malware. We did some more code analysis that revealed a login routine in OllyDbg , and we proceeded to patch it so it would accept any password supplied, which then enabled us to authenticate to the IRC channel and run commands as if we were the malware owner.
During day one we also went over, “general malware knowledge”. Websites were provided to us, reference material that included books, etc. was given to us so we could go online and purchase them for further study after the course. We also configured our labs.
In the end we learned a good amount of information about tnnbtib.exe. We were able to gain control of the malware, went over high level reverse engineering from a code level, used a myriad of tools. Most of which you can find listed here. Towards the end of the day we had enough time to go back and do everything ourselves. It was really nice to get the verbal overview, and then go back and validate what we learned to bring it full circle.
All and all it was a good first day and we covered a lot of material. It was jam packed and we went the full time frame.
Day 2: Additional Malware Analysis Approaches
On day two we jumped right into patching. Nothing like a morning cup of coffee while we discuss packed executables to get the brain jogging.
At the start we went over at a high level about why malware authors pack their files, how they pack them, and the different type of packers out there. We focused mainly on UPX as that seems to be the most widely used packer at the moment in the wild.
We talked about PEiD, which is a tool that’s programmed to recognize packing signatures. I’ve used it in various examples on my blog if you care to look. It’s free and you can download it and try it out yourself.
We also discussed LordPE, which is a tool that allows you to run a process and then dump it. I find this not to be very useful because malware seems to kill their originating process rather quickly before you have time to dump it. I find that dumping it via Volatility is better, especially with the ability to suspend VMware instances almost instantly. That’s just my personal preference.
We also discussed how to unpack malware using OllyDbg. I used what I learned to do the unpacking in this post (look towards the bottom where I use OllyDbg).
I would say the first half of the second day was used to cover patching exes, the mechanics of packed exes, going over LordPE and PEiD, using OllyDbg to unpack an exe, and that’s about it.
The second half we talked about IP traffic. We used Honeyd on our REMnux machines. We discussed how to setup a Web server emulation on honeyd, talked a little bit about the honeyd configuration, and then we took a look at a malware sample called, DoomJuice.
We also did a few hands-on exercises to bring things full circle.
After all that fun stuff we discussed browser based malware, specifically flash and java. We talked about how these types of attacks are carried out, how we can utilize tools like wget, curl, and HTTrack, to grab the malicious files from the web. We discussed how to spoof user agent strings with wget in case the malware authors setup some defenses (Koobface is an example of this). I found this to be very interesting as I haven’t done much web based malware analysis.
Lenny also provided us with some neat tools on REMnux that make spoofing the user agent really easy. We discussed the importance of using TOR to go in covertly and grab malware as well. Note: don’t do this from your office IP space.
We talked about script encoder/decoders, obfuscation techniques and reversals, hands-on labs, etc.
All and all day two was jam packed with a lot of information that will have you retreating to your hotel room only to keep looking over the material and opening the mini-fridge to pull out a couple beers.
I could have kept typing another two or three paragraphs here, but you get the point. It’s a lot of great information. If you want to know if something specific was covered drop a note in the comments and i’ll go back over my material and let you know.
Day 3: Malicious Code Analysis
So on Day 3 we dove into code analysis. We started the day going over the core reversing concepts. By core reversing concepts I mean, a 15,000 foot view. What is a compiler, linker, and loaders. What is the code life cycle, functions, inline functions, data structures, variables, etc. It was a nice primer for the non-coder types (myself). On the first day Lenny asked what most of us used for analysis. The majority of people preferred behavioral analysis. I’m assuming this is the common answer. I think it provided a nice overview.
Next we started looking at Assembly. We discussed registers (general/special use), what makes up a register, direct and indirect memory addressing, various instructions like, JMP, MOV, LEA, CALL, etc. We talked about conditional jumps. We went over some C/C++ code so we could see what it looks like in assembly: If-Else, If-ElseIf-Else, Loops (for, while), and a few more examples. We went over the various calling functions, clearing/swapping, math functions and that was about it for the assembly primer. We also discussed a little bit about anti-disassembling techniques.
On day 3 we also talked about rootkits. We kicked that section off by talking about usermode. We had a quick overview of what rootkits are, how they work. During the usermode section we talked about hooking. We didn’t specifically mention it in the course that I recall, but the descriptions we went over were essentially IDT, SSDT, etc. hooking. We also went over a bit of assembly code that might depict this happening. Specifically some of the API calls we discussed were GetWindowThreadProcessID, SetWindowsHookEXA, WriteProcessMemory, VirtualAllocEx, and some others. DLL injections covered a solid 10 pages or so. We also talked a bit about Kernel level rootkits. DKOM, how processes are hidden, how they modify FLINK and BLINK or hide processes from something like task manager.
Lastly we talked a bit about sniffers, key loggers, and HTTP channels. We also had a few hands-on exercises, which were fun.
That was pretty much it for day 3. It was pretty intense. We covered a lot of technical information. Especially for the non-coder types.
Day 4: Self-Defending Malware
Day four was pretty intense. We kicked the morning off right away talking about packers. We talked about how to identify packers by using strings. We specifically talked about how some of the packers leave behind traces. For instance, Themida might leave some strings like; aPa2Wa or WD}W. UPX might leave something that says, “UPX”. There were some others we looked at too. We also went over PEiD scanner, pescanner.py, Pyew, RDG, and Protection ID. Basically the first 15 pages or so were discussing how to identify what packer you’re up against.
After the identification phase we talked about manual unpacking. We talked about structured exception handing (SEH) and looked at OllyDbg to see what they looked like. We talked a bit about locating OEP, how to set breakpoints, dumping processes, rebuilding dumped exes, etc. We talked a brief moment on automated unpacking via Olly scripts, AllUnpack, Faster Universal Unpacker Tools, but the consensus was not to rely on them.
In addition to the malware defenses we discussed an equal number of ways to counter those defenses. At this stage it was pretty much over my head. I don’t have a lot of experience manually unpacking malware or circumventing their defenses. After talking with some students during break they also were lost around this stage. Note: That’s not a bad thing…
On day 4 we also talked about obfuscation/deobfuscation of Javascript, and various kinds of web based malware. We took a look at some of the tools used for web analysis. SpiderMonkey and some other tools. I would say there was a solid 100+ pages on web based malware. They also provided multiple custom perl scripts to help with obfuscated code, search via regex and other examples towards the back of the book.
Day 5: Malicious Documents and Memory Forensics
Note: I had to leave about two hours early because my flight was changed. I did go back through the books and cover the material I “missed”.
We started off the day taking a look a PDF malware and discussing the PDF file format and also touched on the file structure of PDF files. We looked at indirect objects and references, compression of streams, and some other items as well. We also went over some of the important PDF Keywords, which I liked, because I didn’t have a lot of experience with PDF documents. It was nice to understand them before we started using tools like pdfid.py. Since we went over the keywords before hand we could understand the output of the tools we used, rather than just executing a tool and saying, “cool”….now what. We could see that /RichMedia can be used to embed flash in a PDF file, etc. This brought it full circle at least for me it did. We touched on keyword obfuscation too and how we can’t just assume the malware author is going to put /Java in their code.
We discussed various vulnerabilities that are seen in Adobe Acrobat Reader, and specifically discussed how a lot of vulnerabilities have been discovered as a result of bugs in its SpiderMonkey-based JavaScript interpreter.
We also discussed how code was executed via PDF files, and how the embedded shellcode executes after exploiting a vulnerability. After that we talked about how Heap Spraying is a technique that’s used. We discussed what a heap was, what heap spraying is, how it’s done, and also talked about the various methods of spraying the heap. These were high level overviews as the intent of the program isn’t to teach you how to author malware.
The PDF tool discussion was nice too. We were able to use Didier Steven’s PDF tools, the Oragami PDF framework (for the Ruby lovers out there), Jsunpack, SpiderMonkey, and some others. Most of the items we went over were command line and we used the REMnux OS that is provided to the students on the first day, and also can be downloaded from Lenny Zeltser’s website.
I really liked the example we went over with examining a PDF object using pdf-parser.py. We took a PDF that contained a stream within an Object. We then decompressed the stream using the –filter command, supplied the –raw command, and then did a > out.js, which was cool to see the actual java code extracted into a javascript file, which we then proceeded to review using notepad on REMnux.
We were also provided some custom tools on REMnux that assisted with extracting shellcode from a pdf file, which we could then use a couple other scripts to get a useable .exe file that we then used OllyDbg to walk through the exploit and decoded the shellcode that was extracted from the malicious pdf file.
I want to say it was a solid 3 hours on PDF analysis using various tools. I only touched on a few. You could walk out of there and feel comfortable about looking at PDF malware and if you couldn’t understand it, at least understand enough about the process to ask other people, or look online for more information.
I wont go over the Office Document malware section much because it pretty much followed the same learning process as the PDF malware section. We discussed why, the contents of various Office documents (excel, ppt, etc.). Some of the tools we used were; OfficeMalScanner, OffVis, OfficeCat, MalHost-Setup and a few others. Likewise with the PDF section a person should feel pretty confident looking at various pieces of office malware. If not understand/analyze them, for sure know enough to ask questions, and find out more information online.
After discussing PDF and Office malware we got into Memory forensics. We started off talking about why memory forensics is important. After going over a quick overview we dove into Volatility and started issuing some commands against an image provided on the course DVD that was given to us on day one. All and all it was pretty basic memory analysis. Nothing that you could find on my blog, or some others out there. It is still good to listen to other people ask question, etc. A good intro. SANS also offers a memory analysis course, which is maybe why the memory portion was a bit short given its importance these days.
Final Thoughts:
So yeah…. That’s my review. This was my attempt at getting better at them. I don’t do well with reviews. Especially movie and book reviews. “It was good” is about as far as I get. I wish I was good at reviews, because I would really like to provide reviews about books and what not on Amazon.
Pros/Cons:
It would have been neat to go through a “popular” sample like Zeus or something else more current so the students could have seen how something relatively new/popular works. Even if it was a 1 hour demo after class or something. I think that would have been pretty neat. A lot of the malware seemed old, BUT it did have its place. Trying to cover malware analysis techniques to 50+ students isn’t an easy task. Maybe an after class exercise would have been better??
I also wish they would have scheduled the Process Hacker brief on Wednesday. It was rescheduled for Thursday I believe, but everyone was leaving by then. It would have been a really nice brief to listened to while taking this malware course. – Stuff happens so I don’t hold a grudge.
Now for the ultimate question.
Would I pay $5,000 for the course + lodging out of my own personal pocket? Not unless I was a consultant that did it for a living (write off), or simply wealthy. It comes down to simple ROI. I don’t do malware analysis every day in my job. I took the course to get better at forensics.
I think the book Practical Malware Analysis for $50 would do just fine for your run of the mill forensics/malware guy/gal that doesn’t have a training budget, and doesn’t do malware analysis full time at their job.
Then again with the price of college these days maybe you can argue that it’s a better ROI than a few Masters degree courses?
Is it worth it for companies to send their people to it? Without a question, Yes. I got some great information out of the course and I feel that it was very worthwhile. It sort of brings “forensics” to a whole new level IMO.
When your average CEO is making 380 times your average workers pay then a company can afford to send their people to this malware course [1]. In the end it could be the CEO who gets pwned.
I hope you enjoy the course as much as I did! Let me know if you have any questions.
Reference
[1] http://www.aflcio.org/Corporate-Watch/CEO-Pay-and-the-99/
