I finished Wednesday listening to Irby Thompson and Mathew Monroe discuss FragFS, a way to use the Windows Master File Table (MFT) on NTFS to store data covertly. The MFT can be read as a file if you open C:\$MFT as the administrator. That file can even be written to by administrators, hence the proof of concept tools "hammer.exe" and "looker.exe" provided by the presenters. Their research indicates the average MFT can store around 36 MB of hidden data, and that commercial tools neither review nor understand data hidden in the MFT. Beyond their userland implementation, the pair also wrote a Windows device driver that provides greater functionality. They will not release that code for fear of its misuse.
Incidentally, prior to this talk I met Sam Stover, who gave me two FragFS stickers for my laptop. Thanks Sam.
On Thursday I started with Dr. Arun Lakhotia, who explained problems with analyzing adversarial code. His main point was that tools currently used to investigate malware were built for programmers solving development problems, not secuirty people analyzing suspicious binaries. He outlined three types of analysis problems.
- Some problems can be solved in polynomial time, meaning finding a solution is not difficult.
- Some problems can only be solved in nonpolynomial time, meaning that with infinite resources, they theoretically can be solved.
- Some problems, however, are undecidable. There is no exact solution, regardless of resources. Approximation is the best answer.
Dr. Lakhotia said disassembly is an undecidable problem. He described a few examples to make his point.
He also noted that although there are huge numbers of distinct pieces of malware (12,000 in the last Symantec Internet Threat Report), there are really a very small number of malware families. In other words, code reuse and plagarism is rampant in the malware world. Using this fact, Dr. Lakhotia demonstrated novel ways to decipher call obfuscation and reverse malware to a single "common form." Keep an eye on his Web site for a place where malware will be categorized according to families in a system called "VILO". I also learned of VX Heavens, a malware collection site. I guess Offensive Computing is similar.
Next I heard my friend Kevin Mandia talk about recent incident response and computer forensics cases he and his team have worked. He stated that while investigating 215 suspected compromised systems in the last three years, he could only conclusively say 103 were 0wned. Of those, only 32 revealed enough evidence to demonstrate the intruder's point of entry. Why? The team seldom had the time, audit records, or network logs to figure out what had happened.
Kevin said that modern incident response in corporate America is characterized by "vague reporting channels" and "processes that are shelf-ware." Companies approach IR as a "directionless infantry march" instead of a "precision blitzkrieg." Kevin then outlined common indicators of compromise.
- The number one detection method is internal end users. When their systems crash, their anti-virus refuses to start, they cannot "save as" documents, install new applications, run common applications, or start Task Manager, they are likely compromised.
- Surge in bandwidth usage
- Anti-virus hits: these do not mean the problem has been dealt with. Rather, it's the tip of the iceberg.
- IDS detection is rare, but can be effective during the IR.
- Customers are often a helpful source of detection indicators.
Kevin recommends enabling process tracking, to which I would add exporting the resulting logs via syslog to a central reporting server farm. He shared a few tips for understanding system processes, like using "tasklist /svc" on Windows XP and "psservice -a" to see what processes are started by the Windows svchost.exe, a sort of "inetd" for Windows.
Kevin's team demonstrated their new First Response client-server architecture for Windows. You will see me describe this as soon as I can try the beta. Suffice it to say that this free program will rock the IR world. It makes retrieving and analyzing live response data a snap.