Week 5 - Windows Internals
This week we will be primarily focusing on rootkits. A rootkit is a piece of malware that conceals its activities and existence from the user. The ushering in of this new era of malware came into focus in 2006 when Sony released a disk to try and prevent copying of music. In this piece of software any file that started with $sys$ was hidden from the user. Attackers saw the potential of this and gained control of this method. The majority of rootkits operate in a 32 bit Windows environment however some rootkits target a 64 bit environment. Most rootkits are at the kernel level because at this level they have full access and control to the system. The slide below is a nice illustration what the computer architecture looks like and where rootkits are located.
slide source from lecture, OSU CS 373
Definitions for this week:
thread - the smallest unit of execution within an operating system. The slide below has a nice demonstration of how a thread is executed
hooking - redirecting an executable's memory to an unintended area which is where the malicious code is
in-line hooking - modifying the actual code rather than the table
master boot record (MBR) - the first sector on a disk contains the MBR which has where the operating system is stored and how to boot up the operating system
bootkit - similar idea to a rootkit except this type of malware manipulates the disk size and boot time. Rootkits are stealthy while a bootkit just modifies the MBR.
File Content Forging - overwrite existing files and forge the 'view' so that anti-virus scanners get the clean view rather than the malicious one
New tools for this week:
Process Hacker - this is a little more detailed than Process Explorer, it can walk through the virtual memory of the process and identify some attributes about the memory
Agony Lab
I started examine what happens when examining Agony in Cuckoo. Once all of the setup was done I ran analyzer.py and discovered that three new folders were created.
inside of 1158075553 was tzres.dll.bin, 1253791553 had sortdefault.nsl.bin, and 3376163572 had bad.bin. Everything fell apart from there. I followed the instructions to inspect the file with Cuckoo which went ok, then I ran Tuluka to see what processes were discovered. Nothing.
I then tried to examine the attributes of the agony.exe and wininit.sys but my output did not match what was shown in the lectures.
I thought that I maybe I need to examine the system from the debugger VM. I logged in, set up Windbg to view the debugee VM, however once I set the debugee to run with command "g" I can not enter any further commands to Windbg since the breakpoint is never hit. A learning experience for sure, but I wasn't able to get the intended results.
slide source from lecture, OSU CS 373
Definitions for this week:
thread - the smallest unit of execution within an operating system. The slide below has a nice demonstration of how a thread is executed
hooking - redirecting an executable's memory to an unintended area which is where the malicious code is
in-line hooking - modifying the actual code rather than the table
master boot record (MBR) - the first sector on a disk contains the MBR which has where the operating system is stored and how to boot up the operating system
bootkit - similar idea to a rootkit except this type of malware manipulates the disk size and boot time. Rootkits are stealthy while a bootkit just modifies the MBR.
File Content Forging - overwrite existing files and forge the 'view' so that anti-virus scanners get the clean view rather than the malicious one
New tools for this week:
Process Hacker - this is a little more detailed than Process Explorer, it can walk through the virtual memory of the process and identify some attributes about the memory
Agony Lab
I started examine what happens when examining Agony in Cuckoo. Once all of the setup was done I ran analyzer.py and discovered that three new folders were created.
inside of 1158075553 was tzres.dll.bin, 1253791553 had sortdefault.nsl.bin, and 3376163572 had bad.bin. Everything fell apart from there. I followed the instructions to inspect the file with Cuckoo which went ok, then I ran Tuluka to see what processes were discovered. Nothing.
I then tried to examine the attributes of the agony.exe and wininit.sys but my output did not match what was shown in the lectures.
I thought that I maybe I need to examine the system from the debugger VM. I logged in, set up Windbg to view the debugee VM, however once I set the debugee to run with command "g" I can not enter any further commands to Windbg since the breakpoint is never hit. A learning experience for sure, but I wasn't able to get the intended results.
Comments
Post a Comment