CVE-2026-41940 cPanel Harvester Toolkit — 216.126.227.49

Campaign Identifier: CVE-2026-41940-cPanel-Harvester-216.126.227.49
Last Updated: May 17, 2026
Threat Level: HIGH

1. Executive Summary

The Hunters Ledger has identified a previously-undocumented, financially-motivated cybercriminal — tracked internally as UTA-2026-011 (an internal tracking label used by The Hunters Ledger — see Section 7) — operating a sustained credential-harvesting and phishing-as-a-service operation against the global cPanel, WHM, Plesk, and DirectAdmin shared-hosting ecosystem. The operator’s working filesystem was briefly exposed via a Python http.server development socket on TCP/7777 at 216.126.227.49 on 2026-05-12, allowing an open directory crawler (opendir-hunter) to recover 37 SHA256 hashes from a 45-file operator-built Python and Bash toolkit. The orchestrator file in that toolkit is named pipeline-41940.sh — a literal filename encoding of CVE-2026-41940, the cPanel/WHM CRLF authentication bypass disclosed 2026-04-28 (CVSS 9.8, added to CISA’s Known Exploited Vulnerabilities catalog 2026-05-01).

What Was Found

A single previously-undocumented operator (HIGH 87% confidence, single-operator-cluster identity) running an end-to-end shared-hosting credential-harvesting pipeline:

• Custom toolkit: 45 operator-built Python and Bash files (37 SHA256s recovered, 8 lost to rate-limiting). All 7 distinctive hashes checked returned File not found on VirusTotal — operator-bespoke tooling not seen by the wider security community.
• Multi-vendor coverage: Scanners and credential harvesters targeting cPanel (TCP/2083), WHM (TCP/2087), Plesk, and DirectAdmin Webmail. CVE-2026-41940 is the current high-leverage entry vector; other panel coverage is opportunistic.
• Live Flask C2 dashboard: Server: Werkzeug/3.1.8 Python/3.13.12 with HTTP 302 redirect to /login-2fa on 216.126.227.49:8888. Novel operator signature; hunt-ready Shodan/Censys queries available.
• Three definitive registrar-level same-operator locks: WHOIS org-ID hashes lock 10+ phishing/landing domains to one operator account across three independent registrars (WEBCC 20c6e82190de8bc4, NameCheap 4b7a0912c26a13e2, Dynadot 473daf17453d83cd).
• Operator MX backend mx.plingest.com on 38.143.66.193 (AS63023 GTHost) — shared across three otherwise-separate registrar clusters and is the cross-cluster attribution anchor.
• Operator Linux /etc/machine-id 6e3644a97f844763a34565b865d35310 leaked via systemd-private-tmp paths — a unique-per-VM-install identifier providing a definitive future same-machine pivot.
• Parklogic TDS monetization layer — operator account pkAId=2143526812 stable across 11 operator-owned parked landing domains routing victim traffic through a legitimate domain-monetization platform’s customer infrastructure to multi-brand phishing destinations.
• OpenClaw AI agent platform install footprint at /openclaw/2026.4.29/ with first-execution timestamp 2026-05-01 16:10:09 UTC. Filesystem presence is MODERATE-HIGH confidence; offensive use is LOW-MODERATE / UNCONFIRMED. This is novel observational data on AI-platform presence in an offensive operator’s working environment, not evidence of AI-assisted offensive tool development.

This investigation fills a gap in public threat intelligence reporting: no public reporting enumerates a per-operator toolkit and multi-month infrastructure rotation for the CVE-2026-41940 exploitation cluster. The operator is not the first observed exploiter — KnownHost telemetry documented in-the-wild exploitation since approximately 2026-02-23 — but represents one of the few publicly characterized end-to-end operator profiles for this CVE.

Why This Threat Is Significant

CVE-2026-41940 affects approximately 1.5 million internet-exposed cPanel instances. The bug is a three-stage exploit chain (CRLF injection in the Authorization: Basic header, encryption skip via the expired=1 marker, session promotion to WHM-root) that yields full administrative access to a hosting customer’s panel — and through it, every website, mailbox, and database hosted on that panel. Shadowserver Foundation measured 44,000 internet-wide scanning IPs probing for this CVE; CISA added it to the KEV catalog on 2026-05-01.

This operator’s distinctive contribution is the end-to-end pipeline wrapping the CVE — internet-wide mass scanning, multi-vendor admin-panel coverage, scripted same-day domain registration → certificate → activation, a multi-brand phishing-page generator (Office 365, Amazon, Coinbase, KuCoin, Brazilian Receita Federal, LATAM Airlines), and a Parklogic TDS monetization layer. The operator iterates on their tooling: 10+ versioned scanner/dashboard variants (mass_v4.py through mass_v8.py, live-dashboard-v1.py through live-dashboard-v10.py) coexist on disk, indicating sustained 6+ month internal development.

Key Risk Factors

Threat Actor

• Designation: UTA-2026-011 (Unattributed Threat Actor — internal Hunters Ledger tracking label; see Section 7)
• Named-actor attribution: INSUFFICIENT (<50%) — cannot attribute to any named threat actor
• Single-operator-cluster identity: HIGH 87% (three registrar-level org-ID locks + synchronized cross-registrar MX rotation events + stable Parklogic customer ID + leaked machine-ID)
• Motive: Financial — HIGH 90% (credential theft + TDS monetization; no destructive tooling; no espionage TTPs; no political messaging)
• Possible self-brand: “Beast” observed in 3 of 45 toolkit filenames (beast-dashboard.py, beast-notify.py, gen-beast-page.py) — UNVERIFIED against forum/Telegram corpora. Open hypothesis.

For Technical Teams

Immediate priorities for SOC analysts, threat hunters, and incident responders:

• CVE-2026-41940 mitigation comes first. Patching is the primary lever for cPanel/WHM customers. See Section 4 for the three-stage exploit chain and Section 9 for detection content.
• Hunt the operator infrastructure. The Werkzeug /login-2fa C2 fingerprint, the three registrar org-ID hashes, the mx.plingest.com MX backend, the pkAId=2143526812 TDS parameter, and the operator IP cluster on AS14956 are all defender-actionable. See Section 5 for hunting queries.
• The toolkit is operator-side, not victim-side. The 37 SHA256s are useful for forensic disk imaging of suspected operator-controlled hosts, not for victim-endpoint scanning. YARA byte-pattern detection against the toolkit is impossible — no source code was recovered.
• Detection deliverables are Sigma + Suricata-focused. A single hash-based YARA rule covers the 8 highest-value toolkit files; 9 Sigma rules cover CVE-2026-41940 exploitation patterns and operator infrastructure indicators; 3 Suricata signatures cover network-side detection. See linked detection file in Section 9.
• OpenClaw AI agent platform on operator filesystem is a novel observation, not a confirmed offensive capability. Track as data, not as actionable threat capability — see Section 8.

2. Threat Context — CVE-2026-41940 and the cPanel Shared-Hosting Ecosystem

Analyst note: This section explains the vulnerability the operator weaponizes, the scale of the affected ecosystem, and the timeline of broader exploitation. It is intended to be readable by SOC managers and risk owners who need to understand “why this CVE matters” before reading the technical exploit chain in Section 4.

2.1 CVE-2026-41940 in plain language

cPanel and WHM are the dominant shared-hosting administration panels worldwide — used by small businesses, hosting resellers, and managed-services providers to run thousands of customer websites and mailboxes on a single Linux server. CVE-2026-41940 is an unauthenticated authentication bypass in cPanel and WHM: an attacker who can reach the panel over the network can become an authenticated WHM-root user without knowing any password.

The technical mechanic is a CRLF (carriage-return / line-feed) injection in the Authorization: Basic HTTP header. By splicing a carefully-formatted byte sequence into the header, the attacker triggers two downstream bugs in cPanel’s session-handling code: an “encryption skip” via the expired=1 marker (the session-decryption routine is bypassed), followed by session promotion that issues a valid cpsessXXXX session token at WHM-root privilege.

What WHM-root access yields to an attacker:

• Full read/write access to every customer cPanel account on the host
• Every website’s source code, file system, and database (potentially hundreds of websites per host)
• Every mailbox on the host (read inbox, set forwarding rules, send mail as the customer)
• Ability to create new accounts, new SSH users, new email-forwarding rules, and new authentication tokens

2.2 Scale and adoption timeline

The 14-day weaponization lag is consistent with rapid-adoption tradecraft seen for other high-severity server-side bypass CVEs — not zero-day-actor tradecraft. The operator is not the first observed CVE-2026-41940 exploiter. Whether the same operator participated in the pre-disclosure February exploitation cannot be determined from publicly available evidence; host-side forensics on February victims would be needed to resolve this.

2.3 The three-stage exploit chain

Analyst note: This subsection is a high-level walkthrough of the public exploit chain published by watchTowr Labs and Rapid7. SOC analysts who need the implementation details for a WAF rule should read Section 4.1 (Stage 1 — Initial Access) and the Sigma rules in the linked detection file.

The exploit chain has three stages, all unauthenticated:

1. CRLF injection in Authorization: Basic header. The attacker sends an HTTP request to cPanel’s authentication endpoint with a base64-decoded username portion containing raw \x00, \x0a, or \x0d bytes. cPanel’s pre-decryption routine treats these bytes as field-terminators in a way the original developers did not anticipate.

2. Encryption skip via expired=1. The CRLF-injected payload contains a downstream marker expired=1. The session-decryption code interprets this as “session is expired, skip decryption and reissue” rather than its intended meaning (“validate then reject”). The cipher block that would normally protect session creation is bypassed.

3. Session promotion to WHM-root. Once encryption is skipped, cPanel issues a fresh cpsessXXXX token. The token is keyed to a privilege level controlled by the original (manipulable) request — the attacker requests root, the system grants root. The attacker now holds a WHM-root session cookie and can perform any administrative action.

Two public proof-of-concept repositories existed at the time of investigation: watchtowrlabs/cve-2026-41940 (the disclosing researcher’s PoC) and ynsmroztas/cPanelSniper (a community-maintained scanning wrapper). The operator’s pipeline-41940.sh file is 10,219 bytes; whether it wraps one of these public PoCs, implements the operator’s own exploit from root-cause analysis, or is aspirational cannot be determined from filename and size alone (this remains a MODERATE-confidence uncertainty).

2.4 What this means for defenders

• Patching is the primary lever. cPanel released a fix in late April 2026; affected versions are documented in the cPanel security advisory. Hosting providers should be at the patched version by the time this report is read.
• WAF/reverse-proxy inspection is the secondary lever. A WAF in front of cPanel/WHM (ports 2083, 2087) that inspects the Authorization: Basic header for raw \x00/\x0a/\x0d bytes will block the exploit independent of the patch state. The Sigma and Suricata rules in the linked detection file implement this pattern.
• Hosting customers should monitor. Customers should look for new WHM/cPanel accounts created outside admin sessions, new SSH authorized_keys entries, new email-forwarding rules, and new webshell drops in customer doc-roots. These are post-exploitation persistence patterns associated with this CVE per the cPanel advisory and the watchTowr/Rapid7 writeups.

3. Technical Classification

3.1 Classification table

3.2 File-level identifiers

The operator’s toolkit comprises 45 files total: 37 with successful SHA256 recovery; 8 permanently unrecoverable due to open directory crawler rate-limit cooldowns on the operator’s single-threaded python -m http.server socket. File composition:

3.3 The eight highest-value toolkit files (curated subset)

These eight files are the highest-leverage forensic artifacts from the 37-hash recovered set, selected for their role in the operator’s kill chain. This is a curated subset for narrative reference, not an IOC inventory — hashes are shown as 12-character previews; the full SHA256 values for these and the remaining 29 recovered files are maintained in the IOC feed at threat-intel-vault/ioc-feeds/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-iocs.json.

3.4 Why this is intermediate-mature, not nation-state

Indicators of maturity:

• 15+ months observable infrastructure rotation (Feb 2025 — May 2026)
• 5+ registrar diversification with org-ID-locked pairs across WEBCC, NameCheap, Dynadot, Whoisprotection.cc, and Withheld for Privacy ehf
• Scripted same-day domain registration → certificate → activation pipeline (sub-1-hour: quick-barber.com registered, certed by Let’s Encrypt, and A-record-pointed at the operator’s box all within less than 1 hour on 2026-05-02)
• Versioned filenames showing iterative development (mass_v4..v8, live-dashboard-v10, harvest_whm → _v2)
• JARM template consistency across operator boxes (consistent with image-based deployment of a “Gen-2” build template)
• Cloudflare anti-attribution NS-fronting on newer domains (eps-soltec.cloud, tesaco.sbs, mrrbno.shop)

Indicators of dev-hygiene gaps (below nation-state threshold):

• Exposed python -m http.server on port 7777 (this is how the toolkit was discovered)
• Exposed Werkzeug dev server on internet-facing port 8888 (production C2 should use gunicorn/uWSGI behind nginx)
• Default OS hostname certs on legacy boxes
• All operator infrastructure on a single ASN (AS14956 RouterHosting LLC)
• Operator Linux /etc/machine-id leaked via systemd-private-tmp paths in the open directory listing

The combination of mature operational tradecraft with these specific OpSec gaps is consistent with a financially-motivated cybercriminal who optimizes for throughput over stealth — not with a nation-state actor where machine-ID leakage would be operationally disqualifying.

4. Technical Capabilities Deep-Dive

Executive Impact Summary: The operator runs an end-to-end shared-hosting credential-harvesting pipeline. Their distinctive contribution is not any single technique but the integration: internet-wide scanning → multi-vendor admin-panel exploitation → CVE-2026-41940 weaponization → credential cracking → multi-theme phishing page generation → Parklogic TDS monetization. The full pipeline runs from operator-controlled infrastructure and is invisible to victim endpoints. Defender leverage comes from CVE patching, WAF inspection of Authorization: Basic headers, and infrastructure hunting against the operator’s C2 fingerprint.

Quick reference: capabilities matrix

4.1 Stage 1 — Initial access via CVE-2026-41940 (the kill chain entry point)

Analyst note: This is the operator’s primary entry vector into customer cPanel/WHM hosts. The exploit chain is fully public (watchTowr Labs and Rapid7 have published root-cause analyses), so this section describes the chain at the level needed to understand detection content — not as a how-to. Defenders should focus on the three discriminator strings called out in the detection section: raw CRLF bytes inside an Authorization: Basic header, the expired=1 marker in the payload, and the msg_code:[expired_session] confirmation marker in successful-exploit responses.

Confidence: HIGH (filename pipeline-41940.sh literally encodes the CVE; size and naming consistent with an orchestrator script).

Mechanism (summarized): A single HTTP request to the cPanel/WHM authentication endpoint contains a CRLF-injected Authorization: Basic header. The injected bytes trigger an encryption-skip in the session-decryption routine, which then issues a fresh cpsessXXXX session token at WHM-root privilege.

What was observed in this investigation:

• Filename pipeline-41940.sh (10,219 bytes) — orchestrator script
• Filename poc-fixed.py (3,754 bytes) — “fixed” PoC, likely operator-patched public PoC
• Filename trace_auth.py (4,076 bytes) — auth-flow tracing utility (useful for CRLF-injection exploit development)
• Filename whm-hunter.py (20,531 bytes) — primary post-exploitation WHM credential harvester

The orchestrator likely chains scanner → exploit → session-token capture → credential dump. The internal call graph cannot be confirmed without source code.

Detection priorities (vendor-side, for cPanel/WHM customers):

1. WAF or reverse proxy in front of TCP/2083, TCP/2087, TCP/443 inspecting Authorization: Basic header for raw \x00, \x0a, \x0d bytes after the Basic prefix
2. Web server access log detection of expired=1 token inside Authorization headers
3. HTTP response-body monitoring for msg_code:[expired_session] success marker
4. File integrity monitoring on /var/cpanel/users/, ~/.ssh/authorized_keys, and `cPanel email-forwarding configuration

4.2 Stage 2 — Internet-wide mass scanning

Analyst note: This stage is the top-of-funnel for the operator’s pipeline. Mass-scanning tools enumerate internet-exposed cPanel, WHM, Plesk, and DirectAdmin instances before any exploitation occurs. The 10+ versioned scanner variants on disk indicate sustained iterative development, not a one-off tool download.

Confidence: HIGH (10+ scanner variants observed by filename across 3 development generations).

Observed scanner variants:

The coexistence of v4 through v8 mass scanners alongside earlier mass_scanner_v2/v3 and a mass_probe family signals active iterative development over a multi-month timeframe. The operator keeps prior versions alongside current ones — consistent with A/B comparison and rollback discipline. (Version numbers do not prove 10 iterations occurred; numbering can start at any digit.)

The masscan-boost.sh wrapper around the open-source masscan tool indicates the operator is comfortable bridging custom Python with off-the-shelf scanners for the heaviest network-throughput work.

4.3 Stage 3 — Multi-vendor admin-panel coverage

Analyst note: This stage shows the operator’s scope extends beyond CVE-2026-41940. Separate scanners and harvesters target cPanel, WHM, Plesk, and DirectAdmin — the four dominant shared-hosting control panels. This means defenders cannot rely solely on patching one CVE; the broader panel ecosystem is in scope.

Confidence: HIGH (filenames explicitly cover four major panels).

The operator is not cPanel-only. CVE-2026-41940 is the current high-leverage entry vector, but the toolkit treats the entire small-business shared-hosting ecosystem as in-scope. The Plesk, DirectAdmin, and SSH scanners suggest opportunistic coverage across all major panels — consistent with a mature pipeline where new CVEs are grafted onto a generic credential-harvesting platform.

4.4 Stage 4 — Multi-target credential cracking

Analyst note: This stage converts a list of discovered admin-panel hosts into validated stolen credentials. The operator’s unified_cracker.py likely combines brute-force, dictionary attack, or post-exploitation credential harvesting — the exact method cannot be confirmed without source code, but the output feeds the live Flask C2 dashboard.

Confidence: MODERATE (function inferred from filename; no source observation).

The toolkit explicitly contains unified_cracker.py (FAILED hash, 8,752 bytes per directory listing) and the per-vendor harvesters cited above. The likely workflow is: scanner produces candidate hosts → cracker runs credential-guessing / brute-force or post-exploit harvest against the candidates → results land in the C2 dashboard.

unified_cracker naming suggests a multi-target wrapper consistent with the multi-vendor scanner suite. Whether it implements credential brute-force, dictionary attack, password spraying, or post-exploit credential dump cannot be determined from filename alone.

4.5 Stage 5 — Multi-theme phishing page generation

Analyst note: The phishing layer is downstream of the CVE-2026-41940 entry vector. Compromised cPanel/WHM hosts are used to host operator-generated phishing pages on legitimate-looking subdomains. This stage uses customer hostname space as the phishing-landing infrastructure, making block-by-IP responses ineffective.

Confidence: HIGH (filename gen-beast-page.py plus observed multi-theme phishing destinations).

File: gen-beast-page.py (23,650 bytes — the third-largest file in the toolkit).

Observed phishing themes (from passive DNS + visited URL evidence):

• Office 365 enterprise: https://officebyt.e56sutx.eps-soltec.cloud/f/d6aba322369c and similar subdomain-token patterns
• Tech-support / Amazon spoof: supportsite.info family
• Multi-brand consumer phishing: Coinbase (coinbase-co.cc), KuCoin (kucoinsgem.xyz), Brazilian Receita Federal (receita-federal.com), Yahoo (yahoohelp.com), LATAM Airlines, Livelo rewards, Netflix, AT&T, Bet365

The naming convention <keyword>.<8-12-char hex-token>.<corp-sounding-domain> is consistent across operator-owned domains (e56sutx.eps-soltec.cloud, mmnsdvrt8.eps-soltec.cloud) and afraid.org-abused donor domains (mail.hcjs2.jlengineering.se) — a single kit-generated subdomain pattern reused across infrastructure.

4.6 Stage 6 — Live Flask C2 dashboard

Analyst note: This is the operator’s harvest-tracking and operations console. It runs on the operator’s infrastructure, not victim infrastructure — defenders cannot directly remediate it, but they can use its banner fingerprint to hunt for peer operator infrastructure on Shodan and Censys.

Confidence: HIGH (direct passive observation, captured 2026-05-17).

Live banner (HTTP HEAD against 216.126.227.49:8888 on 2026-05-17 13:53 UTC):

HTTP/1.1 302 FOUND
Server: Werkzeug/3.1.8 Python/3.13.12
Date: Sun, 17 May 2026 13:53:18 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 207
Location: /login-2fa
Vary: Cookie
Connection: close

Distinctive elements:

• Server: Werkzeug/3.1.8 Python/3.13.12 — Flask’s development server banner. Production Flask deployments should use gunicorn or uWSGI behind nginx; the dev server on an internet-facing port is an OpSec gap.
• Location: /login-2fa — operator-named path. Flask defaults would be /login or /auth/login. This is the discriminator string for the Shodan/Censys hunt query.
• Vary: Cookie — session-cookie authentication flow on the C2 dashboard, consistent with a 2FA login workflow.
• TLS JARM: 27d40d40d00040d00042d43d000000d2e61cae37a985f75ecafb81b33ca523 (note: the 27d40d40d00040d00042d43d000000 prefix is too common for standalone use, but the full hash is a stable operator pivot).

Hunt queries (defender-actionable):

• Shodan: http.server:"Werkzeug/3.1.8" "login-2fa" port:8888
• Censys: services.http.response.headers.server: "Werkzeug/3.1.8" AND services.http.response.headers.location: "/login-2fa" AND services.http.response.status_code: 302

These queries are first-documented in this investigation. Any peer Werkzeug+/login-2fa C2 dashboards surfaced by these queries are candidate operator infrastructure or candidate peer-operator infrastructure using the same toolkit fork — both are valuable.

4.7 Stage 7 — Parklogic TDS monetization layer

Analyst note: A TDS (Traffic Distribution System) is the layer between a phishing page’s “click” and the final landing destination. Operators use TDSs to (a) filter out security researchers, sandboxes, and Googlebot from real victims, and (b) monetize traffic that does not match the operator’s primary phishing intent by routing it to parked-domain monetization platforms. The Parklogic abuse here is unusual because Parklogic itself is a legitimate domain monetization platform — this operator is its customer, not a compromise of the platform itself.

Confidence: HIGH (operator Parklogic customer ID pkAId=2143526812 stable across 11 operator-owned parked landing domains).

Observed architecture:

• Parklogic.com is a legitimate domain monetization platform (0/92 malicious on VirusTotal; Cisco Umbrella rank 37,769).
• Operator is a Parklogic customer with account ID pkAId=2143526812.
• 11 operator-owned parked landing domains are configured as Parklogic-monetized: adorarama.com, gocomper.com, and the 7 runwaylander* siblings (runwaylander.com, runwaylanderplace.com, runwaylanderhome.com, runwaylanderspot.com, runwaylanderlights.com, runwayparking.com, runwaylanderstreet.com), plus coinbase-co.cc and receita-federal.com.
• Landing-domain IPs (172.237.149.231, 172.234.24.120) are Parklogic-controlled, not operator-exclusive — they are shared with all Parklogic customers. Blocking by IP would have a HIGH false-positive rate.
• 5 confirmed operator-controlled source-referer brand-spoof domains route TDS traffic: kucoinsgem.xyz, checkwithsec.online, coinbase-co.cc, receita-federal.com, yahoohelp.com.

Important caveat — do not over-attribute: the operator’s TDS architecture surfaces approximately 55 additional brand-spoof source-referer domains. Of these, only the 5 above are verified operator-controlled through registrar org-ID locks or infrastructure matches. The remaining ~55 are unverified candidates. Treat the verified 5 as defender-actionable and the unverified 55 as hunt candidates pending per-domain validation.

4.8 Stage 8 — Same-day domain registration → cert → activation pipeline

Analyst note: This stage describes the operator’s ability to stand up new phishing campaigns within an hour. Domain registration, TLS certificate issuance via Let’s Encrypt, and DNS activation are all automated — meaning a new phishing campaign can be live before threat intelligence feeds have time to catalog and distribute the new domain.

Confidence: HIGH (direct observation of quick-barber.com lifecycle 2026-05-02).

Observed example: quick-barber.com was registered, certified by Let’s Encrypt, and A-record-pointed at the operator’s Gen-1 box (216.126.224.181) all within less than 1 hour on 2026-05-02. This pipeline is automated — the operator can spin up new phishing campaigns within an hour of choosing a domain.

The implication for defenders: by the time a new operator domain is observed in passive DNS, the certificate is already issued and the phishing campaign is already live. URL/domain-block latency from threat intel feeds is unlikely to meaningfully constrain this operator. Hunt queries against the operator’s CT-log subject pattern and the Werkzeug+/login-2fa C2 banner are higher-leverage than chasing individual phishing domains.

4.9 Anti-attribution layering

Cloudflare NS-fronting on newer domains (eps-soltec.cloud, tesaco.sbs, mrrbno.shop) hides the backend IP from passive-DNS pivoting. Published domain-threat research indicates a significant fraction of blocklist-tracked malicious domains use Cloudflare nameservers for this attribution-evasion purpose. Direct A-records on older/disposable domains (pernex.online, supportsite.info) show less OpSec discipline in earlier operator infrastructure — a temporal trend toward more careful operator behavior.

afraid.org FreeDNS abuse on multi-tenant donor domains. The operator created mail.hcjs2.jlengineering.se as one tenant on a multi-tenant FreeDNS-enrolled donor domain (the legitimate Swedish engineering firm jlengineering.se had its domain enrolled in afraid.org’s FreeDNS service, which allows any user to create DNS records on donor domains without consent). The operator is not compromising jlengineering.se — they are exploiting an architectural property of afraid.org’s multi-tenant DNS model.

5. Operator Infrastructure Analysis

5.1 Operator IPs on AS14956 RouterHosting LLC

Analyst note: AS14956 RouterHosting LLC is a US-based VPS provider with documented abuse history across ThreatFox, AbuseIPDB, and Scamalytics. The operator has maintained 9 IPs on this ASN for 15+ months without observed takedown. This pattern is consistent with an abuse-tolerant acceptable-use policy (AUP) or a slow-responding network operations center, though no formal “bulletproof hosting” listing exists. RouterHosting is rated SUSPECTED-but-not-CONFIRMED bulletproof.

Additional historical infrastructure: 5 MODERATE-confidence historical operator IPs on AS14956 (including 216.126.224.181 flagged with prior-gen commodity-malware distribution observed April 2026 — likely different RouterHosting tenant after operator departure) are maintained in the IOC feed at threat-intel-vault/ioc-feeds/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-iocs.json. These rotations were observed across the passive DNS chronology and same-day registration pipeline observations (e.g., quick-barber.com) but are not included as standalone rows here to avoid duplicating IOC-feed content in the report body.

Operator MX backend on AS63023 GTHost:

Parklogic TDS shared infrastructure (on AS63949 Akamai/Linode — Parklogic-controlled, not operator-exclusive):

5.2 Three registrar-level same-operator org-ID locks

Analyst note: WHOIS org-ID hashes are per-customer-account hashes maintained by each registrar’s privacy service. When two domains share the same org-ID hash within the same registrar, it almost always means they are registered under the same customer account. Intra-registrar collisions between unrelated legitimate accounts are negligible (roughly 1 in 2^64). Observing three independent registrar-level locks in a single operator profile is exceptional in the cybercrime literature — typical published profiles report zero or one.

The Dynadot lock is cross-validated by synchronized MX rotation events (see 5.3), which drives the probability of coincidence on those additional domains to effectively zero.

5.3 Synchronized MX rotation — ruling evidence for single-operator identity

This is the ruling evidence for the HIGH 87% single-operator-cluster identity verdict (ACH H1 winner for Q1):

Multi-domain coordination events at 1-3 hour temporal resolution are forensically rich and rare in cybercrime literature. They are the single highest-quality single-operator-identity evidence in this investigation.

5.4 Operator MX backend mx.plingest.com — cross-cluster attribution anchor

A shared MX record across three otherwise-separate registrar/privacy clusters:

• supportsite.info (oldest operator domain)
• adorarama.com (Dynadot org-ID lock)
• gocomper.com (Dynadot org-ID lock)

A single dedicated MX backend across this many cross-registrar domains resolves clusters as same-operator that would otherwise appear disjoint.

Retraction: An earlier framing of 38.143.66.193 as a multi-purpose commodity-malware C2 node was retracted during investigation. The supposed Rhadamanthys / Phorpiex / GandCrab evidence was a researcher-uploaded sample on VirusTotal with no confirmed network connection to .193. The IP’s role is now established as operator MX backend only.

5.5 supportsite.info IP-rotation chain — definitive cluster pivot backbone

supportsite.info is the operator’s oldest confirmed domain (registered 2025-02-20). Its A-record has rotated across 7 of the 9 confirmed operator IPs between September 2025 and January 2026:

The chain links 7 of 9 operator IPs and is the definitive pivot backbone of the cluster. This is what allows the analyst to confidently say “these 9 IPs are the same operator” rather than “these are 9 unrelated VPS tenants on the same ASN.”

5.6 Operator domain inventory (HIGH-confidence operator-controlled, 17 domains)

Note on operator vs. shared infrastructure: The 17 domains listed below are operator-controlled. The 11 Parklogic TDS landing domains are operator-owned but hosted on Parklogic-shared infrastructure. The 5 confirmed TDS source-referer brand-spoof domains are operator-controlled. The ~55 additional unverified candidates are NOT included — over-attribution would corrupt downstream block lists.

Phishing destination domains: pernex.online, eps-soltec.cloud, tesaco.sbs, mailmanagement.cfd, supportsite.info, kwpbby.in, mrrbno.shop, ltamaeropromoweb-ecuador-travel.shop, quick-barber.com

Operator MX backend domain: plingest.com (+ mx.plingest.com)

Confirmed TDS source-referer brand-spoofs: kucoinsgem.xyz, checkwithsec.online, coinbase-co.cc, receita-federal.com, yahoohelp.com

Parklogic TDS landing parent domains (11 total): adorarama.com, gocomper.com, runwaylander.com, runwaylanderplace.com, runwaylanderhome.com, runwaylanderspot.com, runwaylanderlights.com, runwayparking.com, runwaylanderstreet.com, plus coinbase-co.cc and receita-federal.com (also brand-spoofs)

5.7 Pivoting expansion

6. Static and Dynamic Findings

Source caveat. The operator’s port-7777 development server died ~5 days post-discovery. No source code was ever persisted to disk. “Static analysis” below means filename + size + ecosystem context inference. “Dynamic analysis” means passive observation of operator infrastructure (live C2 banner, port scan, passive DNS chronology) and passive collection of operator filesystem artifacts (directory layout, timestamps, machine-ID leak). Treat these as behavioral indicators of the operator’s environment and workflow, not of the malicious tooling’s runtime behavior, which was never observed.

6.1 Static analysis findings

Strings of forensic value (from filename inventory and live C2 fingerprint):

Inferred dependencies (no source observation; MODERATE confidence):

No Windows-specific APIs are observed. The operator’s current platform is Linux + Python + Flask + Let’s Encrypt; prior-generation infrastructure (.181, .105.176) used Windows + XAMPP + Apache.

6.2 Dynamic (passive) observation timeline

Analyst note: This is a chronological reconstruction of operator behavior across the observation window. Timestamps in UTC where available. The timeline tracks operator-side activity, not victim-side execution — no malware sample was detonated in a sandbox.

T-15 months (approx 2025-02-20): First operator domain registration — supportsite.info. Marks the earliest confirmed operator activity.

T-15 months (2025-02-23): Earliest confirmed operator-attributable IP rotation — supportsite.info resolves to 45.61.128.128 (operator’s earliest IP).

2025-08-01: Synchronized MX rotation — adorarama.com + gocomper.com both switch to mx.plingest.com within ~1 hour of each other. Ruling evidence for single-operator identity.

2025-12 (approximate): Operator activates the Parklogic TDS landing layer (pkAId=2143526812). Earliest operator-attributable TDS landing hostname observed.

2026-01-09: Synchronized MX rotation — adorarama.com + gocomper.com both switch back to mx156.hostedmxserver.com within ~3 hours of each other. Second ruling-evidence event.

2026-04-28: CVE-2026-41940 publicly disclosed by cPanel.

2026-05-01 16:10:09 UTC: First OpenClaw execution timestamp recovered from operator’s Node.js compile-cache (v22.22.1-x64-9de703df-0 / 1777651809344 ms-epoch). 4 days post-CVE disclosure.

2026-05-01: CISA adds CVE-2026-41940 to KEV catalog.

2026-05-02: quick-barber.com registered, certed by Let’s Encrypt, and A-record-pointed at operator Gen-1 box — all within less than 1 hour. Same-day pipeline directly observed.

2026-05-12: Operator’s port-7777 development python -m http.server socket exposes their working filesystem. The open directory crawler crawls and hashes 37 of 45 toolkit files. 8 hashes fail due to operator-side rate-limiting cooldowns hitting the single-threaded HTTP server.

2026-05-12 to 2026-05-17: Port-7777 dev server dies sometime in this window. Port-8888 Flask C2 dashboard remains live.

2026-05-17 13:53 UTC: Single passive HTTP HEAD captures Flask C2 dashboard banner — Werkzeug/3.1.8 Python/3.13.12 + 302 → /login-2fa. Port scan confirms only TCP/22 (SSH) and TCP/8888 (Flask C2) open across a 20-port sweep.

6.3 Operator persistence (operator-side, not victim-side)

• live-dashboard-v10.py runs as a long-lived Flask process on TCP/8888 of 216.126.227.49. The dashboard survives across multiple days of observation (reachable 2026-05-12 and again 2026-05-17), suggesting either a systemd service unit, a tmux detached session, or a nohup background process. The operator filesystem listing showed /tmux-0/ (tmux user-0 socket directory) at the root of the exposed working directory — consistent with running the dashboard inside a tmux session.
• /etc/machine-id 6e3644a97f844763a34565b865d35310 is persistent across reboots on this VM. If the operator clones this VM image to a new IP without resetting machine-id, the clone will leak the same value via systemd-private-tmp paths — a future definitive same-VM pivot.

6.4 Victim-side persistence (inferred from toolkit composition; not observed)

Files in the toolkit consistent with post-exploitation persistence on compromised cPanel/WHM hosts:

• gen-cpanel-access.py (FAILED hash, 6,070 B) — likely generates cPanel access artifacts
• gen-sessions.py (5,754 B) — likely forges session cookies

A successful CRLF injection yields a cpsessXXXX token granting WHM-root access. Post-exploitation persistence patterns associated with this CVE (per cPanel advisory and Rapid7 / watchTowr Labs writeups) include:

• New WHM/cPanel account creation outside admin sessions
• New SSH user creation or new ~/.ssh/authorized_keys entries
• Webshell drop into customer doc-root directories
• New email-forwarding rules on compromised mailboxes
• Scheduled-task creation for re-entry

6.5 Code-pattern inferences (no source observation)

1. Versioned active development — 5 coexisting mass_v[4-8].py files plus earlier mass_scanner_v[2-3].py plus mass_probe_v[3-4].py plus harvest_whm → _v2, harvest-v3.py, live-dashboard-v10.py. Operator keeps prior versions alongside current ones — consistent with A/B comparison and rollback discipline.

2. CVE-specific orchestrator grafted onto generic harvester platform. pipeline-41940.sh is a single CVE-named orchestrator surrounded by generic scanners and crackers. Consistent with a mature operator who adds new CVE capability to an existing pipeline; equally consistent with an operator who copied a public PoC into a folder of separately-downloaded generic harvester tools. Filename-only inference cannot distinguish.

3. Multi-vendor admin-panel coverage — toolkit explicitly covers cPanel, WHM, Plesk, DirectAdmin Webmail. Operator is not cPanel-only.

4. “Beast” self-branding — 3 of 45 files share Beast brand identity. Open hypothesis: operator’s own self-brand, operator licensed/forked an existing Beast-branded criminal-forum kit, or coincidental naming. Underground-forum / Telegram-corpus search would resolve.

5. Phishing-kit generator with theme support — gen-beast-page.py at 23,650 bytes suggests a template engine with multi-theme support, consistent with observed Office 365 + Amazon + multi-brand phishing destinations.

6. Operator-templated boxes — JARM 27d40d40d00040d00042d43d000000 prefix identical across 216.126.227.49 and 144.172.103.253, consistent with snapshot/image-based deployment of the operator’s “Gen-2” build template. JARM prefix alone is too common (Ubuntu + OpenSSL + Python + Let’s Encrypt) for standalone same-operator pivot but corroborates the domain-rotation evidence.

7. Same-day domain → cert → activation pipeline — quick-barber.com registration → cert → A-record in less than 1 hour on 2026-05-02. Automation in place.

8. Cloudflare anti-attribution layering on newer domains hides backend IPs; direct A-records on older/disposable domains show less OpSec discipline in earlier infrastructure — a temporal trend.

7. Threat Actor Assessment — UTA-2026-011

Note on UTA identifiers: “UTA” stands for Unattributed Threat Actor. UTA-2026-011 is an internal tracking designation assigned by The Hunters Ledger to actors observed across analysis who cannot yet be linked to a publicly named threat group. This label will not appear in external threat intelligence feeds or vendor reports — it is specific to this publication. If future evidence links this activity to a known named actor, the designation will be retired and updated accordingly.

The full UTA profile is maintained at threat-intel-vault/threat-actors/UTA-2026-011.md. This section summarizes the attribution evidence, ACH-tested conclusions, and explicit gaps.

7.1 Attribution conclusion

The investigation answers three attribution questions:

7.2 UTA gate evaluation

The UTA-2026-011 designation was assigned only after both gates passed with substantial margin:

7.3 Eleven distinguishing characteristics

Technical / infrastructure fingerprints (6):

1. Three independent registrar-level org-ID locks observed simultaneously — WEBCC 20c6e82190de8bc4, NameCheap 4b7a0912c26a13e2, Dynadot 473daf17453d83cd. Exceptional in cybercrime literature.
2. Operator Linux /etc/machine-id 6e3644a97f844763a34565b865d35310 leaked via systemd-private-tmp paths — unique per OS install; survives reboots; propagates to VM clones. Definitive future same-machine pivot.
3. Operator Parklogic monetization customer ID pkAId=2143526812 stable across 11 operator-owned TDS landing parked domains. Definitive cross-domain attribution anchor.
4. Operator-controlled MX backend mx.plingest.com on 38.143.66.193 (AS63023 GTHost) — shared across three otherwise-separate registrar/privacy clusters.
5. Synchronized 1–3-hour MX rotation across adorarama.com + gocomper.com on 2025-08-01 and 2026-01-09. Ruling evidence for Q1.
6. Novel Flask C2 banner fingerprint on TCP/8888 — Werkzeug/3.1.8 Python/3.13.12 + 302 → /login-2fa. Hunt-ready Shodan/Censys queries.

Behavioral fingerprints (5):

1. CVE-2026-41940 weaponization pipeline filename pipeline-41940.sh literally encodes the CVE number — uncommon and operator-specific.
2. Possible “Beast” operator self-brand observed in 3 of 45 toolkit files. UNVERIFIED — open hypothesis.
3. OpenClaw AI agent platform install footprint at /openclaw/2026.4.29/ with first-execution timestamp 2026-05-01 16:10:09 UTC. Filesystem presence MODERATE-HIGH; offensive use LOW-MODERATE / UNCONFIRMED. See Section 8.
4. 10+ versioned scanner/dashboard variants coexisting on disk — sustained 6+ month internal development cycle.
5. afraid.org FreeDNS donor-domain abuse for legitimate-corporate-looking phishing URLs — confirmed donor jlengineering.se, MODERATE additional groundsstudio.com.

7.4 ACH (Analysis of Competing Hypotheses) — summary

Analyst note: Analysis of Competing Hypotheses (ACH) is a structured analytic technique where multiple hypotheses are tested against the same evidence matrix, and the hypothesis with the fewest inconsistencies wins. The technique is designed to counter confirmation bias by forcing analysts to weigh alternative explanations against the same data.

Q1 — single-operator cluster identity:

• Winner — H1: Single experienced cybercrime operator (UTA) — 0 inconsistencies in the 10-evidence matrix
• Runner-up — H2: Small multi-person criminal group (2-5 people) — 0 inconsistencies but no positive multi-person evidence
• Ruling evidence: Synchronized 1–3-hour MX rotation across two Dynadot-registered domains on 2025-08-01 (and 3-hour rotation on 2026-01-09) requires a single operator with administrative access to both domains’ DNS at both events

Q2 — named-actor attribution:

• Winner — H1: Previously-undocumented independent operator (UTA-track) — 0 inconsistencies
• Runner-up — H5: “Beast” criminal-forum kit operator — needs Telegram corpus search
• Ruling evidence: Zero overlap with 10 existing UTAs; zero public Tier-1/2/3 attribution to named actor; 0/7 distinctive hashes on VT; 0 operator-relevant GitHub hits across 14 queries; no language/time-zone/geolocation operator-side signal

Q3 — motive:

• Winner — H1: Financial (credential theft + TDS monetization) — 0 inconsistencies
• Ruling evidence: All monetization streams commercial; no destructive tooling; no espionage TTPs; no political messaging

7.5 Alternative hypotheses considered and ruled LOW

7.6 “Beast” — open hypothesis, not confirmed

The string “Beast” appears in 3 of 45 toolkit files (beast-dashboard.py, beast-notify.py, gen-beast-page.py) and could represent:

• (a) The operator’s own self-brand — possibly with intent to advertise or share the kit
• (b) A licensed customer or fork of an existing “Beast”-branded criminal-forum kit-vendor
• (c) Coincidental naming

This investigation could not validate any of these scenarios. GitHub Code Search returned 0 operator-relevant hits across 14 distinctive string queries; no Telegram or underground-forum corpus search was performed. The hypothesis remains open. If future intelligence surfaces a Beast-branded kit-vendor on a criminal forum or Telegram channel, this designation may shift from INSUFFICIENT to LOW or MODERATE named-actor attribution.

7.7 Gaps and what would shift attribution

Specific evidence that would shift this profile from INSUFFICIENT named-actor attribution to LOW/MODERATE/HIGH:

7.8 Recommended follow-up research

8. OpenClaw AI Agent Platform Observation

Analyst note: This section addresses a novel observational data point — the operator has an OpenClaw AI agent platform install footprint on their working filesystem. The framing of this section is deliberately cautious. Filesystem presence is MODERATE-HIGH confidence (real platform, real version, real first-execution timestamp recovered from operator-side artifacts). Offensive use of the platform is LOW-MODERATE / UNCONFIRMED. The investigation could not recover evidence demonstrating that the operator is using OpenClaw to develop offensive tooling. This is not a “the operator is using AI to build malware” finding — it is a “AI-agent-platform presence on an offensive operator’s working filesystem is novel observational data” finding.

8.1 What was observed

8.2 What this is and is not

OpenClaw is a real platform. The install footprint was independently verified — OpenClaw v2026.4.29 is a documented release of a real AI agent platform. The version path, Node.js runtime build hash, and first-execution timestamp are mutually consistent with a genuine install on the operator’s working VM.

The first-execution timestamp (2026-05-01 16:10:09 UTC) is approximately 4 days post CVE-2026-41940 disclosure (CVE disclosed 2026-04-28). The temporal proximity is suggestive but not probative — millions of OpenClaw installs began in early 2026, and the disclosure timing is coincidental from a population-base-rate standpoint.

What is NOT established:

• Whether the operator uses OpenClaw to develop their offensive toolkit
• Whether OpenClaw was used to generate any of the 45 toolkit files
• Whether OpenClaw access is integrated into the operator’s C2 dashboard, scanner orchestration, or phishing-page generation
• Whether the operator uses OpenClaw for general-purpose developer productivity (entirely consistent with the observation)

What IS established:

• The operator has installed and executed OpenClaw on their working VM
• The operator’s working VM is the same VM running the live Flask C2 dashboard (same /etc/machine-id, same filesystem)
• The platform is therefore co-resident with offensive infrastructure, not on a separate sandbox

8.3 OpenClaw security context (2026)

The 2026 OpenClaw security crises documented by Zscaler ThreatLabZ, Barracuda Networks, Reco.ai, and The Hacker News include:

• The ClawHavoc supply-chain campaign (~1,100+ malicious OpenClaw “skills” delivered via the official skill marketplace)
• The DeepSeek-Claw malicious skill delivering Remcos RAT and GhostLoader payloads
• The ClawJacked flaw (February 2026) affecting OpenClaw skill-permission boundaries

None of these documented OpenClaw security crises are observed in this investigation. The operator’s install appears to be a stock 2026.4.29 release without evidence of either the ClawHavoc skill payloads or the DeepSeek-Claw skill on disk.

8.4 Why this observation matters

The observation is novel observational data, not actionable threat intelligence in the strict sense. Its value is in three areas:

1. Threat-intelligence-community baseline. Prior to this investigation, no public reporting we are aware of documents the presence of an AI agent platform on an offensive operator’s working filesystem. This is a baseline data point against which future observations can be compared.

2. Future cross-campaign correlation. Observation of /openclaw/2026.4.29/ (or any OpenClaw variant) co-resident with offensive infrastructure at a new IP is one correlation signal for future attribution work — especially if observed alongside the 6e3644a97f844763a34565b865d35310 machine-ID, which would be a definitive same-machine match.

3. Capability ceiling tracking. If future evidence demonstrates the operator is using OpenClaw to accelerate offensive tool development, that would justify a sophistication-tier upgrade. The current evidence does not support that conclusion.

8.5 What would change this assessment

9. MITRE ATT&CK Mapping

Confidence note: all rows below are HIGH confidence unless explicitly marked (MODERATE) or (LOW). The Confidence Summary in Section 12 organizes findings by confidence level for the higher-level view. 32 techniques are mapped, organized by tactic in ATT&CK kill-chain order.

10. Risk & Detection Content

10.1 IOC summary

The full validated, machine-readable IOC feed is maintained separately. The main report links to it rather than embedding IOCs inline (per project standard — see Section 13 for the link). High-level counts:

Total HIGH-confidence operator IOCs: approximately 70 unique indicators across hashes, IPs, domains, and identifiers.

Defanging note: the IOC file is machine-readable JSON and is NOT defanged. Defanging is reserved for human-readable prose in this report.

10.2 Operator vs. shared-infrastructure distinction (CRITICAL for blocklists)

10.3 Detection content

Detection rules and hunting queries are maintained in a separate detection deliverable to keep this report focused on analysis. The full detection content is available at:

threat-intel-vault/hunting-detections/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-detections.md

Coverage summary:

10.4 Detection gap — why YARA byte-pattern detection is impossible

Critical evidence-gap note: The operator’s port-7777 development server died ~5 days post-discovery. The opendir-hunter platform hashed files in memory only — no source code was ever persisted to disk. YARA byte-pattern (string-based) detection against the operator toolkit is therefore fundamentally impossible, not a coverage gap that additional analysis effort could close. The single YARA rule deployed is hash-based, covering the 8 highest-value toolkit files by exact SHA256. Defender detection leverage is concentrated in Sigma (log-based) and Suricata (network-based) content.

The full IOC feed is available at:

threat-intel-vault/ioc-feeds/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-iocs.json

11. Response Orientation

This is not an incident-response playbook. Readers with IR needs should engage their internal IR team or a dedicated playbook — that is out of scope for this publication.

Detection priorities (highest-value behaviors to hunt for first):

• CRLF injection in Authorization: Basic headers to TCP/2083, 2087, 443 (CVE-2026-41940 exploit attempts)
• Werkzeug/3.1.8 + 302 → /login-2fa HTTP responses (operator C2 banner)
• DNS queries to operator-controlled domains and the Parklogic pkAId=2143526812 TDS parameter

Persistence targets (what to look for and remove on compromised cPanel/WHM hosts):

• New entries in /var/cpanel/users/ outside admin sessions
• New ~/.ssh/authorized_keys entries
• New email-forwarding rules on cPanel-hosted mailboxes
• Webshells in customer doc-root directories
• New WHM/cPanel accounts created outside admin sessions

Containment categories:

• Patch cPanel/WHM to fixed version (CVE-2026-41940 primary mitigation)
• Block operator IP cluster at network egress and ingress
• Block the 11 Parklogic TDS landing parent domains and 5 confirmed brand-spoof source-referers at DNS
• Deploy WAF inspection of Authorization: Basic header for raw CRLF bytes at cPanel/WHM perimeter
• Isolate affected hosts pending forensic scope assessment

12. Confidence Levels Summary and Retractions

12.1 Findings organized by confidence level

DEFINITE:

• Operator port-7777 development server exposed working filesystem on 2026-05-12 (direct open directory crawler observation)
• Live Flask C2 dashboard on 216.126.227.49:8888 with banner Werkzeug/3.1.8 Python/3.13.12 + 302 → /login-2fa (direct passive HTTP HEAD captured 2026-05-17 13:53 UTC)
• 37 of 45 toolkit file SHA256s recovered; 8 permanently unrecoverable

HIGH:

• Single-operator-cluster identity (UTA-2026-011) — 87% confidence
• Three registrar-level same-operator org-ID locks (WEBCC, NameCheap, Dynadot)
• Synchronized 1–3-hour MX rotation across adorarama.com + gocomper.com on 2025-08-01 and 2026-01-09
• Operator MX backend mx.plingest.com on 38.143.66.193 shared across three otherwise-separate registrar clusters
• Operator Linux /etc/machine-id 6e3644a97f844763a34565b865d35310
• Operator Parklogic monetization customer ID pkAId=2143526812 stable across 11 TDS landing domains
• Financial motive (90%)
• 9 operator IPs on AS14956 RouterHosting LLC (4 HIGH-confidence, 5 MODERATE-confidence historical)
• pipeline-41940.sh filename encodes CVE-2026-41940
• 0/76 VT detections on 7 distinctive toolkit hashes checked

MODERATE:

• Function inferences for all 37 toolkit files (filename + size only; no source observation)
• Inferred Python/Bash dependencies (requests, flask, werkzeug, aiohttp, jinja2, etc.)
• Victim-side persistence patterns (inferred from toolkit composition and CVE-2026-41940 advisories)
• AS14956 RouterHosting bulletproof-hosting classification (SUSPECTED, not CONFIRMED)
• OpenClaw filesystem install footprint (presence MODERATE-HIGH; offensive use LOW-MODERATE / UNCONFIRMED)
• unified_cracker.py brute-force / password-spraying / dictionary attack semantics

LOW:

• “Beast” operator self-brand interpretation (open hypothesis; unverified)
• Operator-attributable status of April 2026 commodity-malware activity on 216.126.224.181 (likely different RouterHosting tenant)
• Operator-attributable status of approximately 55 unverified TDS source-referer brand-spoof domains
• Whether the operator participated in pre-disclosure February 2026 CVE-2026-41940 exploitation

INSUFFICIENT:

• Named-actor attribution (30%)
• Primary malware family name
• Operator nationality, language, time zone, geographic location
• Operator’s exact relationship to the broader CVE-2026-41940 exploitation cluster

12.2 Twelve documented retractions from this investigation

This investigation explicitly retracts the following claims that appeared in earlier drafts. They are documented here to prevent recreation in future reports:

1. NOT “first-observed ITW weaponization of CVE-2026-41940” — broader exploitation predates by ~2 months per KnownHost telemetry (~2026-02-23)
2. NOT “two coherent operator generations Gen-1/Gen-2 XAMPP→Linux” — the architectural shift is observed but the Gen-1 attribution to this specific operator is MODERATE, not HIGH
3. NOT “JL Engineering hijacked-victim mail server” — jlengineering.se is an afraid.org FreeDNS multi-tenant donor, not a compromise victim
4. NOT “operator runs commodity-malware C2 from MX backend 38.143.66.193” — the supposed Rhadamanthys / Phorpiex / GandCrab evidence was a researcher-uploaded VirusTotal sample with no confirmed contacted_ips to .193
5. NOT “all ~60 TDS source-referer brand-spoofs are operator-controlled” — only 5 are verified operator-controlled
6. NOT “~350+ unique victim phishing URLs in TDS landing layer” — this was an extrapolation, not a count
7. NOT “operator is the zero-day actor for CVE-2026-41940” — current evidence supports rapid-adoption tradecraft, not zero-day actor profile
8. NOT “operator is using OpenClaw to build offensive tooling” — filesystem presence is MODERATE-HIGH; offensive use is LOW-MODERATE / UNCONFIRMED
9. NOT “operator nationality is [X]” — no operator-side language or time-zone signal recovered
10. NOT “operator is part of [named criminal crew]” — zero overlap with all 10 existing UTAs and zero Tier-1/2/3 public attribution to any named actor
11. NOT “Parklogic is operator-controlled” — Parklogic is a legitimate domain-monetization platform; the operator is its customer (pkAId=2143526812)
12. NOT “all 9 operator IPs are HIGH confidence” — 4 are HIGH; 5 are MODERATE historical

12.3 Evidence and Data Gaps

This subsection consolidates the four named-gap categories that constrain the depth of this report’s claims. Detection-content coverage gaps are maintained separately in the detection file (see Section 10.3).

• No source-code recovery (Section 6). The operator’s port-7777 development server was hashed in memory by the open directory crawler; source code was never persisted to disk. All function-level claims for the 37 recovered toolkit files are filename + size inference (MODERATE), not source-observation (HIGH). YARA byte-pattern detection against the toolkit is fundamentally impossible — see Section 10.4.
• 8 unrecovered toolkit hashes (Section 3.2). 37 of 45 operator-built toolkit file SHA256s were recovered before the development server was rate-limited and died ~5 days post-discovery. The 8 unrecovered files are permanently lost — no second snapshot is possible.
• No chat-transcript, command-history, or OpenClaw output recovery (Sections 7.7 and 8.5). No operator chat logs, shell history, or OpenClaw conversation/output artifacts were captured. This is the primary gap blocking (a) elevation of OpenClaw offensive-use to HIGH confidence and (b) operator nationality/language attribution.
• No operator nationality, language, time-zone, or geographic signal (Sections 7.7 and 12.1). Recovered artifacts contain no language-localized strings, no timezone-leaking timestamps, and no geographically-disambiguating commit metadata. Named-actor attribution remains INSUFFICIENT (30%).

See Section 6 (source-observation gap), Section 7.7 (attribution gaps), Section 8.5 (OpenClaw offensive-use gap), and Section 12.1 (INSUFFICIENT findings list) for the full per-section discussion.

13. References and Appendices

13.1 External research references

CVE-2026-41940 disclosure and analysis:

• cPanel Security Advisory — CVE-2026-41940 (2026-04-28)
• watchTowr Labs — CVE-2026-41940 root-cause analysis (researcher: Sina Kheirkhah)
• Rapid7 — ETR (Emerging Threat Report) CVE-2026-41940
• CISA.gov — KEV catalog entry, added 2026-05-01
• CyCognito — CVE-2026-41940 CRLF injection technical blog
• watchtowrlabs/cve-2026-41940 (public PoC)
• ynsmroztas/cPanelSniper (community-maintained scanning wrapper)

Infrastructure and ecosystem research:

• VirusTotal — IP, domain, and hash reports
• Shadowserver Foundation — CVE-2026-41940 scanning telemetry
• KnownHost — pre-disclosure exploitation telemetry
• DomainTools Iris Investigate — WHOIS history and passive DNS exports
• Recorded Future — AS14956 RouterHosting context
• AbuseIPDB — AS14956 individual IP reports
• Scamalytics — RouterHosting LLC ISP risk score

TDS, monetization, and DNS abuse:

• Infoblox — “Parked Domains Become Weapons”
• Cofense — “The Unintentional Enabler: Cloudflare Abuse”
• Krebs on Security — “Most Parked Domains Now Serving Malicious Content” (Dec 2025)
• Spamhaus — “Too big to care? Cloudflare anti-abuse posture”
• Palo Alto Networks Unit 42 — Wildcard DNS Abuse research
• Silent Push — Dynamic DNS Providers dark-side research
• Let’s Encrypt Community Forum — afraid.org ongoing abuse discussion

OpenClaw security context (2026):

• Zscaler ThreatLabZ / CybersecurityNews — Malicious OpenClaw DeepSeek Skill (delivering Remcos RAT and GhostLoader)
• Barracuda Networks — OpenClaw agentic AI security risks
• Reco.ai — OpenClaw security crisis analysis
• The Hacker News — ClawJacked Flaw (February 2026)

Press coverage of the CVE:

• Help Net Security — “cPanel zero-day exploited for months before patch”
• CyberScoop — “cPanel authentication bypass exploited in the wild, CISA warns”
• BleepingComputer — CVE-2026-41940 coverage

13.2 Appendix A — Operator identity artifacts (consolidated)

13.3 Appendix B — Operator filesystem layout (observed)

/cpanel-toolkit-export/
├── cpanel-toolkit-export/
│   ├── [37 hashed .py / .sh files — see Section 3.3 and IOC file]
│   ├── [8 hash-FAILED files: deep_probe_v2.py, gen-cpanel-access.py,
│   │     harvest_hostnames.py, mass_exploit_v6.py, post_scanner.py,
│   │     self-scan-whm.sh, unified_cracker.py, whm_enumerator.py]
│   └── [XAMPP default index.html — non-operator artifact]
/openclaw/2026.4.29/
│   └── [Node.js compile-cache: v22.22.1-x64-9de703df-0 with ms-epoch 1777651809344
│         decoding to first execution 2026-05-01 16:10:09 UTC]
/asteroid/        — operator-internal project (contents unknown)
/krypto/          — operator-internal project (cryptography/wallet connotation)
/cdc_hunt/        — operator-internal project (possible Chrome DevTools Cookies hunt)
/tmux-0/          — tmux user-0 socket directory (operator session control)

13.4 Appendix C — Glossary

13.5 Appendix D — Acknowledgments

This investigation was triggered by the open directory crawler platform, which surfaced 216.126.227.49 as a tier-suspicious open directory on 2026-05-12. Infrastructure attribution analysis relied on DomainTools Iris Investigate, VirusTotal MCP, and public CVE-2026-41940 research from watchTowr Labs, Rapid7, CISA, KnownHost, and Shadowserver Foundation.

The full UTA-2026-011 profile is maintained at threat-intel-vault/threat-actors/UTA-2026-011.md. The detection deliverable is maintained at threat-intel-vault/hunting-detections/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-detections.md. The IOC feed is maintained at threat-intel-vault/ioc-feeds/opendirectory-216-126-227-49-cve-2026-41940-cpanel-harvester-20260517-iocs.json.

© 2026 Joseph. All rights reserved. See LICENSE for terms.