This week’s material covers Windows internals and rootkits. A rootkit is a collection of malicious software that enables access to areas not otherwise allowed and often masks its own existence. What makes rootkits so devious is that they conceal themselves. The prevalence of rootkits peaked in the 2000s, but there are still new rootkits being released today. The decline in their popularity can be attributed to new security measures in modern operating systems that prevent unrestricted kernel access, like checking for valid digital signatures for all drivers.
Rootkits operate at the kernel level. The other level is the user level where .exe and .dll files live. The kernel level operates on .sys files. Kernel mode gives more access to system features. Kernel memory, for example, has no security separation and any kernel driver can access any system memory. If a rootkit is able to compromise kernel memory, it can wreak havoc on a system.
Lab 1
The first lab this week has us analyzing a piece of malware named Agony. First, we run the malware using Cuckoo to see what files are created by the executable. After running analyzer.py, the binary files that were created are captured in a files directory. This is handy to know, as last time we used Cuckoo in a lab, I went through the log file manually to check for files that were created. The three binary files created were: bad.bin, tzres.dll, and sortdefault.nls.bin.

The windows list directory command, dir, calls different APIs depending on the parameters it is given. Running dir *.* in the analyzer folder does not list any .sys files. However, running dir *.sys reveals that a wininit.sys file is in the directory. The first command normally should show the sys file. This is evidence that the rootkit has changed something about the dir *.* command.

Next, we use the Tuluka tool to analyze what the malware has done. We navigate to the SST tab and sort the functions by “suspicious”. Three suspicious functions are listed: NtEnumerateValueKey, NtQueryDirectoryFile, and NtQuerySystemInformation. The NtQueryDirectoryFile in particular is called when calling dir *.*. This has been modified to call a different API that hides .sys files.

Windows explorer also uses the dir *.* to show files and the wininit.sys file is not shown in explorer either. Since antivirus also use user-level API calls like dir *.*, this file would be concealed to these types of programs as well.

The next part of the lab used LiveKD to analyze the new code pointed to at the current location of these three functions. These functions now point to wininit plus some offset. This new code that has replaced the function is responsible for hiding the .sys file. If we go back into Tuluka and use the restore service on this function, we can revert this function to its original code and see the .sys file in the analyzer folder again.


This malware needs to be smart enough to find the original address of the NtQueryDirectoryFile, hook itself, and properly patch back. The lecturer referenced an example of a food supply line between two people and a bad actor who would filter all the bananas that passed between the two people. The bad actor cannot just filter all the food because would lead to detection, but if he only takes bananas and redirects the rest of the food to the second person, it is possible to avoid detection. This is similar to our malware because it needs to swap the pointer to the original NtQueryDirectoryFile code in the System Service Descriptor Table (SSDT) and change it to malicious code. Then, the malicious code need to patch back to the original code. If the malware was not properly patched back into the original address, it might lead to blue screens or other errors that would lead to detection.
Lab 2
This lab examines the zbot malware sample using ProcessHacker. The zbot malware is a key stroke capturing malware. After unzipping the malware.exe file to desktop and running Notepad, we checked ProcessHacker to see what changes were made to memory.

When examining the memory used by Notepad, we can sort by permissions. If there was some malware added to the memory of the program, I would expect that there is some sort of executable code injected. Looking at the memory for Notepad, I saw suspicious unnamed files (Private (Commit)) with read/write and read/write/execute permissions. Legitimate DLL files would have names.

Now that the malicious code is hooked into the Notepad memory with read/write/execute permissions, it can capture our key strokes.’
Lab 3
This lab covered live kernel debugging. First, we establish a connection between the debugger machine and the debuggee machine using WinDbg.


We can determine the size of the hooked malicious code by subtracting the call to the NtEnumerateValueKey original code and the address where the malware has hooked. On the debuggee machine, the hooked malicious code starts at 9d52a480 as shown in Tuluka below. So we set a breakpoint here in in WinDbg then step through each instruction until we get to a call instruction that returns us to the original address of the NtEnumerateValueKey API call. This address of the call instruction is at 9d52a480 as shown in the WinDbg screenshot below. By subtracting the addresses, we get 54h or 84 bytes in decimal, the length of the malicious code hooked in this Windows API call.


Lab 4
Now we can patch the change in the KiServiceTable to restore the address of the original code for NtEvaluateValueKey. Ultimately, we want to see that the NtEnumerateValueKey function is no longer suspicious in Teluka. By typing the command, dps nt!KiServiceTAble L191, we can see the table with the addresses for each function. Now we just need to find memory containing 9d52a480 and change it to 82e85a0f. It is important to note that the address is stored in little endian.



Since the malicious code is no longer referenced in memory, it will no longer be executed once the table is patched. However, we are lucky that this is enough to disable the rootkit. The lecturer mentioned that some rootkits will un-patch the addresses back to malicious ones.