[General View]
Articles,links about him
Main features:
- infect the drivers from nt!PsLoadedModuleList
- ability to hide rootkit files
- pseudo "modularity" architecture
- written in disgusting style :D
As already noted EP_X0FF the code was not changed since March 2011
Here bin-diffing:
Rootkit works only on x86 systems, but not so long ago he got a bootkit module for x64 Windows versions.
[Startup Cases]
- DriverEntry start with empty RegistryPath:
call payload function - DriverEntry start with not empty RegistryPath ,but not from system32 directory:
call infect and payload functions,not using direct inject usermode modules - DriverEntry start with RegistryPath and include system32 directory [start like infected file]:
create system thread (PsCreateSystemThread) and in that thread,call infect and payload functions.
Code in infected driver load original rootkit,which is stored on this path:
\\systemroot\\system32\\c_%4.4x%d.nls
[name generate via md5(ZwQueryVolumeInformationFile[VolumeCreationTime])]
[name generate via md5(ZwQueryVolumeInformationFile[VolumeCreationTime])]
[Hooks]
At first Simda is trying to establish own debugging interface by overwriting KiDebugRoutine pointer to its callback function.
(he get this pointer with help of signature-based search in exported function KeEnterKernelDebugger)
Accordingly all the hooks of the rootkit ,implemented via software breakpoints int3(0xCC)
For intercepted functions he create structures,that it stores in an array of pointers.
struct array_hook_struct
{
pvoid array_hook_struct_pointer;
int size_array;
};
Where:
array_hook_struct_pointer - ptr to array of hook_struct
size_array - size of that array
Main and most important hook structure,looks something like here:
struct hook_struct
{
int init_boolean;
struct array_hook_struct
{
pvoid array_hook_struct_pointer;
int size_array;
};
Where:
array_hook_struct_pointer - ptr to array of hook_struct
size_array - size of that array
Main and most important hook structure,looks something like here:
struct hook_struct
{
int init_boolean;
int hook_type;
int reserved_1;
pvoid hook_function_origin_addr;
pvoid hook_handler_addr;
int reserved_2;
pvoid detour_addr;
pvoid nop_chain_addr;
};
};
So inside rootkit debugging interface,when a breakpoint exception has been occurred ,he dispatch them and redirect control flow to eip of detour function.
Here how this look with help of hex-rays:
What exactly Simda hooks?
The lower driver IRP_MJ_INTERNAL_DEVICE_CONTROL(IRP_MJ_SCSI) function,of hard disk DR0 device.
Hook-handler checked all SRB_FUNCTION_EXECUTE_SCSI request.
This hook provide :
- to replace the contents of the infected driver to original clean code
- to replace the contents of the original file rootkit(\\systemroot\\system32\\c_%4.4x%d.nls)by the contents of the biggest .nls file in the directory(\\systemroot\\system32\\)
Hook of NtResumeThread, provide inject of Simda module into usermode processes
[Modularity]
As I mentioned early,Simda support modules architecture,which work in ring0 and in ring3.
r3 modules injected into the user-mode shell-process (explorer.exe)
r0 modules copied to the allocated memory.Then Simda created manually DRIVER_OBJECT struct and for the field DRIVER_OBJECT.DriverSection value is taken from the original
driver object \Driver\Disk (with ObReferenceObjectByName [* IoDriverObjectType]).
driver object \Driver\Disk (with ObReferenceObjectByName [* IoDriverObjectType]).
Some of the names of the modules within the sample
'ModuleR0Pdm'
'ModuleR0PdmCfg'
'ModuleR3Antimalware'
'bcs'
At ITW me was found only the implementation of the r0 module ModuleR0Pdm and r3 bcs module
'ModuleR0Pdm'
'ModuleR0PdmCfg'
'ModuleR3Antimalware'
'bcs'
At ITW me was found only the implementation of the r0 module ModuleR0Pdm and r3 bcs module
<ModuleR0Pdm>
The main task of this module, the creation of web-redirect config, hooks in NDIS and spoofing in network packets ip4 (UDP[DNS], TCP[http] protocols).
The path to the config file:
swprintf(path_conf, L"\\systemroot\\temp\\%d.tmp", md5(VolumeCreationTime)[0x2] ^ md5(VolumeCreationTime)[0x0] ^ 0x58589954);
Config strings encrypted with trivial alg,that looks like here:
for (i=0;i < length_str ; i++)
{
str[i]^=key_xor[i%sizeof(int)];
key_xor[i %sizeof(int)]^=str[i];
}
{
str[i]^=key_xor[i%sizeof(int)];
key_xor[i %sizeof(int)]^=str[i];
}
In kernelmode.info article about Win32/Simda you can also download my web-redirect config decrypt script.
Hooks module installed in all structures NDIS_OPEN_BLOCK (NDIS_MINIPORT_BLOCK->OpenQueue)from all miniport drivers except intermediate drivers and drivers with media type NdisMediumWan,NdisMediumCoWan.
NDIS_OPEN_BLOCK.ReceiveHandler
NDIS_OPEN_BLOCK.TransferDataHandler
NDIS_OPEN_BLOCK.TransferDataCompleteHandler
NDIS_OPEN_BLOCK.ReceivePacketHandler
NDIS_OPEN_BLOCK.ReceiveCompleteHandler
NDIS_OPEN_BLOCK.WanSendHandler
NDIS_OPEN_BLOCK.SendCompleteHandler
NDIS_OPEN_BLOCK.SendPacketsHandler
The system hooks module supports the NDIS versions 5.1;6.0;6.1;6.20
Installed hooks:
Here how look the dns-spoofing in action,with google.com example:
[Detection example]
[Conclusion]
Nothing special here,i am just believe that this old shit will never rise again.
See you in hell Win32/Simda
thx for reading.
P.S.
Found error?Hate me?
Please say it to me! ;)
------------------------------------------------------------
Manipulate the pulse, the pattern, the beat
Dominate the world
