In April of 2015, Kaspersky released a report on a Trojan / Remote Access Tool (RAT) targeting financial institutions in Russia and Ukraine, named BUHTRAP, also known as Pegasus and Carbanak. Kaspersky reported BUHTRAP has been active since 2014, but the first attacks were not detected until August 2015. A small group of users of BUHTRAP have employed techniques more commonly seen in nation-state APT actors, netting hundreds of millions of dollars as a result.
On February 5, 2016, the BUHTRAP source-code was uploaded to the forum “exploit.in” by an individual reporting to be a disgruntled member of the BUHTRAP Group, unhappy with lack of pay for his work. The source code, uploaded on July 7 2018 to the M4L4ALL forum by user FR3D, as been definitively identified by malware researcher Vitali Kremez as a variant or fork of BUHTRAP. This is at least the second variant of BUHTRAP source code released to the public. The following article is dedicated to the analysis of the leaked source code and his capabilities.
- Single stage dropper
- Static config
- Process hollowing
- Limited P2P capabilities
- Built in optional Privilege Escalation
- AV bypass techniques (KIS)
After everything is written to memory, the InstallerExe now enumerates the starting point of each PE module package in memory and then jumps to the reflective loader shellcode currently pointing to the InstallDispatcher package.
Reflective Loader Shellcode
The Shellcode serves the purpose of a reflective DLL loader, importing the API required by the Windows PE loader, descrambling the module, loading the appropriate PE file in memory, and then calling its entry point. Starting from the InstallerExe, the Shellcode points to the InstallDispatcher, which is than executed.
Install Dispatcher – DLL
As already mentioned in the first DCSO article about Pegasus/Buhtrap, a privilege escalation can be performed by using two old vulnerabilities, CVE-2015-0057 and CVE-2015-1701. The privilege escalation step can be enabled or disabled in the build configuration.
With or without elevated privileges, the InstallDispatcher uses process hollowing to start the next stage. The reflective loader shellcode, InstallDispatcher, and WorkDispatcher are written to the process memory of a newly started suspended svchost.exe process. The old PE image is unmapped and the entry point patched to point to the reflective loader shellcode.
However, the complete stage is then executed from within the svchost.exe process and no new process is spawned, which simply but effectively hides the process from the user’s point of view. After resuming the manipulated svchost.exe process, the reflective loader shellcode continues to load the WorkDispatcher component.
Work Dispatcher – DLL
The WorkDispatcher initializes the core of the malware itself. After the WorkDispatcher module is started, the installer file, which contained the InstallerExe component, is deleted. From this point on, the malware runs fileless in memory without evidence on disk. Persistence in the target network is achieved by reinfecting rebooted systems from Pegasus instances running on other machines on the same network. This assumes that multiple targets within the same network are infected.
After cleanup, the WorkDispatcher initializes a shared callback list that allows each module to communicate with each other. This callback structure is referred to in the Pegasus source as CORE_APIS, which includes shared methods that the modules can access. Each module is then loaded and started in its own thread, and the malware starts its normal work.
The modules described below are available in the leaking version of the malware.
After starting via the WorkDispatcher, the NetworkConnectivity module begins to periodically check (every 15 minutes) whether the victim has access to the internet by connecting to a randomly secure URL such as https://addons[.]mozilla[.]org via WinHTTP.
This can be done directly or via a preconfigured proxy. If no uplink is available on the victim’s computer, the malware checks whether other infected hosts can provide an uplink to the C2 server via a pipeline.
If a connection is somehow available, the malware starts testing the connection itself by downloading and checking a .txt and .cab file from two valid Microsoft URLs. This is probably done to test whether the malware is running in a sandbox or analysis VM.
If everything works from this point on, the NetworkConnectivity module starts to communicate with the C2 server directly or via heartbeat mechanisms.
In addition, the NetworkConnectivity module provides callback mechanisms for other modules to send or receive data to or from the C2 server or to spread broadcast information such as gathered credentials or available uplinks through the SMB MailSlot.
The LogonPasswords modules are used to regularly dump credentials from the Windows LSA password memory with Mimikatz-related code. The credentials are stored with a timestamp locally in a Credential Manager and updated as new credentials become available. In addition, all collected credentials are distributed to other infected instances via the SMB MailSlot.
The DomainReplication Module is responsible for spreading the malware in the network using a very classical approach. Depending on the host configuration, if Pegasus has access via SMB on the target with the stored credentials, it checks the target architecture by reading the first bytes of notepad.exe. After this step, it places the corresponding randomly named, signed service execution file (.exe) on the $ADMIN share, which is then remotely executed either via WMI, SCM, or RDP.
Within the C2 console, an attacker can assign various jobs to infected hosts that are then executed by the CmdExec module. For this purpose, the module offers several ways to execute things on a victim machine, e.g., directly via the Windows CMD, reflectively via DLL in memory, or by executing an executable file on the hard disk.
The purpose of the modules seems to be a more targeted one. After the module is started, it attempts to inject code into a running program called KBRI on the victim’s computer, which according to other articles, is a Russian accounting software.1
The source code contains a lot of comments, which indicate that specific measures were taken to evade Kaspersky Internet Security.
From the methods employed by the author to specifically evade the KIS emulation engine, it is likely that a systematic testing against KIS was part of the development process.
Pegasus/Buhtrap is a modular and versatile worm-like malware leveraging dumped credentials with SMB, WMI, and SCM for lateral movement. The well-annotated code and modular structure makes full or partial code reuse in other malware likely, although the build process of the original Pegasus project is somewhat involved.
The build tools and the Pegasus code itself contained some bugs and incomplete implementations of certain functions, which may indicate that the leaked code was a development version.
DCSO will continue hunting for malware derived from Pegasus source in addition to ensuring signature coverage for the specific lateral movement and loading mechanisms employed by Pegasus.
Who we are
The Threat Intelligence -Team helps clients to reduce the threat posed by adversaries to their networks by leveraging the power of collaborative defense in combination with comprehensive analytics and contextualized threat intelligence. DCSO delivers actionable intelligence on all levels – from atomic Indicators of Compromise (IoC) to insights into the political, economic and cultural context of adversaries.