Background

On May 27, 2025, China’s National Cybersecurity Notification Center issued a warning that ComfyUI suffers from several high-risk vulnerabilities that are already being exploited by hacker groups. The notice urged organizations to take immediate defensive actions to protect against potential network intrusions and data breaches.

With the rapid rise of privately deployed AI models across industries, ComfyUI—now a popular image-generation framework for large AI models—has inevitably become a prime target for cyberattacks. In this article, XLab shares key intelligence from our threat landscape monitoring and provides a technical breakdown of the observed attack campaigns.

Rewind to March 17, 2025, XLab's Cyber Threat Insight and Analysis System(CTIA) flagged suspicious behavior from IP 185.189.149.151, which was leveraging ComfyUI vulnerabilities to distribute several ELF executables disguised as config files (e.g., config.json, tmux.conf, vim.json). Upon deeper analysis, we confirmed these files were variants of the same backdoor.Given its core functionality—stealing sensitive AI-related data—we named it Pickai, a nod to the word “pickpocket.”

Pickai is a lightweight backdoor written in C++, designed to support remote command execution and reverse shell access. Despite its small size, it packs a punch:

• Host-side stealth: Includes anti-debugging, process name spoofing, and multiple persistence mechanisms.

• Network robustness: While it doesn’t use encryption, it cycles through multiple hard-coded C2 servers, regularly checking availability and auto-switching to ensure a stable command channel.

During reverse engineering, we discovered one of its C2 domains h67t48ehfth8e.com was unregistered. We quickly claimed it and were able to capture telemetry from infected systems. The results were alarming: at least 695 servers worldwide were compromised. Soon after, the attacker reacted by updating Pickai to use a new domain—historyandresearch.com—with a 5-year expiration window, signaling a deliberate and persistent stance against takedown efforts.

Pickai samples were being hosted on the official site of Rubick.ai—a commercial AI-powered platform serving the e-commerce sector across the U.S., India, Singapore, and the Middle Eas. Based on public sources, Rubick.ai provides services to over 200 major online retail brands, including:

• Amazon – Uses Rubick.ai for product catalog management

• The Luxury Closet (UAE) – Leverages AI tools for image enhancement and product tagging

• Hudson Bay (North America) – Uses Rubick’s PIM and marketing toolkits

• Myntra (India) – Depends on Rubick.ai to manage over 7 million SKUs

Because Rubick.ai acts as an upstream service provider, its compromise could propagate malware or backdoors downstream into dozens (or hundreds) of customer environments—a textbook supply chain threat. Considering that current security vendors mostly detect Pickai samples as generic threats, and many C2 servers remain unflagged, we decided to publish this article to share our findings.

Timeline

• Feb 28, 2025: An early version of Pickai was uploaded to VirusTotal from Hong Kong, using C2 server 195.43.6.252.
• Mar 17: XLab first detected Pickai payloads being distributed via ComfyUI vulnerabilities.
  
• May 3: XLab reported the compromise to Rubick.ai, but received no response.
  
• May 26: XLab observed another Pickai downloader hosted at 78.47.151.49.

Scale & Infrastructure

On March 17, 2025, we registered the previously unclaimed C2 domain h67t48ehfth8e.com, which gave us partial visibility into Pickai’s infections. The data showed nearly 700 infected servers worldwide, mainly in Germany, the United States, and China.

Pickai accesses its C2 servers in a defined priority order, with h67t48ehfth8e.com ranked the lowest. On April 13 and May 5, traffic to this domain spiked—peaking above 400—which we believe reflects Pickai’s actual daily active installations. The spikes likely occurred because the higher-priority C2s failed on those days, temporarily exposing the full botnet.

After this, Pickai samples were updated to include a new C2 domain: historyandresearch.com, with a 5-year validity. Its carefully chosen name and lack of DNS resolution seem like a direct response to our domain takeover. We imagine the attacker’s mindset was something like:

“Oh, XLab loves hijacking domains? Cool. Here’s a C2 with a 5-year TTL—try hijacking that. Let’s see what you’ve got! Haha!”

To that, our response is simple: Can’t take over this one? No problem—we’ll just expose the others. Pickai’s C2s currently have near-zero detection rates, but we believe the security community will soon remind its authors: The lifespan of malware is always written by the defenders.

Technical Analysis

We collected a total of seven Pickai samples, with the latest one from May 26 serving as the primary subject of this analysis. Its basic attributes are as follows:

MD5:8680f76a9faaa7f62967da8a66f5a59c
MAGIC:ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.2.0, stripped

Pickai’s functionality is relatively straightforward. Upon execution, it first decrypts embedded strings containing sensitive configuration data such as C2s , persistence scripts and etc. It then performs anti-debugging by checking the TracerPid field of the process status, ensures single-instance execution via a PID file, and uses the prctl syscall to rename its process.

Depending on the current user's privileges, it establishes persistence using either init.d or systemd. Finally, it connects to its C2 server and waits for remote commands.

The following sections analyze Pickai from two perspectives—host behavior and network communication—with a focus on string decryption, persistence mechanisms, and network protocol details.

Part 1: String Decryption

Most of Pickai’s sensitive strings are stored in the .rodata section in encrypted form. The encryption method is a simple XOR with 0xAF on each byte, with a distinct pattern: all ciphertext strings end with 0xAF.

For easier reverse engineering, the following IDAPython script can be used to decrypt them—just locate the start and end of the ciphertext.

startAddr=0x000000000000D028
endAddr=0x000000000000DBD8

buf=ida_bytes.get_bytes(startAddr,endAddr-startAddr)
items=buf.replace(b'\x00',b'').split(b"\xaf")

for item in items:
    plaintxt=bytearray()
    ciphertxt= ' '.join(f'{byte:02X}' for byte in item)
    addr=idc.find_binary(startAddr,idaapi.SEARCH_DOWN,ciphertxt)
    
    for i in item:
        plaintxt.append(i^0xaf)
    print(f"0x{addr:x}, has {len(plaintxt)} bytes ----> {plaintxt}")
    plaintxt.append(0)
    ida_bytes.patch_bytes(addr,bytes(plaintxt))
    idc.create_strlit(addr,addr+len(plaintxt))

As shown below, the decrypted strings reveal key information related to C2 servers, process spoofing, persistence, and more.

Part 2: Host Behavior

On the host side, Pickai features anti-debugging, single-instance enforcement, process spoofing, and persistence. While most implementations are fairly conventional, its approach to process spoofing and persistence shows a notable emphasis on diversity.

0x1: Process Spoofing
The "diversity" in process spoofing lies in the variety of names used. Pickai randomly selects one from a pool of 20 predefined process names and uses the prctl syscall to rename itself accordingly.

Details of the spoofed process names are as follows:

0x2: Persistence
The "diversity" in persistence lies in the number of services created—10 for root users, and 5 for non-root users.

When running as root, Pickai copies itself to five different paths, syncing each file’s modification time to that of /bin/sh. It then sets up services using both init.d and systemd to achieve persistence.

Below are the file paths where Pickai replicas reside, along with their corresponding persistence services. When using the init.d mechanism, the services are located in /etc/init.d/, while for systemd, they are placed in /usr/lib/systemd/system/ or /lib/systemd/system/.

It’s clear that Pickai attempts to impersonate legitimate system services to fly under the radar. The actual auditlogd persistence script it creates is shown below:

Notably, during the self-copy process, Pickai appends random data to the end of each file—clearly aiming to evade hash-based detection.

As shown, the MD5 hashes of the five Pickai copies on the infected test machine are all different:

When running as a non-root user, Pickai still uses systemd for persistence, following a similar process but with different paths and service names. These services reside in $HOME/.config/systemd/user/.

Through this redundant persistence strategy, Pickai maintains multiple footholds on the infected host—allowing it to survive unless every copy is fully removed.

Part 3: Network Communication

Pickai communicates with its C2s in an infinite loop using a three-tier timing strategy: it rotates active C2s every 43,200 seconds (12 hours), reports device info every 1,200 seconds, and requests commands every 120 seconds.

0x1: Command Request Packet
This is a 1024-byte packet with the first 7 bytes set to LISTEN|, followed by zero padding. Pickai supports two instructions: EXECUTE (for executing system commands) and REVERSE (for establishing a reverse shell).

0x2: Device Info Report Packet
Also 1024 bytes long, starting with UPDATE|, followed by three metadata fields, with the rest padded with 0x00:

• System fingerprint (uname -a)
• Privilege status (whether the current user is root)
• Docker status (checks if PID 1 is init or systemd)
  

0x3: C2 Liveness Check
The sample contains six hardcoded C2 domains. The bot probes each in priority order until it receives a response from the first live C2. This approach masks the presence of lower-priority C2s during normal operations, making it harder for sandbox-based IOC systems to observe the full infrastructure.

The liveness probe packet is 7 bytes long: STATUS|. A LISTENING response from the server indicates the C2 is active.

0x4: Tracked Commands
We implemented Pickai’s protocol in XLab’s command tracking system and observed only two instructions on June 6, both triggering reverse shells. Since we haven't yet emulated follow-up instructions like REVERSE or EXECUTE, the attacker’s intention after gaining shell access remains unknown.

Conclusion

Pickai’s redundant persistence mechanisms give it the traits of a stubborn trojan—any leftover copy can trigger a full resurgence. Network administrators are advised to conduct deep inspections based on the host-level behaviors outlined above and ensure all five implanted copies are completely removed to prevent reinfection.

This report summarizes the intelligence we’ve gathered on Pickai so far. We welcome fellow researchers with unique perspectives—and network admins affected by this backdoor—to share further insights via X. Readers interested in our work are also encouraged to reach out for more technical details and behind-the-scenes findings.

IOC

MD5

f9c955a27207a1be327a1f7ed8bcdcaa *old_version
ebd188be8e7ad72219fd9a227881dd8d *old_version
0641a20bde5bc620f115975c15d0cf40 *vim
fe9896eca398167f5d0304e555d170eb *config.json
7bc08ae32a2e0c9e07c98c2ade45c7f0 *tmux.conf
c587e4596fce1de62d132f46ca1f03de *vim.json
8680f76a9faaa7f62967da8a66f5a59c *x64

Downloader URL

http://78.47.151.49:8878/wp-content/x64
https://rubick.ai/wp-content/tmux.conf
https://rubick.ai/wp-content/vim.json
https://rubick.ai/wp-content/config.json

C2

80.75.169.227	Egypt|Al Qahirah|Cairo	AS36992|ETISALAT MISR
195.43.6.252	Egypt|Al Qahirah|Cairo	AS6879|Egyptian National Scientific & Technical Information Network
154.68.72.34	Rwanda|Ville de Kigali|Kigali	AS37654|Rwanda Ministry of Education
185.189.149.151	Switzerland|Zug|Baar	AS51395|Datasource AG
102.214.30.199	Tanzania|None|None	AS0|
38.180.207.9	United States|None|None	AS174|Cogent Communications  

historyandresearch.com