Preface

As we know google did the 3rd party application assurance last few months. Their objective is intend to fight against unknown malicious code embedded in software.

Hidden malicious code history

Metamorphic code (Win32/Simile)  was born on 2002 written in assembly language which target Microsoft software operating system products. As time goes by, the 2nd generation of metamorphic code capable changing what registers to use, changing flow control with jumps, changing machine instructions to equivalent ones or reordering independent instructions.

*Metamorphic code can also mean that a virus is capable of infecting executables from two or more different operating systems (such as Windows and GNU/Linux) or even different computer architectures.

Malware/RootKit infection from software device driver to Smartphone

A revolution of technology world on 2007 driven by Apple iPhone and Android. Thus such a way driven malware and rootkit re-engineering their architecture. As a result, their implant destination not limit on device drive itself. It also includes smartphone 3rd party application.

Part 1 – Microsoft OS products, rooting your software driver technique overview 

An important step lets the hacker do the hook or infiltrate job is to identify the usable memory space.  A parameter so called KeServiceDescriptorTableShadow. Using KeServiceDescriptorTable variable exported by ntoskrnl.exe, we can get the address of KeServiceDescriptorTableShadow variable. KeServiceDescriptorTableShadow is an extension of
KeServiceDescriptorTable variable.

Below syntax get the address of KeServiceDescriptorTableShadow by comparing memories around KeServiceDescriptorTable.

typedef struct _SERVICE_DESCRIPTOR_TABLE { PULONG ServiceTable; // array of entry-points PULONG puCounterTable; // array of counters ULONG uTableSize; // number of table entries PUCHAR pbArgumentTable; // array of byte counts } SERVICE_DESCRIPTOR_TABLE, *PSERVICE_DESCRIPTOR_TABLE;

Below syntax is retrieves its address in different version of Windows.

PSERVICE_DESCRIPTOR_TABLE QuerySDTShadow()
{
 ULONG Index;
 PUCHAR SDTShadow;
 UONG MajorVersion, MinorVersion, BuildNumber;
 UNICODE_STRING &CSDVersion;
 PsGetVersion(&MajorVersion, &MinorVersion, &BuildNumber, &CSDVersion);
 __try
 {
 if(MajorVersion == 5 && MinorVersion == 1) // Windows XP
 SDTShadow = (PUCHAR)((ULONG)&KeServiceDescriptorTable - 0x40);
 else // Windows 2000, or Windows Vista
 SDTShadow = (PUCHAR)((ULONG)&KeServiceDescriptorTable + 0x40);
 for(Index = 0; Index < 0x1000; Index ++, SDTShadow ++)
 {
 KeServiceDescriptorTableShadow = (PSERVICE_DESCRIPTOR_TABLE)SDTShadow;
 if(KeServiceDescriptorTableShadow == &KeServiceDescriptorTable)
 continue;
 if(memcmp(KeServiceDescriptorTableShadow, &KeServiceDescriptorTable, 0x10) == 0 
 && ((UCHAR)KeServiceDescriptorTableShadow->ServiceTable & 3) == 0)
 {
 return (PSERVICE_DESCRIPTOR_TABLE)SDTShadow;
 }
 }
 return NULL;
 }
 __except(1)
 {
 return NULL;
 }
}

Below details on the picture left hand side show you the step how to relies on driver hook into the kernel process. In end-user point of view, there is a simple way to identify the current driver load into your PC or server. You just execute a command fltmc in your MS-DOS prompt. There is not require any assembly language knowledge. It is a simple and direct path to let you know how many 3rd party driver load into the windows kernel. For more details, please refer to right hand side in below picture.

 

Hacker is difficult to find available address space due to ASLR technique. (see below URL for reference)

The enemy of ASLR (Address space layout randomization) – memory leak

Even though ASLR has design limitation might have possibility let hacker implant malware. However a better idea is that take easy way instead of difficult way. A way confirm that it is possible. From technical point of view, ASLR avoid hacker know the actual memory address.  How about run the malicious code driver and ASLR mechanism at the same time (simultaneously).That is pre-install a 3rd party driver with malicious code embedded then load the software driver during operating system startup. The way similar antivirus product using API hooking allows the antivirus to see exactly what function is called.

- Loading drivers
- Starting new processes
- Process executable image
System DLL: ntdll.dll (2 different binaries for WoW64 processes)
- Runtime loaded PE images – import table, LoadLibrary, LoadLibraryEx[1], NtMapViewOfSection

Antivirus software may use SSDT hooking (System Service Dispatch Table hooking) on 32-bit operation.  On a 64-bit system, a KM (kernel module) driver can only be loaded if it has a digital signature. And therefore hacker could be focus on 32 bit OS instead of 64 bit.

How to run 32-bit applications on x64?

In order to maintain complete code separation, running 32-bit code on a 64-bit operating system design with a destinate folder named \Windows\SysWOW64 that is used to store the 32-bit DLLs to meet the design objective. Meanwhile the x64 version of Windows uses the \windows\system32 folder for 64-bit DLLs. Below diagram shown that the WOW64 emulator responsible for file system redirection for several key components of the Windows operating system.

To identify 32 bit and 64 bit environment changes depending on the registry key. For instance, the ‘rundll32’ is point to the specify registry (HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\CurrentVersion\Run).

Therefore it will execute the following command.

C:\Windows\SysWOW64\rundll32.exe

This is the 32-bit version program thus everything will be remapped accordingly (see below diagram for reference)

Above details shown the registry and file redirection mechanism to execute 32 bit application on 64 bit of operating system. It looks fine that application not possible to work with incorrect bits environment since it governance by registry. However a fundamental design architecture looks provide benefits to the hacker (see below diagram for reference):

Above diagram indicated that software device driver module allow 32-bit software driver go thought module (WOW64) communicate with 64-bit Kernel function. So it has possibility go through the software driver then compromise the system. From security point of view, the server or workstation Antivirus processes will keep track all DLL activities on directory (c:\windows\SysWoW64). So what is the malware next action?

Malware next action

A lot of security experts feedback comments on Microsoft OS products. They highlight that a flaw appears on kernel side. Microsoft official announcement was told that it is not a security issue.  The fact is that  malware can use API system call (PsSetLoadImageNotifyRoutine) to trick the OS into giving malware scanners other files. This would allow malicious software smuggling then by evade antivirus monitoring. A hacking technique so called Register load image callback (see below)

PsSetLoadImageNotifyRoutine

How to prevent PsSetLoadImageNotifyRoutine

Microsoft have solution available against register load image callback flaw. Developer can define a minifilter (FltGetFileNameInformationUnsafe) to confirm the routine returns name information for an open file or directory. And therefore it is the way to avoid the fundamental design limitation of API system Call mechanism (PsSetLoadImageNotifyRoutine).

But what is the causes for system developers not intend to use this preventive mechanism.

FltGetFileNameInformationUnsafe allocates it’s own memory for the structure. As a result it will encountered blue screen and system crash once 3rd party software driver not follow the SDLC (software development life cycle).

Alternative type of attack  (This time does not intend to discuss in detail)

A rootkit will create a hidden partition, at the end of the drive, 1 – 10 MB in size and set itself as the boot partition. Hence, the rootkit is already running before Windows loads. This hidden partition will not show up on Windows Disk Management in most cases.

Rootkit categories:

Operation feature

Persistent rootkit is one that is activated every time the system starts up.

Non-persistent rootkit is not capable of automatically running again after the system has been restarted.

Operation mode

User mode: this kind of rootkit hooks system calls and filters the information returned by the APIs (Application Programming Interface)

Kernel mode : these rootkits modify the kernel data structures, as well as they hook the kernel’s own APIs. It compromise the antivirus program at the same time. This is the most reliable and robust way of intercepting the system.

Summary:

Even though your IT infrastructure install full scope of detective and preventive control facilities. The 3rd software driver will broken your security facilities. Perhaps you have SIEM and central log event management product however such malicious activities is hard to detect since it is running in Kernel (Ring 0).  So a standard policy on software usage is critical goal on today cyber technology world. Believe it or not, a 3rd party software driver embedded malicious code can break your great wall.