Skip to content

Back to the catalog

Threat Actors Abuse IronPython to Deliver CastleLoader/CastleRAT
knowyouradversary.ruwriteup

Threat Actors Abuse IronPython to Deliver CastleLoader/CastleRAT

A threat-hunting blog post (#415 in a recurring series) analyzes how attackers abused IronPython to deliver CastleLoader and subsequently CastleRAT, based on Zscaler's SloppyRAT report. It documents the attack chain — a renamed curl.exe downloading IronPython from GitHub, then IronPython executing a base64-decoded, zlib-compressed Python payload — and provides concrete hunting queries (process creation events filtering on curl.exe with "ironpython" in the command line, and IronPython processes invoking base64.b64decode) to detect this technique, mapped to MITRE ATT&CK T1059.006.

TL;DR Threat-hunting writeup on attackers using renamed curl.exe + IronPython to deliver CastleLoader/CastleRAT, with ready-to-use detection queries.
Open original ↗
Document

What it is

Detection guidance for a technique from Zscaler's SloppyRAT report: attackers use IronPython (a .NET Python implementation) as the interpreter to stage CastleLoader → CastleRAT, exploiting the fact that IronPython is rare on normal hosts. Mapped to MITRE ATT&CK T1059.006 (Python).

How it works

The chain uses evasive naming at each step:

  • A renamed copy of curl.exe (dropped as 9342371634011778.com in AppData\Local) downloads IronPython.3.4.2.zip from the official github.com/IronLanguages/ironpython3 releases — but saves it with a .pdf extension (IronPython.3.4.2.pdf), using --ssl-no-revoke to skip revocation checks.
  • The extracted interpreter (net462\31706105999761.exe) is invoked with -c to run an inline loader that base64.b64decodes a zlib-compressed payload and .decode('utf-32')s it, then re-launches sys.executable via subprocess.Popen to run the decoded stage. This delivers CastleLoader, then CastleRAT.

What to do

The post gives three concrete hunts. The field names matter — reproduce them:

Renamed-curl downloading IronPython:

event_type: "processcreatewin"
AND proc_file_originalfilename: "curl.exe"
AND cmdline: *ironpython*

Note proc_file_originalfilename, not the on-disk name — this catches the renamed .com binary.

IronPython performing Base64 decode:

event_type: "processcreatewin"
AND proc_file_productname: "ironpython"
AND cmdline: "base64.b64decode"

Third and broadest: treat the mere presence of an IronPython interpreter on a host as suspicious. The post argues the average user never runs IronPython, so its existence is a valid investigation starting point regardless of command line — a hunt the summary's query-specific framing doesn't convey.

Caveats

These are hunting hypotheses derived from one incident's artifacts, not validated broad-coverage rules. The cmdline: "base64.b64decode" filter keys on the specific loader pattern seen here; a payload using a different decode path would evade it, which is why the interpreter-presence heuristic is offered as the durable fallback.

Organisations named here

  • T1059.006

Technologies named here

  • IronPython
  • curl.exe
  • Zscaler report
  • curl
  • Python
  • Windows
  • MITRE ATT&CK
  • Zscaler

Techniques named here

  • Command and Scripting Interpreter
  • Renamed system utility
  • Base64/zlib encoded payload execution

Threat actors named here

  • SloppyRAT
  • CastleLoader
  • CastleRAT

Related in Blue Team & Detection