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
It may have various consequences for the infected user. Basically, it uses his/her resources and slows down the network traffic. But it may also frame him/her in some illegal activities carried by the attackers due to the fact that the infected client’s IP is the one visible from the outside.
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 EK
A 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’:
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
Looking at the payload from outside, we will see just a typical installer (with an NSIS installer icon).
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)
To 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)
Then, it loads the dropped module: lithiasis.dll into memory and executes the function called – in the analyzed case – Avidness (responsible for further unpacking).
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)
Keys used to decrypt the files:
- dalookerzmeoajrhja144 – “dalookerzmeoajrhja144”
- UncryptedStub._ini – “9JKjPZSpEL8uHmkHNlXhwhDc9jRTGN”
Files are encrypted with obfuscated, custom XOR based algorithms. For each file the used algorithm is slightly different. Below you can see sample python scripts for decoding the files: Bunitu Proxy – decoding scripts (github)
#1 Decrypting functions
[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).
It 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.