Blog Archives

Rootkits

12/31/2015

Source: OpenSecurityTraining.info

I.What is a rootkit?
•It’s an overused term is what it is
•It's neither a root, nor a kit
•An attacker tool
•NOT how they get root
•"A rootkit is a set of programs which *PATCH* and *TROJAN* existing execution paths within the system. This process violates the *INTEGRITY* of the TRUSTED COMPUTING BASE (TCB)." - Greg Hoglund,
•The only universal truth about rootkits is that they are trying to hide the attacker’s presence
•2 basic categorization schemes though

Rings
•Ring 3 – Userspace-Based
•Ring 0 – Kernel-Based
•“Ring -1” – Virtualization-Based
–Intel VT-x(Virtualization Technology for x86), AMD-V (AMD Virtualization), Hypervisor subverted
•"Ring -1.5?" - Post-BIOS, Pre OS/VMM
–e.g. Master Boot Record (MBR) "bootkit"
–Peripherals with DMA (Direct Memory Access) (this can be ring 0, -1, or -1.5 depending on whether VT-d is being used)
–Not a generally acknowledged "ring", but the place I think it fits best
• “Ring -2” – System Management Mode (SMM)
• "Ring -2.5" - BIOS (Basic Input Output System), EFI (Extensible Firmware Interface)
–because they are the first code to execute on the CPU and they control what gets loaded into SMM
–Not a generally acknowledged "ring", but the place I think it fits best
• “Ring -3” – Chipset Based
–Intel AMT(Active Management Technology)

Stealth Malware Taxonomy
•Type 0: Uses only legitimate system features
•Type 1: Modifies things which should be static
•Type 2: Modifies things which are dynamic
•Type 3: Exists outside the operating system
•Type 4: Exists outside the main CPU/RAM

Detecting Type 0

“Out of scope” for the taxonomy ;
Blacklisting (Signature-based Anti-Virus)
Behavioral analysis (–Triumfant, QualysGuard, most AV to some degree)
Filesystem integrity checking (–Tripwire, Bit9, SolidCore (for HBSS))

Example Type 1 Malware
•Most in-the-wild rootkits are a mix of Type 1 and Type 2
IAT Hook
SSDT Hook (System Service Descriptor Table)
Inline Hook

Detecting Type 1
• Tuluka, GMER, RootkitUnhooker, IceSword, Helios Lite, RootkitRevealer, System Virginity Verifier(SVV), WinDbg !chkimg, VICE, RAIDE, chkrootkit, etc;
• [VMWatcher] for out of band integrity checks
• Strider [GhostBuster] for cross-view of hiding things on disk (but you can generally detect bootkits with memory integrity checks, and you can’t get GhostBuster anyway)

Preventing Type 1
•PatchGuard. Windows x64
•[NICKLE]. Assumes virtualized system

Example Type 2 Malware
•Direct Kernel Object Manipulation [DKOM]
•Kernel Object Hooking [KOH]

•Hook function pointers in dynamically allocated objects in the kernel
•typedef struct {
    SHORT                     Type;
    UCHAR                     Number;
    UCHAR                     Importance;
    LIST_ENTRY                DpcListEntry;
    PKDEFERRED_ROUTINE        DeferredRoutine;
    PVOID                     DeferredContext;
    PVOID                     SystemArgument1;
    PVOID                     SystemArgument2;
    PULONG                    Lock;
} KDPC, *PKDPC;

Detecting Type 2

Plenty of things handle canonical DKOM through “cross-view” detection

–VBA32AR, GMER, IceSword, RootkitRevealer, F-Secure BlackLight, Sophos Anti-Rootkit, etc
•In some cases you may be able to automatically infer semantic constraints on data structures and verify them at runtime [Petroni][LKIM]

•Recent academic interest in KOH
–[HookMap], [HookSafe], [HookScout]

Detecting Type 4 – Ring -3
•Use other ring -3 detectors and get there first? TPM can verify a compatible BIOS, but what about everything else? [DeepWatch] wasn’t designed for it, but can it help?
•Self-attestation [SWATT][SBAP][Pioneer]

Spoiler Alert
•There are ~8 rootkits leveraging ~10 techniques in the example VM, depending on how you count.

!chkimg
•You can also find modifications to static code/data areas with the !chkimg windbg command. It checks the version in memory against the file on disk

System Virginity Verifier
•http://invisiblethings.org/tools/svv/svv-2.3-src.zip
•Like !chkimg but tries to apply some heuristics to the modifications it found to apply a severity score.

Stuxnet use of inline hooks
•From the Stuxnet Dossier: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf
•"~WTR4141.tmp then loads ~WTR4132.tmp, but before doing so, it attempts to hide the files on the removable drive. Hiding the files on the removable drive as early in the infection process as possible is important for the threat since the rootkit functionality is not installed yet, as described in the Windows Rootkit Functionality section. Thus, ~WTR4141.tmp implements its own less-robust technique in the meantime.
•WTR4141.tmp hooks the following APIs from kernel32.dll and Ntdll.dll:
•From Kernel32.dll
–FindFirstFileW
–FindNextFileW
–FindFirstFileExW
•From Ntdll.dll
–NtQueryDirectoryFile
–ZwQueryDirectoryFile"

Review: IAT Hooking
•When the IAT is fully resolved, it is basically an array of function pointers. Somewhere, in some code path, there’s something which is going to take an IAT address, and use whatever’s in that memory location as the destination of the code it should call.
•What if the “whatever’s in that memory location” gets changed after the OS loader is done? What if it points at attacker code?

Review: IAT Hooking 2
•Well, that would mean the attacker’s code would functionally be “man-in-the-middle”ing the call to the function. He can then change parameters before forwarding the call on to the original function, and filter results that come back from the function, or simply never call the original function, and send back whatever status he pleases.
–Think rootkits. Say you’re calling OpenFile. It looks at the file name and if you’re asking for a file it wants to hide, it simply returns “no file found.”
•But how does the attacker change the IAT entries? This is a question of assumptions about where the attacker is.

Review: IAT Hooking 3
•In a traditional memory-corrupting exploit, the attacker is, by definition, in the memory space of the attacked process, upon successfully gaining arbitrary code execution. The attacker can now change memory such as the IAT for this process only, because remember (from OS class or Intermediate x86) each process has a separate memory space.
•If the attacker wants to change the IAT on other processes, he must be in their memory spaces as well. Typically the attacker will format some of his code as a DLL and then perform “DLL Injection” in order to get his code in other process’ memory space.
•The ability to do something like DLL injection is generally a prerequisite in order to leverage IAT hooking across many userspace processes. In the kernel, kernel modules are generally all sharing the same memory space with the kernel, and therefore one subverted kernel module can hook the IAT of any other modules that it wants.

Review: DLL Injection

Review: Lab: IAT hooking
•http://www.codeproject.com/KB/vista/api-hooks.aspx
–This will hook NtQuerySystemInformation(), which is what taskmgr.exe uses in order to list the currently running processes. It will replace this with HookedNtQuerySystemInformation(), which will hide calc.exe
–I modified that code to use IAT hooking rather than inline (which is much simpler actually)
•Steps:
–Compile AppInitHookIAT.dll
–Place at C:\AppInitHookIAT.dll for simplicity
–Use regedit.exe to add C:\AppInitHookIAT.dll as the value for the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT \CurrentVersion\Windows\AppInit_DLLs (if there is already something there, separate the entries with a comma)
–Start calc.exe, start taskmgr.exe, confirm that calc.exe doesn't show up in the list of running processes.
–Remove C:\AppInitHookIAT.dll from AppInit_DLLs and restart taskmgr.exe.
–Confirm calc.exe shows up in the list of running processes.
–(This is a basic "userspace rootkit" technique. Because of this, all entries in this registry key should always be looked upon with suspicion.)

Go with what you know: IDT
This indicates that interrupt index 0xE in the Interrupt Descriptor Table (IDT) does not point as its normal location, it points at memory address 0xF9F55A40, and GMER has not been able to determine which driver, if any, is associated with that memory range (thanks to another rootkit we'll learn about later.)

References
•[VMWatcher] http://www.csc.ncsu.edu/faculty/jiang/pubs/CCS07.pdf
•[NICKLE]: http://friends.cs.purdue.edu/dokuwiki/doku.php?id=nickle
•[3] “TDL rootkit x64 goes wild” http://www.prevx.com/blog/154/TDL-rootkit-x-goes-in-the-wild.html
•[HyperSentry] http://discovery.csc.ncsu.edu/pubs/ccs10.pdf
•[HookMap] http://www4.ncsu.edu/~zwang15/files/raid08.pdf
•[HookSafe] http://www4.ncsu.edu/~zwang15/files/ccs09.pdf
•[HookScout] http://www.ecs.syr.edu/faculty/yin/pubs/hookscout-dimva10.pdf
•[8] “Don’t Tell Joanna, The Virtualized Rootkit Is Dead” https://www.blackhat.com/presentations/bh-usa-07/Ptacek_Goldsmith_and_Lawson/Presentation/bh-usa-07-ptacek_goldsmith_and_lawson.pdf
•[9] “Compatibility is Not Transparency: VMM Detection Myths and Realities”
http://www.usenix.org/event/hotos07/tech/full_papers/garfinkel/garfinkel_html/
•[DKOM] “VICE – Catch the hookers”- http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-butler/bh-us-04-butler.pdf
•[KOH] “Kernel Object Hooking (KOH) Rootkits” - http://www.rootkit.com/newsread.php?newsid=501
•[DeepWatch] “Chipset Based Approach to Detect Virtualization Malware” http://www.blackhat.com/presentations/bh-usa-08/Bulygin/bulygin_Chip_Based_Approach_to_Detect_Rootkits.pdf

Author

Archives

Categories