This talk will feature a live—but entirely self-contained, and therefore safe!—demonstration of a modern malware attack in action. Gain insight into how the bad guys think and operate, and you learn how better to defend yourself against them. The talk will also examine some of the tricks and techniques that can be used in a malware research lab to get even an apparently complex and heavily obfuscated piece of malware to reveal its secrets in safety.
It took them a little over a year to convince the network engineers that RTT from England to Australia is about 300ms no matter how much money you throw at it.
Most of the tools Paul used to set up his sandbox are open source.
Tools for writing rootkits are publicly available; you don't have to know much to get started. (For example, Sony's rootkit was very similar to one that was dissected at a conference a few years prior.)
You should go download the Sysinternals tools if you do any type of development work on Windows. For example, the Process Explorer (procexp.exe) tool is extremely useful.
OllyDbg is a fantastic Windows debugger.
Windows resisted stack randomization for the longest time for
performance reasons. This is why writing stack exploits is
pathetically easy; there's a short list of known addresses
for injecting code into the stack on various DLLs.
In Vista, stack randomization occurs for DLLs, but only when you reboot.
Having a non-executable stack is a great idea, but you can't always make the stack non-executable.
The Interactive Disassembler (IDA) is probably one of the best disassembler ever. You should buy the professional version.
You cannot use a debugger to safely examine malware, because there are many tecniques that malware can use to break out of the debugger. You must sandbox the machine on which the malware is running.
Microsoft provided a DLL to download a URL to a file in one line of C. It's one of the more popular tools for malware writers to use.
If you have something to monitor file access (e.g., filemon, regmon), a good detection technique is to watch for files that get created, then disappear from sight, but are never deleted. That's a dead give-away that something is up to no good.
Device drivers in Windows tend to load in alphabetical order, so this is why you want to name your antivirus program AAAAARKVARK, because it'll load before MMMMMALWARE.
The Windows debugger is actually a pretty good debugger.
The MZ magic number was picked by the guy who created the file format, Mark Zbikowski.
If you find that the malware is blocking access to antivirus companies, and you're an antivirus company, the first thing you want to check is whether you're on the list. Because there's no worse diss than not being targeted by the malware.
KeServiceDescrptorTable in Windows is equivalent to the Linux system call table.
I'm not sure how much practical information the audience actually took away from this presentation, as Paul was poking through Windows internals at a very deep level—to the point where he was essentially looking at hex dumps and disassembling it in his head.
If there's only one lesson here, it's this: malware authors are very, very clever, and antivirus authors have to be even more clever.
You can go to the index of my Usenix notes.