Defense Against the Dark Arts: Week 5

The presenter for this week’s lectures was Aditya Kapoor, a malware researcher who was employed by Intel. He’s now at Cylance working on security research.


A rootkit is a sophisticated form of malware which allows code to infiltrate and run on a machine without being detected. Rootkits gain a level of access that is normally not permitted. This can be used to provide different types of malware access to a machine.

The central strategy in defending against rootkit attacks is to prevent their installation in the first place because once they’re on a machine, they’re very difficult (perhaps impossible) to track down.


The Agony lab involved observing the behavior of a particular rootkit sample called Agony. Part of Agony’s functioning depends on hooking, which is the process of intercepting some sort of communication on a machine and processing the result. The example that the presenter used was a thief stealing a product as it was being shipped from one place to another. In Agony’s case, the communication that it is hooking into is the API.

A key part of rootkits, as mentioned above, is obfuscation. In the Agony sample, there’s a file being hidden that is not visible to the user, nor to anti-virus software. Using a tool called Tuluka, the presenter was able to restore the file that was hidden by “rewinding” the series of events.


The discussion on threads was mostly review for me (thanks to previous courses in this program), but there was a definition of the term that I liked. A thread, the presenter said, is the smallest unit of execution on a machine. Threads are important when discussing rootkits because the rootkit will employ a thread to accomplish its goal. As such, it’s important to be able to identify which thread among those currently running on a machine is associated with a rootkit.

Process Hacker

For this lab, the presenter demonstrated the use of a tool called Process Hacker. It’s similar to the Windows application Process Explorer, but has an important difference: it allows the inspection of the virtual memory associated with a process.

The malware that we investigated in this lab was called ZBot (or Zeus), which is a trojan that can be used for logging keystrokes.

Live kernel debugging

This demonstration showed how to inspect the memory and assembly instructions while using a debugger like WinDbg. The tool that the presenter used also allows modifying memory via manual entry. I was not familiar with this feature before this lecture.

This modification of memory was important for this particular example because it allows erasing links to the malware code. Once that code was no longer referenced in the kernel, it will no longer be called. After this modification Tuluka shows that the infection no longer exists. That said, if the malware is running on another thread then it can be repatching what you’re patching, presenting a race condition.