Backdoor.Win32.UltimateDefender Reversing

From UIC

Backdoor.Win32.UltimateDefender.gtz - Reversing

Backdoor.Win32.UltimateDefender Reversing
Author:	Evilcry
Email:	evilcry@virgilio.it
Website:	http://evilcry.netsons.org
Date:	22/12/2008 (dd/mm/yyyy)
Level:
Language:	English
Comments:

Tools

• Ida
• OllyDbg
• Explorer Suite - CFF

Essay

install.exe presents the typical structure of an Medium Evoluted Malware, with basical Obfuscated-Dummy Code, some layer of Encryption decoded at Runtime and Custom Hash Functions used as Integrity Check. We can also see an intersting technique that retrieves API's Addresses OnDemand through a series of hardcoded values that corresponds to some API, the correspondent API Address is computated at runtime and chosen in function of the Hardcoded Value.

In a second phase of the malware evolution a second similar way is used to build a static tabbed IAT. This technique is used to make Reverse Engineering longer and to hide the real used APIs from static analysis such as Disassemblers and IT Viewers, we will follow a Live Approach so in a few moments we will be able to detect suddenly the API calls ;)

install.exe is also the infection vector of a Medium Level Rootkit, we will Dissect both .exe (install.exe and brastk.exe) and the rootkit (figaro.sys.

Let's begin with preliminary checks!

From what we can see by a first inspection with CFF, the executable is not packed, presents a minimal IT that is necessary to call all other APIs and does not have any embedded resources, indeed executables are stored in an enciphered way into install.exe.

In this way, static analysis is deceived cause the call 40101D+1 “breaks” opcodes placed at 0040101D, this acts as basical SMC, indeed the real instructions are:

Let's see call 00401104:

Inside call sub_4010AF

As we can see this call implements a custom algorithm that hardcodes a string into a dword. When this call is completed we come back to the previous call, that by using a cycle, searches about a predeterminated DWORD (6AE69F02h), if we insert a breakpoint, immediately after the cycle, we can see that EAX contains the BaseAddress of “kernel32.dll”

At the end of the computation, EAX is equal to GetModuleHandleA, indeed by exiting from call 00401104 we can see:

This piece of code is easy to understand, thanks to GetModuleHandle, malware identifies a piece of its PE structure, precisely the portion of bytes proper of the .text section and next calls the already seen BuildAPI_Address function:

VirtualProtect is going to make Writeable the portion of bytes that surely will be subject to a Decryption Operation (cause .text is not +Writeable)

Let's see call 0040287E..

(Code is cleared from all NOPs between the instructions)

This piece of code, decrypts code after 004029A2 location, so be careful and don't insert breakpoints after JNZ or code will be wrongly decoded, here the correcty decoded routine

Inside call EBP:

This routine decrypts another piece of code, after computing this execution jumps to the core decryption procedure, that starts here:

at 00402A31 we place a Conditional Breakpoint that verifies the condition “ECX == 0”, when condition is verified we can see that suddenly after this jump the code changes and another big decryption loop is performed

We insert also here a Conditional BP “ECX == 0”

Code here is clear, we are in front of a nested loop, first loop repeated 2716h times for 391h times (exernal loop) for a total of 2716*391 iterations, simply we insert a Conditional BP “EDX == 0”. After that the condition is verified code immediately after 00402A83 changes as follows

this piece last piece of code locates kernel32.dll with the already seen procedure and with the final if checks if it's really kernel32.dll the module founded.

The first searched API is VirtualAlloc, this function is executed reached indirectly by using a RET instruction as trampoline:

After allocating an Executable Portion of Memory

a block of code is copied into this location and with a jmp eax, execution flow jumps into the allocated piece of memory:

from the block computation is obtained a DWORD that could be seen as an hash value, indeed by exiting from CALL 00840026, we can see:

In other words CALL 00840118 is an indirect way to execute an API, in this first case is called GlobalAlloc. After GlobalAlloc

CALL 0084012C Assembles two new executable, one used for brastk.exe and another for figaro.sys and another Integrity Check is

Main Procedure:

In this way the application builds an IAT, other APIs imported are:

“Advapi32.dll”
RegQueryValueA, AdjustTokenPrivileges, LookupPrivilegeValue, OpenProcessToken, RegSetValueEx, RegOpenKeyExA-

“Kernel32.dll”
GetVersionExA, GetLastError, CreateMutexA, CloseHandle, WriteFile, lstrlenA, CreateFileA, lstrcatA, lstrcpyA, GetEnvironmentVariableA, ExitProcess, HeapFree, HeapAlloc, GetProcessHeap, GetCurrentProcess, GetProcAddress, LoadLibraryA, MultiByteToWideChar, CreateProcessA, MoveFileExA, CopyFileA, GetWindowsDirectoryA, Sleep, GetSystemDirectoryA.

“Shell32.dll”
ShellExecuteA.

After building the IAT, ends the work of the Allocated Memory Code, and execution comes back to the normal flow:

After exiting from this call

If Mutex creation fails malware Exits, else execution follows here

Its builded the path C:\WINDOWS\System32\brastk.exe

It's really clear what does this call, creates a file into /system32 called brastk.exe and next takes from Malware Process's Heap the previously generated brastk.exe code

In this way brastk.exe is executed at every Windows startup.

Malware here assembles the path C:\WINDOWS\System32\dllcache\figaro.sys

and next as for brastk.exe is created a system driver called figaro.sys placed at C:\WINDOWS\System32\dllcache\figaro.sys, to see this file you need to enable the +h view of files causes the directory is hidden.

assembles C:\WINDOWS\System32\drivers\beep.sys and next

Here we can see an original operation, malware loads sfc_os.dll that acts as ... and imports entry #5 that receives as parameters, the most intersting is the path of beep.sys "C:\WINDOWS\system32\drivers\beep.sys"

sfc_os.dll is a dll that contains functions used to monitor system files for validity. It belongs to the Microsoft Windows Environment.

sfc_os.#5 corresponds to PfnSetFileException SetFileException that is used to disable WPF (Windows File Protection)

After performing this operation:

Assembles C:\WINDOWS\System32\dllcache\beep.sys

In this way, beep.sys System Driver is infected with the content of figaro.sys, beep.sys is one of drivers loaded by default at every Windows start, so UltimateDefender Rootkit is automatically loaded by Windows.

This call adjust Security Token Privileges of the malware itself and exits.
→ CALL 004012E0
Generates a file called delself.bat that deletes the malware itself.

Here ends install.exe infection phase, if all goes ok the system will be rebooted and brastk.exe executed when OS is loaded, so is the time to analyse brastk.exe =)

brastk.exe Dissection

When computer has restarted we are adviced that the PC has been infected, but this is a classical fake advice generated by AntivirusPro2009..

brastk.exe present a structure identical to install.exe, indeed during the dissection we will see the same API Importing Technique and other various similarities.

As you can see the execution architecture/flow is equal to install.exe, for reasons of practicity I jumped the analysis of the same pieces of code and I report here only a basical descryption of what brastk.exe does.

After Allocating a Portion of memory, the same operations of install.exe are performed, an IAT is builded and some executable codes are uncompressed and next execution comes back to brastk.

Some Registry Key Entries are created..

"\AntivirusPro2009\AntivirusPro2009.exe"

The path C:\programmi\\AntivirusPro2009\AntivirusPro2009.exe is assembled

A Mutex is created so that only one copy of the trojan runs at a time, if Mutex exist execution ends else continues. This is the next call that need to be analysed:

This Registry entry is filled with values: 1200, 1201, 1208, 1608, 1804, 2500 and this is iterated 6 times:

1. SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\
2. SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1\
3. SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\2\
4. SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3\
5. SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4\
6. SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\5\

Other registry entries are created

In the same way are created other Reg Entries:

In this way, UltimateDefender disables Firewall and Security Updates

The trojan adds the following registry entries to modify the user's Internet Explorer Home Page and Search Page:

Here some information on UltimateDefender Backdoor Capabilities:

after creating these files

Is opened Extensible Cache and asked History Infotmations relative to three dates:

• MSHist0120080815-2008-08-16
• MSHist0120080815-2008-08-17
• MSHist0120080815-2008-08-18

When victim launches Internet Explorer, a malicious website appears with a fake security alert that invites user to install an antivirus (the malicious application)

here the malicious URLs used:

These domains are used to receive instructions regarding where to download additional malware.

Figaro.sys Rootkit Analysis

As you should remember, install.exe creates also a system driver called figaro.sys, thanks to sfc_os WPF is disabled and the original beep.sys is infected with the malicious content of figaro.sys, so we have to reverse beep.sys.

Rootkit is identified as: Backdoor.Win32.UltimateDefender.a, let's decompile it!

Device beep is created but if it already exists driver exits

here driver associates a series of routines

Uses KeServiceDescriptorTable to locate NtQuerySystemInformation..

PsSetLoadImageNotifyRoutine represents the core part of figaro.sys, indeed this function registers a driver-supplied callback that is subsequently notified whenever an image is loaded for execution. In this way fake beep.sys became able to “know” when a program is executed, and to make a series of check on it (we will see this after figaro.sys complete analysis).

Here is created a file into SystemRoot called karna.dat

Let's see the DereferredRoutine:

Simply performs a beep, (beep.sys does this) by calling HalMakeBeep. Now we put a breakpoint for PsSetLoadImageNotifyRoutine's NotifyRoutine and after release debugger to see what happens when an image is loaded for execution.

Let's Reverse the NotifyRoutine:

We immediately understand that PIMAGE_INFO Struct contains a list of informations releated to the Image Loaded and one of them is passed as parameter for call sub_12408, other two parameters are Handle and ProcessHandle.

->if jump is not taken, the loaded process comes from the list, and is firstly Open with ZwOpenProcess and next Terminated woth ZwTerminateProcess. In this way dangerous (for malware) applications are suddenly killed =)

if the process loaded isn't into list figaro.sys checks if is a system file such as winlogon.exe csrss.exe etc..

at the end of the process creates registry entry for karna.dat

Here ends the work of figaro.sys =)

This is the list of killed executables:

Karna.dat is Backdoor.Win32.Small.gjm that will be analysed in a succesive paper =)

Note Finali

The paper ends here, hope you enjoied it!

Regards, Giuseppe 'Evilcry' Bonfa'

Disclaimer