Smoke and (screen) mirrors: A strange signed backdoor

Credit to Author: Matt Wixey| Date: Tue, 09 Apr 2024 19:08:05 +0000

In December 2023, Sophos X-Ops received a report of a false positive detection on an executable signed by a valid Microsoft Hardware Publisher Certificate. However, the version info for the supposedly clean file looked a little suspicious.

A table of file version information, with the CompanyName listed as "Catalog Thales"

Figure 1: Version info of the detected file. Note the typos ‘Copyrigth’ and ‘rigths’

The file’s metadata indicates that it is a “Catalog Authentication Client Service” by “Catalog Thales ” – possibly an attempt to impersonate the legitimate company Thales Group. However, after digging into both our internal data and reports on VirusTotal, we discovered that the file was previously bundled with a setup file for a product named LaiXi Android Screen Mirroring, “a marketing software…[that] can connect hundreds of mobile phones and control them in batches, and automate tasks like batch following, liking, and commenting.”

It’s worth noting that while we can’t prove the legitimacy of the LaiXi software – the GitHub repository has no code as of this writing, but contains a link to what we assume is the developer’s website – we are confident that the file we investigated is a malicious backdoor.

This isn’t the first time Sophos X-Ops has seen threat actors abusing the Microsoft Windows Hardware Compatibility Program (WHCP). In December 2022, almost exactly a year before conducting this research, we reported that attackers had deployed cryptographically-signed drivers in a failed attempt to disable Sophos endpoint security products. Those drivers, variants of BURNTCIGAR/POORTRY (an EDR killer sold on criminal forums and linked to ransomware gangs such as LockBit and CUBA) were signed with a legitimate WHCP certificate. However, other than the abuse of WHCP, we didn’t observe any evidence that the December 2023 backdoor is in any way linked to that earlier EDR killer.

Just as we did in 2022, we immediately reported our findings to the Microsoft Security Response Center. After validating our discovery, the team at Microsoft has added the relevant files to its revocation list (updated today as part of the usual Patch Tuesday cycle; see CVE-2024-26234).

While writing this article, which is based on our independent research into this backdoor in December 2023, we became aware that Stairwell had published its own article on this topic in January 2024, based on information in a tweet by Johann Aydinbas (also in January 2024). Our research validates and expands on some of those findings.

Picking up the trail

As noted above, the threat actor behind the malicious file managed to obtain a Microsoft Windows Hardware Compatibility Publisher signature from Microsoft, so we started our analysis from there.

A screenshot of certificate information from Catalog.exe, showing WHCP as the signer

Figure 2: Signature of Catalog.exe

Authenticode is a Microsoft code-signing security measure, which identifies the publisher of an application and provides verification that the application hasn’t been modified since it was signed and published. Fortunately, Microsoft provides code snippets on how to process these signatures and extract further metadata from them. One of the pieces of information we were able to extract was the original requesting publisher.

A screenshot from a Windows command-line showing output from the AuthenticodeParse.exe tool on Catalog.exe, showing WHCP in the signer certificate information

Figure 3: Extracting the original requesting publisher from the malicious file

In this case, the original requesting publisher is Hainan YouHu Technology Co. Ltd, which is also shown as the publisher of the LaiXI software.

A screenshot of the LaiXi website. The company name is highlighted in a red box on the bottom-right

Figure 4: Hainan YouHu Technology Co. Ltd is also shown as the publisher of the LaiXi application

We have no evidence to suggest that the LaiXi developers deliberately embedded the malicious file into their product, or that a threat actor conducted a supply chain attack to insert it into the compilation/building process of the LaiXi application. However, we will note that given the links between LaiXi and the malicious backdoor we investigated – and the length of time those links have existed (since at least January 2023, as we’ll discuss shortly) – users should exercise extreme caution when it comes to downloading, installing, and using LaiXi.

Technical analysis

The suspicious file embeds a tiny freeware proxy server, called 3proxy – a sketchy feature for an authentication client. We assess that this embedded binary is intended to monitor and intercept network traffic on an infected system.

A screenshot from a disassembly of the malware, with the strings "3proxy" highlighted in yellow

Figure 5: Strings relating to the embedded proxy server within the malware

When the file executes, it installs itself as a service called ‘CatalogWatcher’, with a service description of ‘Google ADB LoaclSocket [sic] Multi-threading Graphics API’ – a complete mismatch for the file version information shown in Figure 1. While we can’t confirm it, we assess that this is connected to link to a setup file for the LaiXi Android software, and an attempt to trick infected users into believing that the service is legitimate.

A screenshot from a disassembly of the malware

Figure 6: The function for creating the CatalogWatcher service

Once the service runs, the malware queues a new work item/thread via QueueUserWorkItem to the threadpool. Once the process has enough resources available, the malicious thread starts. This thread embeds the core functionality of the backdoor itself.

Interestingly, this function starts with an attempt to call the function VmProtectBeginVirtualization(), which is an export of the VMProtectSDK32.DLL by VMProtect.

A screenshot from a disassembly of the malware

Figure 7: Start of function for C2 communication

As per the VMProtect user manual, this function is used to define areas of code to protect via obfuscation and virtualization. Legitimate software developers often use virtual machine-based code protection to help prevent applications from being reverse-engineered – but threat actors also abuse it to try and thwart malware analysis. For more detail on reverse-engineering applications that use virtual machine-based protection, see a blog I wrote on my personal site a few years ago. In this case, the function is not properly obfuscated. We conclude that the threat actor may have intended to do this, but failed for some unknown reason.

We also note that the POORTRY/BURNTCIGAR samples we reported to Microsoft in December 2022 were packed with VMProtect. Back then, we already suspected that the attackers were using commercial packers such as Armadillo or VMProtect to hide the software’s malicious intent and get their drivers signed. It is possible that the threat actor behind this backdoor was attempting to do the same (although we should point out that the use of obfuscation, packers, and virtualization – including VMProtect – is very common across many malware developers).

The C2 server string “catalog[.]micrisoftdrivers[.]com” – a lookalike domain of microsoftdrivers[.]com – is decrypted via a simple XOR operation. A Python reimplementation of the decryption routine is below:

# Decrypts to catalog[.]micrisoftdrivers[.]com  s = "c`vbhja)e`iye~aidu`zbpdd6zuv"  cc = ""  i = 0  while i < len(s):      ch = chr((ord(s[i]) ^ i))      cc += ch      i += 1

Threat hunting

Finally, we wanted to determine if the threat actor had embedded the same payload into other products. We checked both our own telemetry and other sources, but saw no evidence that the backdoor has been bundled with anything other than LaiXi. We did, however, find multiple other variants – some of which were linked to a file named ‘Laixi_Update_1.0.6.7_b.exe’, indicating that other files, not just the setup installer, contain the malicious backdoor.

We’ve classified all the samples we discovered into four groups, based on the compilation timestamp.

A timeline showing the four categories of samples based on compilation timestamps

Figure 8: The four groups of samples and their chronological classifications

While the compilation timestamp of a PE file can be faked, we looked at the time delta between the moment the file was compiled and the time it initially appeared in our systems, and assess that the compilation stamps are likely genuine.

  • The first variant contains a compilation time of 2023-01-05. We therefore assess that this campaign has been in development since at least January 2023
  • The second variant contains a compilation timestamp of 2023-01-11. This is also the first sample that managed to obtain a WHCP certificate
  • The third group of samples, with a compilation timestamp of 2023-03-19, were either signed by the WHCP certificate, or unsigned. Some of these samples are associated with the Laixi_Update_1.0.6.7_b.exe file mentioned above
  • The final group shares a compilation timestamp of 2023-10-08. Interestingly, two samples of this group were signed by a different signer, although as of this writing we haven’t been able to ascertain any further information on these signers, or identify any other samples signed by them.

Table 1: A summary of all the samples we discovered, including their compilation timestamp and signer

IoCs relating to this incident are available on our GitHub repository. The Sophos protection Mal/Proxcat-A protects against this malware and the variants we discuss here.

Acknowledgments

Sophos X-Ops would like to thank Richard Cohen, Andrew Ludgate (SophosLabs), and Sean Gallagher (Sophos X-Ops) for their help in analyzing the samples; and Microsoft for engaging with us to help protect users.

http://feeds.feedburner.com/sophos/dgdY

Leave a Reply