A “setup.iso” that runs Python from a text file, then steals your browser and hands over your PC

About this post: Thanks to MalwareHunterTeam for flagging this sample. This analysis and write-up were produced by Claude (Opus 5.5), working as an agent in Claude Code on a REMnux analysis VM. Tools used: Malcat, speakeasy, capa, Binary Refinery, 7-Zip, tshark, Python, VirusTotal (file store, sandbox report and PCAP), ANY.RUN, Triage and Deception Pro.

TL;DR

setup.iso is an 88 MB disk image that looks like a software installer. Double-clicking the shortcut inside starts a genuine copy of IronPython, a .NET version of Python that the attackers ship with the image, and has it run a "text file" that is really a Python script. From there, five stages are downloaded and unpacked, each one only in memory. The last of them is a loader bot that installs StealC v2, an information stealer, and the NetSupport Manager remote-control client.

• Lure: an ISO with a single setup.lnk shortcut, padded with ~68 MB of junk files.
• Trick: the payload script sits in docs\submergibility.txt and runs under a legitimate, bundled Python interpreter.
• Payloads: StealC v2 (passwords, cookies, cards, crypto wallets, Steam/Discord tokens, Outlook, WinSCP, screenshots) and a NetSupport RAT client with a scheduled task.
• Infrastructure: jumalputty[.]com (stages + loader C2), nizariuserp[.]com (NetSupport package), 85[.]239[.]149[.]151 (StealC).
• Sandboxes: two of three public sandboxes scored it clean or nearly clean, because they never clicked the shortcut.

Update (19 October 2026): we watched it run

We ran the ISO in a Deception Pro sandbox, a long-running virtual machine dressed up as an ordinary company workstation, and clicked the shortcut by hand. That sandbox can’t open an ISO on its own, so a person had to do what a victim would do. The whole chain fired again, and this time NetSupport started and connected to its server.

• The first two minutes: the stages came down from jumalputty[.]com, StealC uploaded about 1.5 MB to 85[.]239[.]149[.]151, and the NetSupport package from nizariuserp[.]com was unpacked.
• Five minutes later: the scheduled task started client32.exe. It looked up drrajivparti[.]com, which points to 79[.]133[.]41[.]107, and from then on checked in once a minute with an HTTP POST to /fakeurl.htm on port 4889. That is how NetSupport talks to a "gateway", a relay server the operator connects through.
• About 50 minutes after infection: the check-ins stopped, and for about seven minutes the connection carried much denser traffic before the regular check-ins resumed. That pattern fits someone opening a remote session to the machine. NetSupport started no programs during that window, so it was most likely a look at the screen or the system details. We’ll know more once the full traffic capture is available.

This answers one of the open questions in "What we couldn’t reach" below, and the new indicators are in the table. crataga[.]site was contacted again and, as before, never answered.

A note for defenders: client32.exe itself is the genuine, signed NetSupport program. What gives it away is where it lives (%LOCALAPPDATA%\Nets\) and which server it reports to.

What’s in the box

An ISO file is a disk image. On Windows a double-click "mounts" it as a new drive, and whatever is inside appears as a normal folder. Attackers like ISOs because a file inside the image can lose the "downloaded from the internet" marking that would otherwise trigger extra warnings.

The only thing a victim is expected to click is setup.lnk. It runs setup.cmd, which contains one line: start runtime\ipyw32.exe and give it docs\submergibility.txt. ipyw32.exe is the windowless IronPython launcher, so no console window appears.

The rest of the image is noise: folders called config, langs, skins and docs full of random-word text, JSON and Word files, plus seven 6–12 MB "storage" blobs that look encrypted. We checked every stage, and nothing ever reads them. They make the image look like a real product and make it large, which some scanners skip.

Stage 1: a text file that isn’t

submergibility.txt opens with a paragraph of dictionary words. The last line is Python: it base64-decodes a blob (stored as UTF-32 to make it bigger and harder to read) and runs it with exec. The decoded script is short. It turns off HTTPS certificate checks, downloads more Python from jumalputty[.]com/473070fa-…/doc8, waits 2.1 seconds and runs that too.

Stage 2: Cyrillic letters in disguise

The downloaded doc8 is base64 again, with a twist. Some letters have been swapped for Cyrillic look-alikes (о for b, Р for S, and so on), and the script swaps them back before decoding. To a human or a simple scanner, the text looks like broken base64.

Once decoded, it XOR-decrypts 6,400 bytes of shellcode: raw machine instructions with no file around them. It copies them into executable memory and jumps to them using Python’s ctypes library. This is the point where the attack leaves "script" territory and becomes native code.

Stages 3–5: nesting dolls

The shellcode downloads v8 from the same server and RC4-decrypts it, using the first 64 bytes of the download as the key. Inside is another small stub that XOR-decrypts itself, and inside that is a reflective loader: code that loads a Windows program straight from memory, doing the job of the Windows loader itself, so the program never exists as a file on disk.

We did not need to contact the attackers to get these stages. VirusTotal had already fetched the URLs and kept the server’s responses, so we pulled doc8 and v8 from its file store and decrypted them offline.

The loader bot

The program at the centre of the dolls is a small C++ "bot" whose job is to take orders. Its settings are hidden as stack strings, built one character at a time and XORed with tiny keys. Decrypted, they give:

• its server jumalputty[.]com/70cadffb-604e-5ebd-845d-79a123ed1f74 and a build ID
• a fixed, odd User-Agent: hUoJQMMpy5YoPFuQ0Htm
• a "only run once" marker (mutex) D7lzR4b7W1q6PHS
• what looks like a ChaCha20 encryption key

It asks the server for settings (with options such as anti_vm and a list of active antivirus products), checks in, and then downloads and runs whatever it is told. It can run EXEs, DLLs, PowerShell and cmd commands, and create scheduled tasks.

Its design matches public descriptions of CastleLoader / CastleBot: a shellcode stager, then a PE loader, then a core bot with ChaCha20 traffic that delivers NetSupport and StealC. Our code-similarity check did not match it to CastleLoader, so treat the name as a likely fit, not a confirmed one.

What it delivered

VirusTotal’s CAPE sandbox ran the whole chain, and its report and network capture show what the bot was told to do:

StealC v2, hidden in a copy of Python. The bot downloaded viewer99, started a second, suspended copy of ipyw32.exe and swapped its contents for the stealer. That technique is called process hollowing: a legitimate-looking process becomes a shell for something else. We recovered the stealer itself and decrypted its strings. They list exactly what it goes after:

• saved passwords, cookies, autofill and credit cards from Chrome, Edge, Brave and Firefox (with a small helper for Chrome’s newer "App-Bound" protection)
• browser-extension and desktop crypto wallets (Bitcoin, Electrum, Litecoin, Exodus)
• Steam login files, Discord tokens, Outlook and Foxmail profiles, WinSCP saved sessions
• files matching operator-chosen patterns, a screenshot, and a system report
• a built-in "loader" option, so it can download and run something else too

In the sandbox, it sent 19 uploads (about 1.9 MB on the wire) to 85[.]239[.]149[.]151. The traffic is encrypted with a key we could not recover. We did recover the start of each message and could see the StealC v2 fields: build, hwid, access_token and "opcode":"success".

NetSupport Manager. The bot also downloaded a 2.3 MB package from nizariuserp[.]com and unpacked the NetSupport client into %LOCALAPPDATA%\Nets\Netsupport\, with a scheduled task named client32.exe to start it again later. NetSupport is a legitimate remote-administration product, but in this setup it gives the attacker a remote-control session on your PC. In the sandbox run the client was installed but not seen running, so we couldn’t confirm which server it would connect to. (Update: we have since seen it run and connect; see the update near the top.)

Why the sandboxes disagreed

ANY.RUN scored this file 0/100 and Triage scored it 3/10. Neither was "fooled" by clever evasion: neither ever opened the shortcut. Triage tested the decoy Word files and DLLs one by one. ANY.RUN’s run showed no command prompt or Python process at all. Only VirusTotal’s CAPE run clicked through and saw the full infection. If you triage ISO, ZIP or IMG files, check whether the sandbox actually ran the thing inside before trusting a clean verdict.

What we couldn’t reach

• The stealer’s traffic key. It is not stored in the binary as text; it is probably derived at runtime or sent by the server. Without it, only the first ~60 bytes of each message are readable.
• The NetSupport configuration (client32.ini, which names its server). The 2.3 MB package wasn’t available offline, and we did not download it from the attacker’s server. (Update: the server is now known from a live run: drrajivparti[.]com / 79[.]133[.]41[.]107.)
• The loader’s own traffic. It runs inside HTTPS, and the sandbox capture has no session keys.
• Family name for the loader. "CastleLoader-like" is a behaviour match only.
• One more domain, crataga[.]site, was contacted by one of the Python processes but never answered. Its role is unknown.

Advice

For everyone:

• Be suspicious of installers that arrive as .iso, .img or .vhd files, especially ones containing a shortcut.
• If you ran something like this: change your passwords from a clean device, starting with email, banking and crypto. Log out of all sessions, since stolen cookies can bypass passwords. Move crypto funds to a new wallet.
• Look for %LOCALAPPDATA%\Nets\Netsupport\ and a scheduled task named client32.exe. If they exist, assume someone had remote access.

For defenders:

• Alert on ipyw32.exe/ipy.exe started from a mounted ISO or removable drive, or with a .txt argument.
• Alert on a child ipyw32.exe with no arguments (the hollowed stealer).
• NetSupport client32.exe under %LOCALAPPDATA%\Nets\ is rarely legitimate.
• Block the network indicators below. StealC v2 uses plain-HTTP POST / with JSON and no User-Agent.

Indicators of compromise

Closing

This one is a good example of how much effort goes into getting a decades-old idea — "download and run a program" — past modern defences. The attackers used a disk image, a borrowed interpreter, a fake text file, look-alike letters and three layers of encryption, and the payload never touched the disk. None of that changes the advice: don’t run installers from ISO files you didn’t expect, and if you did, assume your browser data is gone and act accordingly.