SHA1: FA40B39B5E3755A3AB58634DBF0BAF4B0E0E3659
I obtained the sample from ANY.RUN. The creation date of the sample is 2011, but it was uploaded to VirusTotal recently. After initial analysis, I found that it’s a variant of the banking trojan iBank.
Note: My recommendation is to open IDA FREE/Pro or any other favorite disassembler or debugger (like x32dbg) inside a VM and analyze the sample alongside me.
On ANY.RUN, we observe what the malware does: it injects Explorer.exe, which in turn injects windanr.exe, dwm.exe, and taskhost.exe. It also attempts to download a key.bin file from various sources, but none of them are currently functional.
Now that we understand what the malware does, let’s examine how it accomplishes this.
Note: I’ve renamed functions after analysis for clarity.
At 0x0E22D30, it calls disable_CaHIPS to turn off CA HIPS by 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 a control message to the ____AVP.Root window. According to a Virus Bulletin article, this is intended to block Kaspersky Anti-Virus.
The disableAOutpostFirewall function exploits a vulnerability in Agnitum Outpost Firewall to disable the firewall.
At AVG_mov_config_file, it renames dfncfg.dat to dfmcfg.dat, and at zero_AVG_confg_, it clears the content of C:\ProgramData\PrevxCSI\csidb.csi.\AVG9\dfncfg.dat. This appears to be an attempt to disable AVG Anti-Virus.
At COM_Firewall_add, it uses the COM object to initialize the Windows Firewall with Advanced Security API (FirewallAPI.dll), which contains functions to manage Windows Firewall settings.
It checks if the firewall is enabled, and if so, adds itself to the authorized applications list. You can find more about this method here.
If the current user is a member of the Administrators group, it adds a task to the Task Scheduler using the COM interface and exits. More about the COM interface of Task Scheduler can be found here.
If the user is not an admin, it uses the Run key for persistence and injects into Explorer.exe; otherwise, it injects into WinLogon.exe. To ensure that only one instance of the malware runs, it uses GlobalAddAtomA/GlobalFindAtomA instead of a Mutex.
If the user is an admin and the path of the malware does not contain the AppPatch string, it calls the AppPatch_t function. At AppPatch_t, it retrieves the volume serial number of the root directory (in my VM, it’s C:/), XORs it with numbers from 0 to 0xFF, and uses the change_values_encrypt__ function to further modify values. The result is applied as the filename to check if it exists under the Windows Defender directory.
It copies the malware to AppPatch/{RandomName}.exe and uses this name to generate data for the 30dfa5f0 key (where 30dfa5f0 is the 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 creation time of the NTFS.sys file.
If the user is an admin, it acquires the SE_DEBUG_PRIVILEGE privilege and injects into winlogon.exe.
The getProc function is straightforward: it receives a process name and returns the process handle.
InjectProc is also simple; it utilizes familiar functions like VirtualAllocEx, WriteProcessMemory, and more about process injections can be found here. It uses CreateRemoteThread to execute code inside another process, which in this case is winlogon.exe (or explorer.exe if the user is not an admin).
The PE_file is embedded within the malware; you can dump it from memory or extract it from the file. You can use the Rip button from Exeinfo PE.
Interestingly, the injected file (which is a .dll) does not have imported functions, indicating that it somehow retrieves function addresses.
It uses the PEB structure of the process to get the base address of the ntdll module.
The sample uses getKernelBase (0x10001000) to get the address of the kernelbase module.
Thus, it has everything it needs to execute its malicious activities.
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 the import table of the second PE and retrieves all necessary function addresses, building the import table:
After that, it jumps to the recently mapped PE via call esi:
The second PE is also embedded within the original PE.
I suspect the second PE has trojan capabilities, but that analysis is outside the scope of the initial injection phase.
Any feedback would be greatly appreciated.