VBKlip Banking Trojan Goes Man-In-The-Browser
VBKlip Banking Trojan Goes Man-In-The-Browser VBKlip malware was first introduced by Cert Polska back in 2013. It started out as a simple yet effective threat, targeting Polish on-line banking users. Its first reincarnation intercepted clipboard data. Once a user used the “copy-paste” Windows functionality, the malware changed the data being copied. It looked forIBAN(International Bank Account Number)string format in the copied data and swapped it with its own hard codedIBAN. Recently, my colleaguePavel Asinovsky and I witnessed a significant evolution in the malware, as it followed the footsteps of well-known financial threats such Zeus and Neverquest by resorting to man-in-the-browser techniques. The current version’s infection scheme starts with a downloader which downloads two files: wmc.exe and .windows.sys (which is a dll) to %programdata% as described in Cert Polska's blog. The malware can survive a reboot thanks to the scheduled task it creates in windows task scheduler. This method is quite uncommon as most malware use runkeys in the registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) in order to remain persistent. After the malicious .windows.sys dll is loaded into memory, it tries to communicate with several domains. The expected payload being another executable which is responsible for the core functionality. Each component is downloaded separately and has a different task in the whole control flow of the fraud. By dividing the operation into several modules which depend on Command and Control server communication in order to download the next component, the fraudsters make the attack harder to analyze as it is harder to obtain all of the components involved in the fraud. The core module starts by creating a thread whose sole purpose is to check the running process list every 3 seconds. Each process name is compared to a hard coded list of browser names, while the targeted browsers are the three major browsers: Internet Explorer, Firefox and Chrome. Once the malware identifies a process of interest, it writes its malicious code into the process' memory and executes it. The malware uses a mutex of the format __NTDLL_CORE__<processID> for synchronization. This is a significant improvement from its previous version that lacks synchronization and could only handle one running browser process. Now it swaps the IBAN in all running browser processes thanks to the mutex and the injection. It only injects to processes that don't have the mutex, and this mutex is created in every newly injected browser process. The injected code hooks several key functions. It hooks communication related functions in order to intercept the IBAN and swap it before the request leaves the browser. The browser functions are: HttpSendRequestA HttpSendRequestW InternetWriteFile PR_Write IBAN swapping is done in two steps. First, the Host header is compared to a hard-coded bank name. If the match is successful, the hard-coded <CreditAccount> HTML tag is searched throughout the request body and the content is swapped if it matches the IBAN pattern. Otherwise, it will scan the entire request body for the IBAN format and swap it in every instance. The fact that a backup plan is used in case the bank name does not match, shows that this features is probably still being tested in the field. This feature bares great resemblance to Zeus “man-in-the-browser” mechanism where bank names are matched against a configuration, once the request is sent by the victim. Although this approach to committing fraudulent transactions is pretty simplistic in comparison with its well-known counterparts in the wild, it is nonetheless successful, and it is safe to assume that the malware’s evolution has yet to reach its final form. Sample MD5: A86BD976CE683C58937E47E13D3EB448