The speaker for this week was Aditya. The first things we went over this week were what rootkits were, and how we needed to better understand how processes and memory worked so we could better understand how to deal with rootkits. Dealing with rootkits helps us better understand Windows security, which is the biggest target of malware nowadays.
Something that I noticed was that almost all operating systems now are 64 bit, rather than the old 32 bit. I know back when I was in high school and before that, all of my computers were exclusively 32 bit. This change is good for users because 64 bit kernel is harder for rootkits to infiltrate, but it can be done. Methods include bypassing driver signing checks, modifying the windows boot path(preventable with the use of secure boot), kernel exploits such as third party drivers, and stealing valid signatures.
So how do kernels use memory? Kernels use a flat memory model, which means that there is no security features present and the CPU can access any of the memory. The windows kernel(system32) is made up of mostly windows kernel and driver code.
We had to use Cuckoo, but we were also told we could use other tools if we weren’t great with it, such as Regshot.exe.
It created 3 files in cuckoo named 630669781, 7449788859, and 804340447. Inside each was one file, in the same order: bad.bin, tzres.dll.bin, and sortdefault.nls.bin.
We then used the command line to search around for different files. One file that we found using the “dir *.sys” command was wininit.sys. This file is not visible without the use of tools or search commands.
We then used the tool Tuluka to view “suspicious” files. 3 files popped up, highlighted in red: wininit.sys in analyzer. It called the 3 functions, NtEnumerateValueKey, NtQueryDirectoryFile, and NtQuerySystemInformation. The original and current columns refer to the pointers in memory.
Next we used the livekd.exe tool, which reads kernel memory, to see what exactly is happening there. Running the “u <address” command shows what’s happening at that memory address. We ran this command for both the original and current pointers of the wininit.sys file. We are also able to look at modules loaded.
One cool thing we did was right click and use the “restore service” function to return the pointer to its original state. This dropped one of the suspicious activities back to normal, and allowed us to see the wininit.sys file in the analyzer directory once again.
When a application, such as word or excel executes some kind of arithmetic code, it gets translated to assembly code, then machine code. This machine code is passed to the RAM first before any execution happens. If another program wants to do something similar, it will be scheduled after the first app. The thread scheduler decides what gets to get executed first. When they are executed, the CPU takes the code through an instruction pipeline, which returns the result back through the bus, to the application. Multi-threading was introduced where there can be multiple instruction pipelines to increase productivity in code execution, then later came multi-core CPUS ,which can multiply productivity(I have a quad-core laptop). Having multiple cores makes multi-tasking better, but doesn’t make processing power much stronger.
Processes have their own memory and boundary. They are implemented as objects, and an executable process may contain more than one thread. Each process has an object table that has handles to other known objects, and each process needs a thread to execute.
This tool is extremely similar to what Process Explorer shows us, but it can show the how the process’ virtual memory changes of each process in order. It also shows the memory contents at any of these points.
We used a malware file named zbot, which contained a .bin and malware.exe. We looked at the affect of malware.exe on notepad. One notable thing that was in the memory, was there are now tons of Private(Commit) actions in notepad’s memory, and they had read write access. This is an example of Process Injection, where an outside interference will inject code into another process.
We got a chance to use two separate VM’s to analyze the kernel of one VM in another using WinDbg. WinDbg could break and freeze the VM just like it could break a program. The exercise we were asked to do was repatch the modified pointers in memory that were changed by the Agony malware using WinDbg. Patching/changing the pointers back to their original pointers leaves the malware, but the code won’t ever be executed, basically neutering it. Apparently there’s a chance that doing this will kill the VM and “blue screen of death” the computer, but if done right, the hook should be gone.
We learned about a type of malware named bootkit that hooks/patches Windows throught he master boot record specifically. Apparently some of the first malware was a bootkit. Inn 2015 there was a bootkit named “South Korean Viper” that messed up a bunch of computers in South Korea, to the extent that they could not start.
This was one of the more confusing weeks for this class, learning about the kernel and patching bytes was confusing, but it’s definitely interesting. Re-learning about threads and processes reminded me of my time in my operating systems class, I struggled in that class so I definitely did not have that much fun programming with processes again.