Category Archives: News

News

The AI Fix #10: An AI cookery dumpster fire, the ARC prize, and a creepy new AI friend

Read Time:24 Second

In episode ten of “The AI Fix” podcast, Graham attempts to say “quinoa”, Mark draws a line in the amper-sand, ChatGPT becomes an expert in solar panels and bomb disposal, and our hosts watch a terrifying tailer for a creepy new AI friend.

Graham discovers that the world of AI cookery is a soggy, limey mess, and learns an unusual trick for making a great mojito, while Mark pits his co-host against the cleverest AI brains in the world.

Read More

News

Hijacked: How Cybercriminals Are Turning Anti-Virus Software Against You

Read Time:10 Minute, 20 Second

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

Read More

News

A Better Investigatory Board for Cyber Incidents

Read Time:6 Minute, 52 Second

When an airplane crashes, impartial investigatory bodies leap into action, empowered by law to unearth what happened and why. But there is no such empowered and impartial body to investigate CrowdStrike’s faulty update that recently unfolded, ensnarling banks, airlines, and emergency services to the tune of billions of dollars. We need one. To be sure, there is the White House’s Cyber Safety Review Board. On March 20, the CSRB released a report into last summer’s intrusion by a Chinese hacking group into Microsoft’s cloud environment, where it compromised the U.S. Department of Commerce, State Department, congressional offices, and several associated companies. But the board’s report—well-researched and containing some good and actionable recommendations—shows how it suffers from its lack of subpoena power and its political unwillingness to generalize from specific incidents to the broader industry.

Some background: The CSRB was established in 2021, by executive order, to provide an independent analysis and assessment of significant cyberattacks against the United States. The goal was to pierce the corporate confidentiality that often surrounds such attacks and to provide the entire security community with lessons and recommendations. The more we all know about what happened, the better we can all do next time. It’s the same thinking that led to the formation of the National Transportation Safety Board, but for cyberattacks and not plane crashes.

But the board immediately failed to live up to its mission. It was founded in response to the Russian cyberattack on the U.S. known as SolarWinds. Although it was specifically tasked with investigating that incident, it did not—for reasons that remain unclear.

So far, the board has published three reports. They offered only simplistic recommendations. In the first investigation, on Log4J, the CSRB exhorted companies to patch their systems faster and more often. In the second, on Lapsus$, the CSRB told organizations not to use SMS-based two-factor authentication (it’s vulnerable to SIM-swapping attacks). These two recommendations are basic cybersecurity hygiene, and not something we need an investigation to tell us.

The most recent report—on China’s penetration of Microsoft—is much better. This time, the CSRB gave us an extensive analysis of Microsoft’s security failures and placed blame for the attack’s success squarely on their shoulders. Its recommendations were also more specific and extensive, addressing Microsoft’s board and leaders specifically and the industry more generally. The report describes how Microsoft stopped rotating cryptographic keys in early 2021, reducing the security of the systems affected in the hack. The report suggests that if the company had set up an automated or manual key rotation system, or a way to alert teams about the age of their keys, it could have prevented the attack on its systems. The report also looked at how Microsoft’s competitors—think Google, Oracle, and Amazon Web Services—handle this issue, offering insights on how similar companies avoid mistakes.

Yet there are still problems, with the report itself and with the environment in which it was produced.

First, the public report cites a large number of anonymous sources. While the report lays blame for the breach on Microsoft’s lax security culture, it is actually quite deferential to Microsoft; it makes special mention of the company’s cooperation. If the board needed to make trades to get information that would only be provided if people were given anonymity, this should be laid out more explicitly for the sake of transparency. More importantly, the board seems to have conflict-of-interest issues arising from the fact that the investigators are corporate executives and heads of government agencies who have full-time jobs.

Second: Unlike the NTSB, the CSRB lacks subpoena power. This is, at least in part, out of fear that the conflicted tech executives and government employees would use the power in an anticompetitive fashion. As a result, the board must rely on wheedling and cooperation for its fact-finding. While the DHS press release said, “Microsoft fully cooperated with the Board’s review,” the next company may not be nearly as cooperative, and we do not know what was not shared with the CSRB.

One of us, Tarah, recently testified on this topic before the U.S. Senate’s Homeland Security and Governmental Affairs Committee, and the senators asking questions seemed genuinely interested in how to fix the CSRB’s extreme slowness and lack of transparency in the two reports they’d issued so far.

It’s a hard task. The CSRB’s charter comes from Executive Order 14208, which is why—unlike the NTSB—it doesn’t have subpoena power. Congress needs to codify the CSRB in law and give it the subpoena power it so desperately needs.

Additionally, the CSRB’s reports don’t provide useful guidance going forward. For example, is the Microsoft report provides no mapping of the company’s security problems to any government standards that could have prevented them. In this case, the problem is that there are no standards overseen by NIST—the organization in charge of cybersecurity standards—for key rotation. It would have been better for the report to have said that explicitly. The cybersecurity industry needs NIST standards to give us a compliance floor below which any organization is explicitly failing to provide due care. The report condemns Microsoft for not rotating an internal encryption key for seven years, when its standard internally was four years. However, for the last several years, automated key rotation more on the order of once a month or even more frequently has become the expected industry guideline.

A guideline, however, is not a standard or regulation. It’s just a strongly worded suggestion. In this specific case, the report doesn’t offer guidance on how often keys should be rotated. In essence, the CSRB report said that Microsoft should feel very bad about the fact that they did not rotate their keys more often—but did not explain the logic, give an actual baseline of how often keys should be rotated, or provide any statistical or survey data to support why that timeline is appropriate. Automated certificate rotation such as that provided by public free service Let’s Encrypt has revolutionized encrypted-by-default communications, and expectations in the cybersecurity industry have risen to match. Unfortunately, the report only discusses Microsoft proprietary keys by brand name, instead of having a larger discussion of why public key infrastructure exists or what the best practices should be.

More generally, because the CSRB reports so far have failed to generalize their findings with transparent and thorough research that provides real standards and expectations for the cybersecurity industry, we—policymakers, industry leaders, the U.S. public—find ourselves filling in the gaps. Individual experts are having to provide anecdotal and individualized interpretations of what their investigations might imply for companies simply trying to learn what their actual due care responsibilities are.

It’s as if no one is sure whether boiling your drinking water or nailing a horseshoe up over the door is statistically more likely to decrease the incidence of cholera. Sure, a lot of us think that boiling your water is probably best, but no one is saying that with real science. No one is saying how long you have to boil your water for, or if any water sources more likely to carry illness. And until there are real numbers and general standards, our educated opinions are on an equal footing with horseshoes and hope.

It should not be the job of cybersecurity experts, even us, to generate lessons from CSRB reports based on our own opinions. This is why we continue to ask the CSRB to provide generalizable standards which either are based on or call for NIST standardization. We want proscriptive and descriptive reports of incidents: see, for example, the UK GAO report for the WannaCry ransomware, which remains a gold standard of government cybersecurity incident investigation reports.

We need and deserve more than one-off anecdotes about how one company didn’t do security well and should do it better in future.  Let’s start treating cybersecurity like the equivalent of public safety and get some real lessons learned.

Read More