7 minutes read

SHA1: FA40B39B5E3755A3AB58634DBF0BAF4B0E0E3659

I’ve got the sample from ANY.RUN, the creation date of the sample is 2011 but it has been uploaded on VirusTotal just recently. After initial analysis, I’ve found that it’s a variant of banking trojan iBank

NOTE: My recommendation is to open IDA FREE/Pro or any other your favorite disassembler or debugger (x32dbg) inside a VM and analyze the sample with me

On ANY.RUN we see WHAT the malware does, it injects Explorer.exe , Explorer.exe itself injects windanr.exe , dwm.exe and taskhost.exe , it also tries to download key.bin file from different sources, at this point none of them works.

It’s WHAT the malware does, let’s see HOW it does this.

NOTE: I've renamed functions after analysis

At 0x0E22D30 it calls disable_CaHIPS to turn off CA HIPS via sending the corresponding request to the KmxAgent device:

At 0x0E22D35 it calls disableWindowsDefender to disable Windows Defender , you can read more about this method here

After that, it sends the control message to ____AVP.Root window, according to VirusBulletin article, it’s there to block Kaspersky Anti-Virus

disableAOutpostFirewall function uses Agnitum Outpost firewall vulnerability and tries to disable the firewall.

At AVG_mov_config_file it renames dfncfg.dat to dfmcfg.dat and at zero_AVG_confg_ it removes content of C:\ProgramData\PrevxCSI\csidb.csi.\AVG9\dfncfg.dat file, I think it tries to disable AVG anti-virus

At COM_Firewall_add it uses the COM object to initialize Windows Firewall with Advanced Security API ( FirewallAPI.dll ), the API contains functions to manage Windows Firewall settings.

It Checks if the firewall is enabled and if so, adds itself to the authorized applications list, if you wish you can find more about this method here:

If current user is a member of the Administrators group it adds the task to Task Scheduler using COM interface and exits, you can find more about COM interface of Task Scheduler here:

If the user is not the admin, it uses Run key for persistence and injects into Explorer.exe , otherwise injects into WinLogon.exe . To ensure that only one instance of malware runs, it uses GlobalAddAtomA / GlobalFindAtomA instead of Mutex

If the user is admin and path of the malware does not contain AppPatch string, it calls AppPatch_t function. At AppPatch_t it receives the volume serial number of the root directory (in my VM, it’s C:/ ), xors it with numbers from 0 to 0xFF, and uses change_values_encrypt__ function to further modify values, the result is applies as the filename to check if it exists under Windows Defender directory

It copies the malware to AppPatch/{RandomName}.exe and uses this name to generate data for 30dfa5f0 key ( 30dfa5f0 is volume serial number for my VM) under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

It sets the creation time of the malware equal to the NTFS.sys file s creation time.

If the user is admin it gets SE_DEBUG_PRIVILEGE privilege and injects into winlogon.exe

The getProc function is very simple: it receives a process name and returns the process handle:

InjectProc is also very simple, there are our old friends: VirtualAllocEx , WriteProcessMemory , more about process injections here, it uses CreateRemoteThread to execute code inside another process, in our case, it’s winlogon.exe (or explorer.exe if the user is not admin)

PE_file is inside the malware, you can dump it from memory or extract from the file, you can use the Rip button from Exeinfo PE

Interesting about the injected file (which is .dll by the way), is that it does not have imported functions, which means it somehow gets function addresses.

It uses PEB structure of the process to get the base address of ntdll module.

It uses getFuncAddr function to get the address of the desired function, getFuncAddr receives two arguments: the base address of the module, and the hash of the function name

Pseudocode of the getFuncAddr is below, it parses export table of the module and compares the hash of export name with the second argument:

The sample uses getKernelBase (0x10001000) to get the address of kernelbase module:

So, it has everything it needs to do whatever it wants.

What it does is very similar to the previous stage, but in this case, it allocates memory inside itself and copies the content of another PE file there.

It parses import table of the second PE, and gets all necessary functions addresses, it builds import table:

After that it jumps recently mapped PE via call esi :

The second PE is also embedded into original PE

I think the second PE have trojan capabilities, but it’s outside of the initial injection phase:

Any feedback would be greatly appreciated.

Twitter: @_qaz_qaz

Discuss on Reddit