Executive Summary
LevelBlue Labs has identified a new evolution in the toolset of threat actors. Threat actors are hijacking legitimate anti-virus software to carry out malicious activities undetected.
A new tool, named SbaProxy, has been found masquerading as legitimate anti-virus components to establish proxy connections through a command and control (C&C) server. This tool, distributed in various formats such as DLLs, EXEs, and PowerShell scripts, is challenging to detect due to its sophisticated design and legitimate appearance.
By modifying legitimate anti-virus binaries and using valid certificates, the threat actors have made SbaProxy particularly stealthy. This threat has a significant impact, as it can be used to create proxy services that facilitate malicious activities and potentially be sold for financial gain. LevelBlue Labs is committed to continuing its efforts to monitor and combat this evolving threat.
What you need to understand at the highest level:
Hijacking of Legitimate Software. Threat actors leverage legitimate anti-virus components, modifying them to serve malicious purposes while maintaining their appearance as benign software, making detection difficult. In this new iteration of the campaign, we have observed Malwarebytes, BitDefender, APEX products, and others being targeted.
Introduction of SbaProxy. A new tool, SbaProxy, has been identified as part of this threat actor's evolving toolkit, capable of establishing proxy connections they use to generate revenue.
Sophisticated Evasion Tactics. The malicious binaries are signed with valid or seemingly valid certificates, which helps them bypass security checks and evade detection.
Variety of Distribution Formats. SbaProxy is being distributed in multiple formats, including DLLs, EXEs, and PowerShell scripts, all with the same underlying functionality, increasing the attack's resilience.
Ongoing Threat Monitoring. LevelBlue Labs is actively tracking this threat to stay ahead of the actors' evolving techniques and protect their clients from emerging cyber risks.
Technical Analysis: A Closer Look at How It’s Done.
In early June, LevelBlue Labs observed suspicious activity originating from seemingly legitimate anti-virus binaries. Upon investigation, this activity was from a new tool associated with the campaign already reported by Sophos in late April. It marks a new iteration in the toolset used by this threat actor. It’s controlled from a C&C server and establishes a proxy connection between the C&C server and a target through the infected machine. We believe this proxy service is then sold to other criminals. We are tracking this as SbaProxy following the nomenclature given by Sophos.
SbaProxy is being distributed in several formats:
- PowerShell scripts
- DLL libraries
- EXE binaries.
Even though the format varies and there are technical differences among the different types of files, the functionality offered is the same.
Notably, when the chosen format is DLL or EXE, the samples are based on the legitimate anti-virus components they are trying to imitate but are modified to include malicious code. This is done to disguise their binaries as legitimate, as the larger portion of the code is benign.
Of course, the original anti-virus binaries were signed by their respective manufacturers, and the modifications performed by the malicious threat actor broke the signature. The threat actor has opted to sign the files again with counterfeit certificates. While some of the certificates used by the threat actor to sign the malicious binaries have expired or been revoked, others are still valid as we publish this report.
For example, the certificate with the thumbprint “DCB42EF087633803CD17C0CD6C491D522B8A2A” issued to “STERLING LIMITED” is currently valid and used to sign some of the samples in this campaign. It looks like the threat actor acquired this certificate to perform their activities, as the date it was issued fits the campaign, and all files found signed with this certificate exhibit malicious behavior.
Let’s take the file ‘7d96ec8b72015515c4e0b5a1ae6c799801cf7b86861ade0298a372c7ced5fd93‘ as an example. This sample masquerades as a BitDefender logging DLL, and as can be seen in Figure 1, the exported functions in the malicious DLL (left) are identical to those in the original DLL (right).
Figure 1. Comparison of exported functions between legitimate and malicious samples
Furthermore, all functions but one are unmodified from the original BitDefender code. Figure 2 shows an example of this, comparing the DLL entry point from the malicious sample with the legitimate DLL.
Figure 2. Malicious sample DLL entry point (left) vs legitimate DLL entry point (right)
For this sample, the modified function was the exported function ‘LogSetMode’.
Figure 3. Malicious function (left) vs original function (right)
In Figure 3 the replaced function can be seen. The original body was replaced with with a jmp instruction to another address. If we explore this address, we can see a function that decrypts and executes a bundled XOR-encrypted shellcode.
Figure 4. Payload decryption function
The function contains a pointless loop that sets several local variables to a hardcoded value. This operation is repeated 448,840 times. This is a rather rudimentary form of bypassing detection methods that rely on emulation and operate on a maximum number of instructions emulated, such as anti-virus emulators. After completing the loop, the code then checks one of the set variable’s values, verifying it is what was expected. If it’s not, it crashes. Other observed samples attempt to load sc.exe or other Windows binaries via LoadLibrary. Although the technique differs, the purpose is the same.
Having completed these operations, the code proceeds to allocate memory for the payload, decrypt it using a hardcoded multi-byte XOR key, and execute it. Besides the XOR encryption, the code is straightforward and not obfuscated. We believe this is done purposefully, not to trigger detection tools based on code analysis, as obfuscated code is harder to analyze but more suspicious. Some samples include anti-disassembly features like jumps to the middle of a previously defined instruction, but this feature is limited to a few samples only.
Figure 5. Unencrypted shellcode
In Figure 5, the code attempts to reach the C&C server in an iterative loop until it is successful. The initial communication with the C&C is quite peculiar as it performs a series of calls to the ‘send’ function with all zero content and lengths of 16, 4, and 0 bytes, respectively. Even though the last send has a payload length of 0 bytes, it still causes a TCP packet to be sent over the network. This is likely a magic sequence to ensure the C&C only replies to the malicious client.
After performing this set of sends, it receives 16 bytes from the C&C and sends them back to the server over a new socket. This new set of connections is performed in an iterative loop, so each time the C&C replies, a new thread is created with its corresponding socket. This allows for several active connections in parallel. The C&C will reply each time a new proxy connection wants to be created, enabling it to manage large amounts of parallel connections.
Figure 6. Thread code to handle C&C communications
The thread code to handle C&C communications is also straightforward. First, it reads a command, which can produce two possible values:
- A command with id = 1 will open a socket to the specified IP address, which will be used as the proxy's target address.
- A command with id = 3 does the same, but instead of specifying an IP address, the C&C will specify a host name to connect to as the target address. Said hostname will be resolved using ‘getaddrinfo’.
Once the connection to the target has been established, the code will forward data between the target and the C&C server. The C&C server will do the same between itself and the client. This effectively establishes a proxy between the client and the target that routes traffic through the C&C server and the infected machine. Only TCP connections are supported.
Figure 7. Proxy implementation
The shellcode does not include any other features besides what was described. So, notably, the implants do not feature persistence. When the implant is distributed in DLL format, persistence is not needed. The host process will load the malicious DLL and given that the targeted processes are anti-virus services, the malicious implant will execute at system start.
The infection remains in memory for the PowerShell and EXE formats if no other process creates persistence for the malicious executables. No features enable the threat actor to execute additional code or commands. We believe this is complementary to the primary threat, which is usually a fully-fledged remote administration tool like Cobalt Strike. This secondary threat is kept as minimal as possible to evade detections while also being able to generate revenue for the threat actor.
The PowerShell samples implement the same algorithm found in the encrypted shellcode payload directly in PowerShell without further layers or obfuscation. The scripts even retain the original function and variable names the original author gave, making it very readable. This can be seen in Figures 8 and 9.
Figure 8. C&C command handling in Powershell sample
Figure 9. Proxy implementation in PowerShell
While the activity presented by this threat actor remains largely the same, this new tool marks an iteration in their toolset and demonstrates a rapid evolution. How the threat actor splits the code between two components makes the attack more resilient.
Even if the first component, which is usually easier to detect, is deleted from the system, likely, they can still use the secondary component since it's only doing a specific task with less code modification, and it’s harder to detect. Additionally, the presented decoys in this new threat are well-formed, so samples could easily be dismissed as benign if not carefully examined. LevelBlue Labs will continue to track this threat actor and the techniques observed in this blog to protect our clients from the latest malware development trends.
Conclusion
The discovery of SbaProxy underscores a troubling trend in the cyber threat landscape: sophisticated adversaries' weaponization of trusted security tools.
By hijacking legitimate anti-virus software, these threat actors have found a way to operate under the radar, making traditional detection methods less effective. The use of valid certificates and the careful crafting of malicious binaries that closely resemble their legitimate counterparts highlight the growing complexity of these threats.
As cybercriminals continue to innovate, organizations must remain vigilant and proactive in their defense strategies. LevelBlue Labs is dedicated to staying ahead of these evolving threats, ensuring our clients have the latest intelligence and tools to protect their critical assets. The battle against cyber threats is ever-changing, and only through constant adaptation and vigilance can we hope to keep the upper hand.
Detection Methods
The following associated detection methods are in use by LevelBlue Labs. They can be used by readers to tune or deploy detections in their own environments or for aiding additional research.
SURICATA IDS Signatures
- alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"AV TROJAN SbaProxy CnC Beacon M1"; dsize:16; content:"|00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00|"; depth:16; flow:established,to_server; flowbits:set,AV.SbaProxy.1; flowbits:noalert; sid:1000001; rev:1;)
- alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"AV TROJAN SbaProxy CnC Beacon M2"; dsize:4; content:"|00 00 00 00|"; depth:4; flow:established,to_server; flowbits:isset,AV.SbaProxy.1; flowbits:set,AV.SbaProxy.2; flowbits:noalert; sid:1000002; rev:1;)
- alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"AV TROJAN SbaProxy CnC Beacon M3"; dsize:0; flow:established,to_server; tcp.flags:FA; flowbits:isset,AV.SbaProxy.2; sid:1000003; rev:1;)
Associated Indicators (IOCs)
A list of indicators is available in the OTX Pulse. Please note, the pulse may include other activities related but out of the scope of the report.
Mapped to MITRE ATT&CK
The findings of this report are mapped to the following MITRE ATT&CK Matrix techniques:
● TA0002: Execution
○ T1059: Command and Scripting Interpreter
- T1059.001: PowerShell
● TA0003: Persistence
○ T1554: Compromise Host Software Binary
● TA0005: Defense Evasion
○ T1036: Masquerading
- T1036.005: Masquerading: Match Legitimate Name or Location
○ T1140: Deobfuscate/Decode Files or Information
○ T1205: Traffic Signaling
○ T1574: Hijack Execution Flow
○ T1656: Impersonation
● TA0040: Impact
○ T1496: Resource Hijacking
● TA0042: Resource Development
○ T1588: Obtain Capabilities
- T1588.003: Obtain Capabilities: Code Signing Certificates