This post describes the infection process of the latest version of the Bunitu Proxy Trojan as seen delivered by the Neutrino Exploit Kit via a malvertising campaign.
We will start from a high-level overview of the issue and used elements. Then, we will dive deeper in the used techniques of hiding and obfuscating the modules.
What is Bunitu Proxy and why is it dangerous?As its name suggests, Bunitu Proxy is a Trojan that exposes the infected computer to be used as a proxy for remote clients. It is done in a few steps:
- Installs itself on the machine
- Opens ports for the remote connections
- Registers itself in the remote server (clients database) informing about its address and open ports
- Accepts connections coming on the exposed ports and bypasses the traffic
Read more: Who’s Behind Your Proxy? Uncovering Bunitu’s Secrets
How is the infection carried?
Bunitu has been dropped from various exploit kits. On June 10th 2015, as Websense Security Labs described in their post, it was dropped by the Angler Exploit Kit. This time, a similar payload is distributed by Neutrino EK.
Role of Neutrino EKA malvertising from Adcash (they have been notified and the problem is already fixed) redirected users to the Neutrino EK via a compromised site and rotator.
The below screenshot from Fiddler Web Debugger, shows the chain of URLs on the way of dropping the malicious payload: The rotator (.eu domain) does its job of switching to a new sub-domain every few minutes. This technique is often used to bypass blacklists because the malicious URLs are ‘moving targets’: And the landing page carried the exploit:
At this stage, users of Malwarebytes Anti-Exploit were protected - the product detected and stopped the malicious activity.
But if deployed on a vulnerable, unprotected machine, infection followed further - the payload was dropped and deployed.
Payload: Bunitu Proxy
Infection symptomsLooking at the payload from outside, we will see just a typical installer (with an NSIS installer icon).
It pretends to be a legitimate piece of software - scamming an existing product: ManyCam by Visicom Media.
After dropping the malicious DLL (described in details further), the installer tries to run it. Then we witness the attempt of opening the ports for incoming connections.
Windows Firewall alerts about this attempt (it seems that at this level it relies on social engineering - only under Windows XP it managed to suppress these messages to maintain stealth). Also, after the successful setup, when the computer is restarted, the persistent module runs again - triggering a similar alert:
If we see the details of the running process (rundll32) i.e. in Process Explorer, it will reveal the module that has been loaded:
and the open ports (chosen randomly at the time of installation):
If we keep it running for some time, we may even see the clients, that connected via our unwanted proxy (in the below case, july1.exe was used as the name of the installer)
Technical detailsTo hide its real intentions, the installer uses several layers of protection. It takes several modules to run before the malicious DLL (serving as proxy) is revealed. Let's go deeper!
installer.exe-> unpacks and loads: lithiasis.dll, function: Avidness -> decrypts and runs using RunPE technique: stub_unpacked.exe -> unpacks and loads: ynfucvu.dll, function: ynfucvu-> perform all the malicious activitiesinstaller.exe Unpacks several files into %APPDATA%/Local/Temp/ It seems that not all of them play a role in unpacking the payload - some are dropped only to make "noise"
- [random].tmp , i.e.: nsn4CB0.tmp
- [random].tmp/lithiasis.dll (i.e. nse474E.tmp/lithiasis.dll)
lithiasis.dll, Avidness (real name of the module: __Intelerino.dll) - is unpacked and loaded by the installer.exe - is obfuscated - uses files:
- dalookerzmeoajrhja144 - packed list of functions that are going to be loaded in order to do further unpacking
- UncryptedStub._ini - packed executable (I refer to it as: stub_unpacked.exe)
- dalookerzmeoajrhja144 - "dalookerzmeoajrhja144"
- UncryptedStub._ini - "9JKjPZSpEL8uHmkHNlXhwhDc9jRTGN"
[code language="python"] def decode1(data, key, max_key): l = len(key) j = 0 #key index decoded = bytearray() for i in range(0, len(data)): decoded.append(data[i] ^ key[j % l]) if (i > 0): j += 1 if (j == max_key): j = 0 return decoded [/code]
#2 Decrypting PE file result - a new PE file (stub_unpacked.exe):
[code language="python"] def decode2(data, key, max_key): j = 0 #key index prev_j = 0 decoded = bytearray() for i in range(0, len(data)): val = data[i] + prev_j val = ((val ^ key[j]) ^ key[prev_j]) % 256 decoded.append(val) prev_j = j j = j + 1 if (j == max_key): j = 0 return decoded [/code]
After decrypting the new executable: stub_unpacked.exe - it loads it into the memory using "RunPE" technique (unmaps the installer.exe and loads the new PE section by section on it's place).
stub_unpacked.exe Its main role is to unpack from inside the "heart" of the malware: module ynfucvu.dll. It also loads and deploys it. Makes following registry keys (Winlogon Notify): The key 'zinkraxx' is used to uniquely identify the installation. It is made by following simple algorithm: It uses RDTSC (an instruction that reads time-stamp counter into EDX:EAX). Then part of the result (EAX) is processed and writen into a buffer. This buffer is then stored in the registry. After unpacking the DLL it drops it in %APPDATA%/Local folder:
Then, it loads in the memory and enters in the function ynfucvu of ynfucvu.dll - using JMP EAX:
This is the Bunitu Proxy module - malicious part of the full package. It is independent from other modules. Once installed, it is loaded on system startup, using rundll32.exe. The entry point is in the function ynfucvu.
It carries all the network operations - registers the client on the server, opens ports and serves as a proxy. Techniques used by the Bunitu Proxy module haven't changed much from June 10th, when it was described by Websense Security Lab. Even the xor-ed value is exactly same! compare with the WebSense analysis:
This module is slightly obfuscated - i.e. domains used to resolve C&Cs are given in a plain text. Only their addresses are calculated on the fly - to make difficult finding where they are referred. As we see below: the address of the string is calculated on the stack (this DLL is always loaded on the same, predefined base - what makes calculation on the addresses easy).
It is also responsible for creating registry keys used for persistence and tries to be invisible for the firewall - by adding itself to the list of Authorized Applications (but effectiveness of it varies depending on the version of Windows).
Analyzed sampleOriginal sample (installer) md5=542f7b96990de6cd3b04b599c25ebe57 ; payload (ynfucvu.dll) md5=1bf287bf6cbe4d405983d1431c468de7
ConclusionIt seems that this malware is being actively distributed through various exploit kits. However, the mutation of the core is not so fast, as we see our sample is very similar to the one observed a month ago. Still, the used packing, composed of many layers gave it advantage of low detection rates in early days after the release.
On the other hand, the good news is that it's not an entirely stealthy piece of malware (except on Windows XP), so a cautious user can notice some of the alarming symptoms.
Part II: Who’s Behind Your Proxy? Uncovering Bunitu’s Secrets