Kernel-mode callbacks routines are used by various drivers, they are commonly used by malwares or third party products because they make possible to “hijack” critical functions without having to patch the SSDT (System Service Dispatch Table) which is protected by PatchGuard on x64 version of Windows. Moreover, it avoids to patch the prolog code of the target function.

This article is a short introduction to what functions are registering callback and where they are stored. Windows Kernel is storing callback functions using different methods, some of them can be retrieved in a table like notify routines, or via a linked list like Bug check callback functions.

The most infected callback table is the “Load Image” (PspLoadImageNotifyRoutine) callback table, which is infected by TLD4 Rootkit as highlighted by Frank Boldewin.
PspLoadImageNotifyRoutine, PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine are part of the Process Manager and entries can be registered using PsSetImageLoadNotifyRoutine(),  PsSetCreateProcessNotifyRoutine[Ex](), and PsSetCreateThreadNotifyRoutine() functions.

PspNotifyEnableMask is updated when a table is used, each lower bit correspond to a callback table of the process manager.

Create process notify routines are called two times, one time during the creation of the first/main thread in PspInsertThread(), and a second time during the destruction of the process in PspExitProcess().

Create thread notify routines are  called each time PspInsertThread() is invoked by the creation new thread and also each time PspExitThread() is invoked during the destruction of a thread.

And finally, load image notify routines are invoked by the Memory Manager each time an executable image is loaded in memory.

Configuration Manager (Registry) call back functions are managed by the double link list called CallbackListHead on Windows Vista+ and by the callback table CmpCallBackVector in NT 5 and below. These callbacks are registry by CmRegisterCallback() function. As highlighted by Scott Noone on his personal blog.

Bug checks (B.S.O.D.) have three linked list dedicated to callbacks: KeBugCheckCallbackListHead, KeBugCheckReasonCallbackListHead, and KeBugCheckAddPagesCallbackListHead introduced in Vista+. These callbacks functions are sometimes patched by rootkit such as Rustock.C to remove “sanitize” the physical memory before the generation of a Microsoft crash dump during the B.S.O.D. as highlighted by Frank Boldewin in his Hack.lu presentation in 2008. Please notice that these callback functions are not called during the generation of a Microsoft crash dump using MoonSols WinDD utility.

Entries in KeBugCheckCallbackListHead are inserted by KeRegisterBugCheckCallback() function and entries in KeBugCheckReasonCallbackListHead are inserted by KeRegisterBugCheckReasonCallback() functions.

NMI (Non-maskable interrupt) callbacks are managed by the double link list called KiNmiCallbackListHead and registrable by KeNmiRegisterCallback() – These callbacks are invoked each time KiHandleNmi() function is invoked, and this function is called every time the hardware interruption 2 occurs (INT2, nt!KiNmiInterruptStart()).

AlpcpLogCallbackListHead is managed by Windows ALPC (Advanced Local Procedure Call) Manager. In theory only the internal kernel function AlpcRegisterLogRoutine() can insert an entry in this link-list, and this ALPC callbacks are invoked every time an ALPC log message is sent.

EmpCallbackListHead is a linked list managed by Errata Manager, only the Windows Kernel can have access to it to register entries.

Some of these callback tables, linked-list are only available from Windows Vista symbols (e.g. AlpcpLogCallbackListHead, KiNmiCallbackListHead).

The Windows Debugger script is available below, to run it use the following command:

This WinDbg script is working with every version of Windows from XP to 7, and for X86, x64 and IA64 architectures. Example of output can be found here.

Download Windbg script

From Windows 2000 to Windows 7 and Windows 2008 R2, Windows Service Controler/Manager is “services.exe” – in other words “services records” are inside this process address space.

The interesting thing with service records is that they have a tag signature at the beginning. Here are the 3 different tag signatures:

• “sErv” is the tag signature for NT 5.x service control records.
• “serH” is the tag signature for NT 6.x service control records.
• “scrH” is the tag signature for the service control manager.

Based on these tag signatures, we can easily retrieve these structures from a memory dump or from a live debugging session from Microsoft WinDbg, Microsoft LiveKd or MoonSols LiveCloudKd.

The following WinDbg command can be used to retrieve each tag records from memory :

As pointed out by Scott Noone and Nephi Johnson, the command “s” (Search Memory) can also be used with the .foreach WinDbg command if you use it with the -[1] argument.

For instance, if you want to look for every MZ signature in the current address space or to look for a particular string pattern in every address space you can use one of these two commands :

Services records contains a SERVICE_STATUS entry, which provide information regarding the service type and the service status – they also contain UNICODE string pointer to the service description and to the service name and of course the ProcessId.
From Windows 2000 to Windows 7 and Windows 2008 R2, Windows Service Controler/Manager is “services.exe” – in other words “services records” are inside this process address space.

The interesting thing with service records is that they have a tag signature at the beginning. Here are the 3 different tag signatures:

• “sErv” is the tag signature for NT 5.x service control records.
• “serH” is the tag signature for NT 6.x service control records.
• “scrH” is the tag signature for the service control manager.

Based on these tag signatures, we can easily retrieve these structures from a memory dump or from a live debugging session from Microsoft WinDbg, Microsoft LiveKd or MoonSols LiveCloudKd.

The following WinDbg command can be used to retrieve each tag records from memory :

typedef struct _SERVICE_STATUS {
DWORD dwServiceType;
DWORD dwCurrentState;
DWORD dwControlsAccepted;
DWORD dwWin32ExitCode;
DWORD dwServiceSpecificExitCode;
DWORD dwCheckPoint;
DWORD dwWaitHint;
} SERVICE_STATUS, *LPSERVICE_STATUS;

If you want more, check out the dates of the next MoonSols trainings or request a private training

Download WinDbg Script

As highlighted Frank Boldewin to me, some rootkits also use the following functions to registers callbacks or notification functions.

IoRegisterFsRegistrationChange
IoRegisterShutdownNotification
IoRegisterPlugPlayNotification

How these notification functions and callback functions are registered is described below, an output of this WinDbg Script can be found at the end of this blogpost, and a link to the script is present at the beginning of the blogpost.

IoRegisterFsRegistrationChange() add entries in IopFsNotifyChangeQueueHead
And it contains both a notification routine plus a pointer to the driver object

kd> dps nt!IopFsNotifyChangeQueueHead L2
fffff800`0287b170  fffff8a0`001cd060
fffff800`0287b178  fffff8a0`001cd060

Entries are like this

     LIST_ENTRY List;
     PDRIVER_OBJECT DrvObj;
     PVOID NotificationRoutine;
} FOO, *PFOO;

kd> dps fffff8a0`001cd060 L4
fffff8a0`001cd060  fffff800`0287b170 nt!IopFsNotifyChangeQueueHead
fffff8a0`001cd068  fffff800`0287b170 nt!IopFsNotifyChangeQueueHead
fffff8a0`001cd070  fffffa80`017657c0
fffff8a0`001cd078  fffff880`0112d7e0 fltmgr!FltpFsNotification
kd> !drvobj fffffa80`017657c0
Driver object (fffffa80017657c0) is for:
\FileSystem\FltMgr
Driver Extension List: (id , addr)

Device Object list:
fffffa8001b5c060  fffffa8001b5e330  fffffa8001b5e5c0  fffffa8001883aa0
fffffa8001863ca0  fffffa8001776710  fffffa800176e700  fffffa800176c700
fffffa8001769790  fffffa8001766790

IoRegisterShutdownNotification() adds an entry to the device object only to IopNotifyShutdownQueueHead

kd> dps nt!IopNotifyShutdownQueueHead L3
fffff800`0287b1b0  fffffa80`0279c220
fffff800`0287b1b8  fffffa80`00cfa2a0
fffff800`0287b1c0  fffff800`0287b1c0 nt!IopDriverReinitializeQueueHead

Entries are defined like the following:

    LIST_ENTRY List;
    PDEVICE_OBJECT DevObj;
} FOO2, *PFOO2;

kd> dps fffffa80`0279c220 L3
fffffa80`0279c220  fffffa80`0217a580
fffffa80`0279c228  fffff800`0287b1b0 nt!IopNotifyShutdownQueueHead
fffffa80`0279c230  fffffa80`021be050

kd> !devobj fffffa80`021be050
Device object (fffffa80021be050) is for:
00000060 \Driver\usbhub DriverObject fffffa8002157e70
Current Irp 00000000 RefCount 0 Type 00008600 Flags 00002840
Dacl fffff9a10007f0b1 DevExt fffffa80021be1a0 DevObjExt fffffa80021c1570
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedTo (Lower) fffffa8001b5f060 \Driver\usbhub
Device queue is not busy.

There is also the File System queue, one queue per file system.

kd> x nt!Io*FileSystemQueueHead
fffff800`0287b200 nt!IopCdRomFileSystemQueueHead =
fffff800`0287b210 nt!IopDiskFileSystemQueueHead =
fffff800`0287b1e0 nt!IopTapeFileSystemQueueHead =
fffff800`0287b1f0 nt!IopNetworkFileSystemQueueHead =

There are linked via the Queue field of the Device Objects.

kd> !devobj poi(nt!IopCdRomFileSystemQueueHead)-@@c++(#FIELD_OFFSET(nt!_DEVICE_OBJECT, Queue))
Device object (fffffa8001b5ec50) is for:
UdfsCdRom \FileSystem\udfs DriverObject fffffa8001b5ee70
Current Irp 00000000 RefCount 1 Type 00000003 Flags 00000040
Dacl fffff9a1002f66f0 DevExt 00000000 DevObjExt fffffa8001b5eda0
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) fffffa8001b5e5c0 \FileSystem\FltMgr
Device queue is not busy.

kd> !devobj poi(nt!IopDiskFileSystemQueueHead)-@@c++(#FIELD_OFFSET(nt!_DEVICE_OBJECT, Queue))
Device object (fffffa8001b5ea30) is for:
UdfsDisk \FileSystem\udfs DriverObject fffffa8001b5ee70
Current Irp 00000000 RefCount 1 Type 00000008 Flags 00000040
Dacl fffff9a1002f66f0 DevExt 00000000 DevObjExt fffffa8001b5eb80
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) fffffa8001b5e330 \FileSystem\FltMgr
Device queue is not busy.

kd> !devobj poi(nt!IopTapeFileSystemQueueHead)-@@c++(#FIELD_OFFSET(nt!_DEVICE_OBJECT, Queue))
Device object (fffffa80015b4e40) is for:
RawTape \FileSystem\RAW DriverObject fffffa8000c37a10
Current Irp 00000000 RefCount 1 Type 00000020 Flags 00000850
Dacl fffff9a1002f66f0 DevExt 00000000 DevObjExt fffffa80015b4f90
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
Device queue is not busy.

kd> !devobj poi(nt!IopNetworkFileSystemQueueHead)-@@c++(#FIELD_OFFSET(nt!_DEVICE_OBJECT, Queue))
Device object (fffffa8001861730) is for:
Mup \FileSystem\Mup DriverObject fffffa8001861dd0
Current Irp 00000000 RefCount 9 Type 00000014 Flags 00040040
Dacl fffff9a1002f66f0 DevExt 00000000 DevObjExt fffffa8001861880
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) fffffa8001863ca0 \FileSystem\FltMgr
Device queue is not busy.

Did you ever wish of being able to control your virtual machines from your host/parent partition, without having to install any agent inside your Virtual Machine ? Like kernel modules, processes, dlls, handles, files, objects enumeration – no matter of the target version of Windows ?

And in addition to that, did you have wish to have a security agent empowering your cloud security by running only from the parent partition side and not from the children partitions like popular Anti-Virus solutions (Microsoft, McAffee etc.) does ? Did you ever wish of something that do more that scanning signatures in memory, but that also proceed to memory behaviorism to detect low-level modification to improve your security level and alert you when the next Stuxnet will hit you ?

MoonSols redesigned cloud management and security for Microsoft Hyper-V Hypervisor, and now makes possible to monitor your virtual machines and also to kill processes over its WMI / PowerShell interface. In addition to the innovation part regarding Incident Response, it’s also a great move for Microsoft Hyper-V Administrators.

The screenshot below is demonstrating MoonSols WMI Hyper-V Virtual Machines interface detecting, from outside the box, an elevation of privilege using CVE-2010-1893 tcpip.sys vulnerability on a Windows 7 target. (Exploit by Tarjei Mandt)

Click on the image for more details.

Please contact sales@moonsols.com for commercial inquiries, or msuiche@moonsols.com for general questions.

Some people have already made the analysis of the lastest Flash 0day itself, which means this blogpost is not going to cover the attack itself but only a specific part: when Microsoft Word is re-opened from a Command Line shell created by the exploit.

This is not a pure technical article, this article aims at showing how (an) infected Hyper-V virtual machine(s) could be quickly analyzed.

In summary of the attack, we have a Microsoft Word Document with an embedded Flash file. The Flash file is using ActionScript heap spraying, then it is exploiting an un-patched Flash vulnerability (0day). Once the shellcode/malicious code is executed, a Command Line Shell is launched to reopen Microsoft Word with a regular Word document like nothing happened. Here is the Command Line executed:

This blogpost covers different methods (from live to post-mortem analysis) to retrieve the command line above.

Instead of using MoonSols Win32dd/Win64dd/DumpIt Acquisition Utilities inside the Virtual machine, everything is done from outside the virtual machine (from the Parent Partition).

We have two Microsoft Hyper-V virtual machines. One is running under Windows XP SP3 x86 and the other one under Windows 7 SP0 x86, they are both using Microsoft Office 2007 and the lastest Flash player version (10.2.253.1).

In the screenshot below, I’m imaging the physical memory of the Windows XP as a Microsoft crash dump using LiveCloudKd.

Having a physical memory image makes possible to analyze the memory image with MoonSols Analyst*, as you can see below.

Sometimes, regular tools/products/utilities are not enough. But since, a Microsoft Crash Dump image had been generated it can be analyzed via Microsoft Windows Debugger.

Command line things are interesting if you want low level details but when you have several virtual machines to inspect, a PowerShell over WMI interface is fantastic. In the screenshot below, we can see that the malicious command line had been executed on both virtual machines.

Comments of this blogpost are open if you have any comments. If you are interested by Memory images analysis, check out the public training schedule : http://www.moonsols.com/trainings/ – Private trainings with more hands-on exercices can be delivered for if the class has minimum 4 students (contact: sales@moonsols.com)
Otherwise, if you want to make a private and interesting offer, I can be reached via msuiche moonsols.com

This blogpost is the part two of “WMI, VMs, LiveCloudKd, MoonSols Analyst & CVE-2011-0611″ about latest Adobe Flash 0day/unpatched vulnerability.

Yesterday, we saw how we could identify how Microsoft Word had been relaunched. But this artifact is obviously not enough to detect if a running machine had been infected or not.

As pointed out by Mila, on Windows XP two dlls are created mspmsnsv.dll and msimage.dat and on Windows 7 we have a dll with a random name and msimage.dat.

The figure below shows the existence of these two Dynamic Libraries in scvhost.exe process. These dlls could be dumped for additional analysis if needed.

In both version of Windows, msimage.dat is present in the automatically started service. In other words, if we would like to detect the present of these malicious code on a machine without using signatures. We could just look if there is a dynamic library called “msimage.dat” used by any scvhost.exe process.

Jon Larimer, Security Researcher at IBM, encouraged me to write a small piece of code to detect if a Microsoft Hyper-V virtual machine had been infected. And in addition to that, I added a feature to kill the scvhost.exe process running inside the virtual machine from the host without having to install any agent inside the virtual machine.

The application Kill-CVE-2011-0611.exe can be distributed on request if you send me an email at msuiche.

For those who are curious about how it works, MoonSols has written its own interface and its own library to retrieve such information. The source code used for that (using MoonSols Interface) can be found at the figure below:

There are some screenshot while running this small utility/proof of concept.

That’s it. You killed it !

Few days ago, Peter Vreugdenhil twitted a one-line WinDbg command to detect if ASLR (Address Space Layout Randomization) is used by the current process and its Dlls.

The problem with the !for_each_module command is that sometimes, it will list drivers instead of dlls of the current process. In other words, you might have a different output from using the “!dlls”. Why ? I’ve no idea, people in charge of Microsoft WinDbg are getting lazy, last version of WinDbg is from February 2010 – hopefully they are going to release an update soon.

Anyway, since this command also has hardcoded offset I rewrote a similar WinDbg script to check every process and dll of the System. This script is using kernel variables so it can be used only during a kernel debugging sessions or a post-mortem dump analysis.

As a reminder the flag IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE (0×40) from DllCharacteristics inside the executable means that the executable is going to use the ASLR feature, and the flag IMAGE_DLL_CHARACTERISTICS_NX_COMPAT (0×100) is set if the executable is compatible with the NX (No eXecute) feature.

More information can be found about it on Robert Hensing blogpost on Microsoft SWI blog, and in Mark Dowd and Alex Sotirov BH 2008 presentation.

The script below can be modified easily if one day you want to retrieve specific information inside the header of every user-land module loaded in memory.

$$
$$ MoonSols SARL (C) 2011
$$ http://www.moonsols.com
$$ Author: Matthieu Suiche (msuiche)
$$

r $t0 = nt!PsActiveProcessHead

$$  Iterate over all processes in list.
.for (r $t1 = poi(@$t0);
      (@$t1 != 0) & (@$t1 != @$t0);
      r $t1 = poi(@$t1))
{
    r? $t2 = #CONTAINING_RECORD(@$t1, nt!_EPROCESS, ActiveProcessLinks);

	.process /p @$t2

	.printf "\n	+> Process Name = %ma\n", @@c++(&@$t2->ImageFileName)

	.if (@$peb == 0) { .continue }

	r? $t3 = @$peb->Ldr->InLoadOrderModuleList.Flink

	.for (r $t4 = poi(@$t3);
		  (@$t4 != 0) & (@$t4 != @$t3);
		  r $t4 = poi(@$t4))
	{
		r? $t5 = #CONTAINING_RECORD(@$t4, nt!_LDR_DATA_TABLE_ENTRY, InLoadOrderLinks.Flink);

		r? $t6 = @$t5->DllBase;
		.if (@$t6 == 0) { .continue }

		r? $t7 = ((nt!_IMAGE_DOS_HEADER *)@$t6)->e_lfanew;
		r $t8 = @$t6 + @$t7;
		r? $t8 = (nt!_IMAGE_NT_HEADERS *)(@$t8);

		r? $t9 = @$t8->OptionalHeader.DllCharacteristics

		$$ IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE (0x40)
		.if ((@$t9 & 0x40) == 0)
		{
			.printf "	-> NO ASLR 0x%p %128msu\n", @@c++(@$t5->DllBase), @@c++(&(@$t5->FullDllName))
		}

		$$ IMAGE_DLL_CHARACTERISTICS_NX_COMPAT (0x100)
		.if ((@$t9 & 0x100) == 0)
		{
			.printf "	-> NO NX 0x%p %128msu\n", @@c++(@$t5->DllBase), @@c++(&(@$t5->FullDllName))
		}
	}
}

Script can also be found on pastebin.

After talking with few people who expressed their limitations with current Windows memory dumpers, I decided to release MoonSols DumpIt publicly.

MoonSols DumpIt is a fusion of win32dd and win64dd in one executable, no options is asked to the end-user. Only a double click on the executable is enough to generate a copy of the physical memory in the current directory. DumpIt is the perfect utility to be deploy on a USB key for quick incident response operations. Fast, small and portable.

Check @lennyzeltser video on how to use MoonSols DumpIt !

Source: http://blog.zeltser.com/post/7952715630/memory-acquisition-with-dumpit-for-dfir

Today, I finally decided to release the first public version of MoonSols HyperTaskMgr.

What is MoonSols HyperTaskMgr ?

It’s a new generation Task Manager for IT Professionals to manage Windows Virtual Machines running under Microsoft Hyper-V R2 Hypervisor. HyperTaskMgr is running on the host, it’s easily deployable (One executable and one dll in total). You don’t need to install anything inside the target windows virtual machines.

This first version of MoonSols HyperTaskMgr allows the user to:

• Display every processes running in each windows virtual machine, as well as each attached dll of any process.
• Kill any Process
• Provide SYSTEM privilege on the fly of any process
• Unlock the virtual machine if you don’t remember you password
• You can also mitigate exploitation of processes against kernel exploits using the “Protect against null page attack” feature.

The protect against null page attack feature is based on Tarjei Mandt research. You can find more information about his research on his personal (and pretty cool) blog at the following address : http://mista.nu/blog/2011/07/07/mitigating-null-pointer-exploitation-on-windows/

For those who are familiar with Microsoft EMET (Enhanced Mitigation Experience Toolkit), you can compare the last feature to a “Kernel-Mode” version of what EMET is doing for userland processes. Except it’s going to prevent the exploitation of kernel bugs to avoid security risks such as privilege escalation.

Contact: support@moonsols.com for bug reports or questions. If you are CEO of VMWare and you are jealous because you don’t have a such software for your products and because this utility is only for Microsoft Hyper-V, you can contact msuiche@moonsols.com

Windows Developer Preview WDK contains the new version of WinDbg which is 6.2.8102.0 (previous version was 6.12.0002 – it seems that Microsoft decided to change the version name to the corresponding NTOS kernel version).

Two interesting commands had been introduction in !reg
kd> !reg

reg              - Registry extensions
querykey|q - Dump subkeys and values, if key is cached
keyinfo - Dump subkeys and values, given knode

Unfortunately, Microsoft still didn’t patch an existing problem I reported one year ago when enumerating subkeys with !reg subkeylist and this issue is also present in those new commands. I’m wondering if the Microsoft debug team really debugged the debugger… Anyway, people who attended to my forensic & incident response training course already know the source of the problem – but I’m gonna explain it here for people you didn’t attended to it yet.

Basically the bug is the following, when enumerating subkeys the first subkeys is going to be displayed n times.

Let's look at the following example to illustrate the bug:
kd> !reg querykey \REGISTRY\USER\S-1-5-21-789336058-1844823847-839522115-500\SOFTWARE\ADOBE\ACROBAT READER

Found KCB = e1ca95f0 :: \REGISTRY\USER\S-1-5-21-789336058-1844823847-839522115-500\SOFTWARE\ADOBE\ACROBAT READER

Hive         e1de0b60
KeyNode      c6b3c8a4

[SubKeyAddr]         [SubKeyName]
c6b3c914             6.0

Use '!reg keyinfo e1de0b60 ' to dump the subkey details

[ValueType]         [ValueName]                   [ValueData]
Key has no Values
kd> !reg keyinfo c6b3c914
Cannot get signature for KeyNode 00000000
kd> !reg keyinfo e1de0b60 c6b3c914
\Software\Adobe\Acrobat Reader\6.0

[SubKeyAddr]         [SubKeyName]
c6b3cb84             AdobeViewer
c6b3cb84             AdobeViewer
c6b3cb84             AdobeViewer
c6b3cb84             AdobeViewer
c6b3cb84             AdobeViewer
c6b3cb84             AdobeViewer

Use '!reg keyinfo e1de0b60 ' to dump the subkey details

[ValueType]         [ValueName]                   [ValueData]
Key has no Values

Note, if the key or subkey does have values – the new command will also display its content like in the following example when I’m displaying the content of the registry key of the Rustock driver.

kd> !reg querykey \REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\PE386

Found KCB = e1055b00 :: \REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\PE386

Hive         e1035b60
KeyNode      cd801d84

[SubKeyAddr]         [SubKeyName]
cd801ddc             Security

[SubKeyAddr]         [VolatileSubKeyName]
e1a6c3dc             Enum

Use '!reg keyinfo e1035b60 ' to dump the subkey details

[ValueType]         [ValueName]                   [ValueData]
REG_DWORD           Type                          1
REG_DWORD           Start                         1
REG_DWORD           ErrorControl                  0
REG_EXPAND_SZ       ImagePath                     \??\C:\WINDOWS\system32:lzx32.sys
REG_SZ              DisplayName                   Win23 lzx files loader
REG_SZ              Group                         Base
REG_BINARY          ExtParam                      1d de 5b cb 93 e0 b1 af 00 00
kd> !reg keyinfo e1035b60 e1a6c3dc

\ControlSet001\Services\pe386\Enum

[ValueType]         [ValueName]                   [ValueData]
REG_SZ              0                             Root\LEGACY_PE386\0000
REG_DWORD           Count                         1
REG_DWORD           NextInstance                  1
kd> !reg keyinfo e1035b60 cd801ddc

\ControlSet001\Services\pe386\Security

[ValueType]         [ValueName]                   [ValueData]
REG_BINARY          Security                      01 00 14 80 90 00 00 00 9c 00 00 00 14
                                                  00 00 00 30 00 00 00 02 00 1c 00 01 00
                                                  00 00 02 80 14 00 ff 01 0f 00 01 01 00
                                                  (...)

The explaination regarding the bug can be found in the following PDF document : Registry Bug (121)

An update for MoonSols Windows Memory Toolkit is on its way ! The update includes Windows 8 support, and a fusion between win32dd/win64dd/DumpIt in one utility.
If you wish to be part of the beta-testing program please send an email at support@ moonsols.com and if you wish to pre-order please contact sales@ moonsols.com.

Kernel-mode callbacks routines are used by various drivers, they are commonly used by malwares or third party products because they make possible to “hijack” critical functions without having to patch the SSDT (System Service Dispatch Table) which is protected by PatchGuard on x64 version of Windows. Moreover, it avoids to patch the prolog code of the target function.

This article is a short introduction to what functions are registering callback and where they are stored. Windows Kernel is storing callback functions using different methods, some of them can be retrieved in a table like notify routines, or via a linked list like Bug check callback functions.

The most infected callback table is the “Load Image” (PspLoadImageNotifyRoutine) callback table, which is infected by TLD4 Rootkit as highlighted by Frank Boldewin.
PspLoadImageNotifyRoutine, PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine are part of the Process Manager and entries can be registered using PsSetImageLoadNotifyRoutine(),  PsSetCreateProcessNotifyRoutine[Ex](), and PsSetCreateThreadNotifyRoutine() functions.

PspNotifyEnableMask is updated when a table is used, each lower bit correspond to a callback table of the process manager.

Create process notify routines are called two times, one time during the creation of the first/main thread in PspInsertThread(), and a second time during the destruction of the process in PspExitProcess().

Create thread notify routines are  called each time PspInsertThread() is invoked by the creation new thread and also each time PspExitThread() is invoked during the destruction of a thread.

And finally, load image notify routines are invoked by the Memory Manager each time an executable image is loaded in memory.

Configuration Manager (Registry) call back functions are managed by the double link list called CallbackListHead on Windows Vista+ and by the callback table CmpCallBackVector in NT 5 and below. These callbacks are registry by CmRegisterCallback() function. As highlighted by Scott Noone on his personal blog.

Bug checks (B.S.O.D.) have three linked list dedicated to callbacks: KeBugCheckCallbackListHead, KeBugCheckReasonCallbackListHead, and KeBugCheckAddPagesCallbackListHead introduced in Vista+. These callbacks functions are sometimes patched by rootkit such as Rustock.C to remove “sanitize” the physical memory before the generation of a Microsoft crash dump during the B.S.O.D. as highlighted by Frank Boldewin in his Hack.lu presentation in 2008. Please notice that these callback functions are not called during the generation of a Microsoft crash dump using MoonSols WinDD utility.

Entries in KeBugCheckCallbackListHead are inserted by KeRegisterBugCheckCallback() function and entries in KeBugCheckReasonCallbackListHead are inserted by KeRegisterBugCheckReasonCallback() functions.

NMI (Non-maskable interrupt) callbacks are managed by the double link list called KiNmiCallbackListHead and registrable by KeNmiRegisterCallback() – These callbacks are invoked each time KiHandleNmi() function is invoked, and this function is called every time the hardware interruption 2 occurs (INT2, nt!KiNmiInterruptStart()).

AlpcpLogCallbackListHead is managed by Windows ALPC (Advanced Local Procedure Call) Manager. In theory only the internal kernel function AlpcRegisterLogRoutine() can insert an entry in this link-list, and this ALPC callbacks are invoked every time an ALPC log message is sent.

EmpCallbackListHead is a linked list managed by Errata Manager, only the Windows Kernel can have access to it to register entries.

Some of these callback tables, linked-list are only available from Windows Vista symbols (e.g. AlpcpLogCallbackListHead, KiNmiCallbackListHead).

The Windows Debugger script is available below, to run it use the following command:[box type="info"]kd> $><”[Drive]:\[FullPath]\callbacks.txt”[/box]

This WinDbg script is working with every version of Windows from XP to 7, and for X86, x64 and IA64 architectures. Example of output can be found here.

Download Windbg script

MoonSols Ltd is a privately held information security company specialized on passive and active protective intelligence using tailored technologies and services delivering a range of products and services to businesses, organisations and individuals around the world.

MoonSols 2.0 is here to provide a newer and fresher view on security.  Those who knew MoonSols before probably noticed the re-branding, and are probably excited by the new release of our Incident Response/Forensics toolkit.

MoonSols Windows Memory Toolkit 2.0

MoonSols Windows Memory Toolkit is a powerful toolkit containing all the utilities needed to perform any kind of memory acquisition or conversion during an incident response, or a forensic analysis for Windows desktops, servers or virtualized environment. The version 2.0 is a refresh and updated version of our software to reply to the evolving needs of our clients and assist them to deliver in a strategic and professional way.

DumpIt
Many of you probably are also probably familiar with win32dd and win64dd, those applications belong to the past and only DumpIt remain to avoid any confusion. As part of MoonSols Windows Memory Toolkit 2.0, DumpIt is now a merged version of win32dd and win64dd for practical reasons.

As you can see now DumpIt has all the features from win32dd/win64dd, including new options such as compression capabilities (LZNT1), and encryption (RC4).

And also provide the option to the user to change the device name and driver name, by just renaming the executable in some random name. And the executable is obviously also scriptable as requested by many in the previous version of DumpIt.

Hibr2Bin
Another notable feature is the capacity to retrieve the orphans memory chunks from an hibernation file present because of a previous hibernation via the /slack option of Hibr2Bin.

MoonSols is launching a mailing-list to discuss about Digital Forensics, Incident Response and Memory Forensics and increase security awareness.

Subscription can be done at the following address:
https://groups.google.com/a/moonsols.com/forum/#!forum/dfir-list

Or by simply sending an email at the following address: dfir-list+subscribe@moonsols.com

MoonSols is delivering a 5-day advanced incident response and memory forensics training course in Dubai, UAE on 18-22 May, 2014.

You can already pre-book your seat for the class or inquiry by contacting sales@moonsols.com

Training is based on MoonSols products, and designed to teach to experts how advanced and targeted attacks work in order to significantly improve incident response expertise.

The training course includes a copy of MoonSols Windows Memory Toolkit – Consultant Edition.
At the end of the 5-day training course, attendees will be certified “MoonSols Windows Memory Incident Response Expert”.

Abstract

Attacks are more[1][2] and more sophisticated and everybody[2][3][4] can be a victim from those highly technical attacks that anti-virus won’t protect you from. This is why security experts need to know more about what the attackers are targeting and trying to modify on a vulnerable system.

[1] MTN investigates NSA hack of its systems September 2013
[2] Belgacom Attack: Britain’s GCHQ Hacked Belgian Telecoms Firm September 2013
[3] French agency caught minting SSL certificates impersonating Google December 2013
[4] Microsoft revokes the digital signatures for nine private, third-party UEFI modules that could be loaded during UEFI Secure Boot. December 2013

Description

In this live incident response and forensics course, students will learn how to use software-based acquisition methods (with MoonSols utilities such as MoonSols Windows Memory Toolkit, and even Windows itself) and the clockworks of different full memory dump file format (Microsoft Windows hibernation file, crash dump, and raw dump).
Students will also learn the difference between hardware and software acquisition methods. The course will then cover how to do perform advanced analysis of these dumps, such as the hibernation file, using free Microsoft Debugger WinDbg.
The analysis part of the training will explain the core points of Windows Kernel such as processor memory management, Windows memory and process management internals but also WinDbg SDK and scripting, and how to identify and retrieve suspicious applications and how they proceed.

Trainer: Matthieu Suiche.