Smoke and (screen) mirrors: A strange signed backdoor

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.

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.

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.

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.

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.

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.

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.

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.

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.
SHA256
Compilation Timestamp
Signature
cec73bddc33cd11ba515e39983e81569d9586abdaabbdd5955389735e826c3c7
2023-01-05 19:58:50
Not signed
815e21de6fab4b737c7dd844e584c1fc5505e6b180aecdd209fbd9b4ed14e4b2
2023-01-11 09:46:14
WHCP
3c931548b0b8cded10793e5517e0a06183b76fa47d2460d28935e28b012e426c
2023-03-19 14:19:29
WHCP
0dae9c759072f9c0e5a61a9de24a89e76da35ffab8ff9610cc90df417c741f3f
2023-03-19 14:19:34
WHCP
acc5c46ae2e509c59a952269622b4e6b5fa6cf9d03260bfebdfaa86c734ee6ea
2023-03-19 14:19:34
Not signed
230c9c47abb17e3caa37bcb1b8e49b30e671e6c50e88f334107e3350bee13385
2023-03-19 14:19:29
WHCP
d6a1db6d0570576e162bc1c1f9b4e262b92723dbabdde85b27f014a59bbff70c
2023-03-19 14:19:34
Not signed
4c23a199152db6596ccafb5ea2363500e2e1df04961a4ede05168999da87d39a
2023-10-08 17:05:40
Not signed
c0c648e98ec9d2576b275d55f22b8273a6d2549f117f83a0bcc940194f1d0773
2023-10-08 17:05:45

eccfd9f2d1d935f03d9fbdb4605281c7a8c23b3791dc33ae8d3c75e0b8fbaec6
2023-10-08 17:05:40
WHCP
5a519932c20519e58a004ddbfee6c0ed46f1cee8d7c04f362f3545335904bae2
2023-10-08 17:05:40
IFOX PTE. LTD
593f8ed9319fd4e936a36bc6d0f163b9d43220e61221801ad0af8b1db35a0de5
2023-10-08 17:05:40
Gaoyou tucker network studio
0ee12274d7138ecd0719f6cb3800a04a6667968c1be70918e31c6f75de7da1ba
2023-10-08 17:05:45
Not signed

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.