Detection Rules: WebLogic Deserialization and Telecom Credential Harvesting, 13.140.145.210

Campaign: WebLogicDeserialization-TelecomHarvester-13.140.145.210 Date: 2026-08-17 Author: The Hunters Ledger License: CC BY 4.0 Reference: https://the-hunters-ledger.com/reports/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817/

Detection Coverage Summary

This campaign is a single operator’s bespoke intrusion toolkit, not a commodity malware family, so coverage below is organized by capability cluster rather than by family. The operator practises consistent victim-side anti-forensics, including per-session webshell deletion, SAM/SYSTEM hive wipes, staging-file removal, and timestomping (a rewritten watchdog script stamped back to 2010-10-07), so host-artifact hunting on the victim fails by design in several of these clusters. Coverage is weighted toward signals the operator cannot reach or clean: network egress the victim device itself generates, the operator’s own listener-side receipts, and device-generated crash/telemetry the operator does not control.

Detection vs Hunting: Detection rules are high-fidelity and evasion-resilient, safe to alert on. Hunting rules are broader, built for scoping and threat-hunting. Expect to review the hits.

The single highest-priority rule in this file is the Suricata signature for an outbound HTTP PUT carrying User-Agent: cisco-IOS to a non-management destination (Cisco IOS-XE WSMA Exfiltration cluster, Suricata Detection). It is the highest-fidelity signal in the entire case: a network device generates this traffic itself as it uploads its own firmware, core dumps and configs, so the operator cannot suppress or clean it after the fact the way they can a victim-side log or file.

Two rules in the Cisco IOS-XE cluster are deliberately broader than this operator. The generic-CVE-2023-20198 URI (/webui/logoutconfirm.html?logon_hash=1) and the bare-hex forged-token shape (18 hex characters in either case, no auth scheme) both cover the public exploit class used by at least five other, unrelated intruders observed hitting the same victim router. They are labeled GENERIC-CVE-2023-20198 in their rule names and msg fields throughout this file to keep them clearly distinct from the two operator-specific signatures (the double-encoded WSMA path %2577eb%2575i_%2577sma_Http, and the WSMA fileCopy exfiltration primitive), which are this operator’s fingerprint and will not fire on the other five.

Atomic indicators were deliberately routed to the IOC feed instead of being authored as rules. Per the routing test in detection-rule-tiering (if removing the single hard-coded literal makes the rule detect nothing, it belongs in the feed), the following were excluded from this file and are already present in threat-intel-vault/ioc-feeds/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-iocs.json: the operator VPS IP and port combination (13.140.145.210:4445) hard-coded into the reverse-shell one-liner; the two Go compiler build IDs that distinguish the two builds of the CVE-2023-21839 exploit; the domain radius-sync.com (a single-domain DNS-query match is a pure-IOC selector by definition); and the four captured chisel server key fingerprints (useful as pivot material, not as rule content). See Coverage Gaps for the full accounting.

Capability Cluster Organization

There is no malware family here, so the layout below nests capability cluster inside tier rather than family inside tier: for each rule-type section, ### Detection Rules comes first and ### Hunting Rules second, and inside each tier the rules are grouped under a bold cluster label. All seven capability clusters below produced at least one rule; within a few of them, specific artifacts still have no rule at all (the PRTG notification-trigger RCE step, the rootkit’s unrecoverable trojanized binaries) and are covered under Coverage Gaps instead.

The seven capability clusters:

• Cisco IOS-XE WSMA Exfiltration, the confirmed, victim-side compromise. Highest-priority cluster; every rule here targets a signal the operator cannot suppress because it is generated by the victim device or lives in the device’s own crash telemetry.
• WebLogic T3/JNDI Exploitation, the operator’s hand-written JNDI-injection suite and hand-rolled 4-mode BER/LDAP server, plus the two downloaded public exploits it drives.
• Tunnelling & Internal Pivot, the chisel reverse-SOCKS tunnel that gave the operator a confirmed internal foothold inside the victim telecom’s network.
• Internal Windows Post-Exploitation, the GeoServer RCE-to-webshell-to-credential-spray chain on the internal WAMP/cadastre host.
• Userland Rootkit & AAA-Host Anti-Forensics, the originals-backup staging set and the timestomped watchdog rewrite on the carrier AAA server.
• Linux Kernel LPE (Public Dirty Frag), the downloaded, unmodified kernel exploit and its two overwrite targets.
• Monitoring-Plane Credential Harvest (PRTG), the credential-extraction API calls against the carrier’s monitoring platform.

YARA Rules

Detection Rules

Cisco IOS-XE WSMA Exfiltration

WSMA_CVE_2023_20198_DoubleEncode_Exfil

Tier: Detection Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application), T1048.003 (Exfiltration Over Unencrypted Non-C2 Protocol) Confidence: HIGH Rationale: The rule requires one operator-specific spelling of the encoded path together with the fileCopy operation name and the WSMA namespace or the sequential-hex token. That is a build and tool fingerprint: the operator can change the encoding pattern, as the Blind Spots line states, so it scores Robustness 2 and not 3. False Positives: None known. The double-encoded WSMA path form (capital H, only w/u encoded) does not occur in legitimate WSMA usage or in the public CVE-2023-20198 proof-of-concept tooling, which uses a different, single-encoded lowercase form Blind Spots: Needs the fileCopy operation name in the same file as the encoded path, so an access log or capture that holds only the path (the request body is not logged) does not match. Not run against the original script in this pass (NOT CHECKED). Misses any future campaign where the operator changes the encoding pattern; this is a file/log-content rule, not a live network signature. See the companion Suricata rules for wire-level coverage Validation: Scan the operator’s own exfiltration script (exfil_nvram.sh); a carved nginx access log or a file holding only the double-encoded path must NOT fire; a stock, unmodified Cisco WSMA client script using the documented single-encoded path form must NOT fire Deployment: File scanning of recovered operator scripts and of any captured request-body or replay file that holds the script text. A captured web server access log is not a valid input: it carries the encoded path but not the fileCopy operation name, so it does not satisfy the rule.

rule WSMA_CVE_2023_20198_DoubleEncode_Exfil {
   meta:
      description = "Detects a script (under 10 MB) carrying the double-encoded Cisco IOS-XE WSMA path bypass together with the WSMA fileCopy operation name and either the WSMA filesystem namespace or the sequential-hex authorization token, the operator-specific mechanism that reads a router's own NVRAM and PUTs it out over HTTP. A captured access log holding only the encoded path does not satisfy the rule"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      hash1 = "72c6383477bbcb93811fd837a9e4721cfddea0cd238eebe3012acc0e6a31c40e"
      family = "Unknown - bespoke single-operator WebLogic/telecom intrusion toolkit"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "94efd4fe-4813-55a4-9b9a-3e4cc64b0d24"
   strings:
      $path = "%2577eb%2575i_%2577sma_Http" ascii
      $wsma = "urn:cisco:wsma-filesystem" ascii
      $copy = "fileCopy" ascii
      $token = "0123456789abcdefab" ascii
   condition:
      filesize < 10MB and
      $path and $copy and 1 of ($wsma, $token)
}

File name: vuln_cve_2023_20198_wsma_doubleencode_exfil.yar

WebLogic T3/JNDI Exploitation

WebLogic_CVE_2024_21182_OpaqueReference_JNDI

Tier: Detection Robustness: 3 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: HIGH False Positives: Any file that names all three classes matches, not only operator tooling: WebLogic’s own internals, advisories and write-ups about CVE-2024-21182 (see Blind Spots). The rule tests the three class names alone, so a hit shows that a file mentions the OpaqueReference primitive and not that it exploits it; read the reflection and lookup code in the file to tell the two apart Blind Spots: The three class names are tested as strings only, so WebLogic internals, advisories and write-ups that name all three also match. Misses variants that reach the same primitive through different class names, or that exploit the underlying JNDI weakness purely over the T3/IIOP wire protocol without ever appearing as Java source or bytecode Validation: Scan the operator’s Java source (any of the seven byte-identical copies of the reflection block); a legitimate WebLogic JNDI administration utility must NOT fire Deployment: Source-code and bytecode scanning of recovered operator tooling, static-analysis pipelines ingesting suspected exploit code

rule WebLogic_CVE_2024_21182_OpaqueReference_JNDI {
   meta:
      description = "Detects Java source or compiled tooling that holds the three class names AggregatableOpaqueReference, MessageDestinationReference and ForeignOpaqueReference together, the classes the report names in the CVE-2024-21182 WebLogic JNDI-injection primitive (the operator's code reflects the first class's referent field to a spoofed MessageDestinationReference and resolves it through the ForeignOpaqueReference lookup path); the rule tests only the three class-name strings, with no reflection call, field name or spoofing"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      family = "Unknown - bespoke single-operator WebLogic/telecom intrusion toolkit"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "33789184-a9c6-5a7a-80d9-0189c0707dcc"
   strings:
      $ref1 = "AggregatableOpaqueReference" ascii
      $ref2 = "MessageDestinationReference" ascii
      $ref3 = "ForeignOpaqueReference" ascii
   condition:
      filesize < 5MB and
      all of ($ref1, $ref2, $ref3)
}

File name: vuln_cve_2024_21182_weblogic_opaquereference_jndi.yar

WebLogic_JNDI_HelloFromLdap_CallbackMarker

Tier: Detection Robustness: 2 ATT&CK Coverage: T1132.001 (Standard Encoding, serialized-object callback validation) Confidence: HIGH False Positives: None known. This exact Java-serialized String is a plumbing test the operator wrote for their own LDAP server, not a string that appears in legitimate Java serialization traffic Blind Spots: Needs the raw serialized bytes (stream header, string type tag, length 15, then the text). The bare text hello_from_ldap in source code, a log or a document does not match, and a base64 or otherwise encoded copy does not either. Only fires if the operator reuses this exact test string in a future campaign; a renamed validation string evades entirely Validation: Scan string_payload.bin or any capture containing the raw serialized bytes; generic Java-serialized traffic containing unrelated Strings must NOT fire Deployment: File scanning of recovered operator artifacts and of payload files carved from a saved traffic capture. The condition tests filesize, which is undefined in a process-memory scan, so the rule does not match there; a memory-scan form would need the filesize test removed and is not written or tested here.

rule WebLogic_JNDI_HelloFromLdap_CallbackMarker {
   meta:
      description = "Detects the Java-serialized String hello_from_ldap used by this operator's hand-rolled 4-mode BER/LDAP exploitation server to validate a JNDI callback path before sending a live gadget chain"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      hash1 = "9251373f585c91b6bf7c407aa1a989e7cc596c4afc79a8573a18f858df9f014d"
      family = "Unknown - bespoke single-operator WebLogic/telecom intrusion toolkit"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "15fe1607-d88a-51fa-82d1-f8153f3e94f3"
   strings:
      $ser_hex = { AC ED 00 05 74 00 0F 68 65 6C 6C 6F 5F 66 72 6F 6D 5F 6C 64 61 70 }
   condition:
      filesize < 1MB and
      $ser_hex
}

File name: crime_weblogic_telecom_ldap_callback_marker.yar

Internal Windows Post-Exploitation

Webshell_PHP_XCMD_Header_Dispatcher

Tier: Detection Robustness: 2 ATT&CK Coverage: T1505.003 (Web Shell) Confidence: MODERATE Rationale: The only evidence of h.php is the operator’s script, which writes a persistent h.php dispatching on an X-CMD request header; the report records no captured outcome and no copy of the file. The rule matches <?php, an X-CMD or HTTP_X_CMD string, and one execution-function string anywhere in a PHP file of under 200 KB. It tests no order, distance or data flow, and exec( also matches inside shell_exec(. False Positives: A poorly-designed internal debug or operations tool that intentionally maps a custom HTTP header to shell-command execution without other access controls. Rare, but not unheard of in legacy internal tooling. Because no data flow is tested, a PHP file that merely names an X-CMD header (to log, display or reject it) and separately runs any hard-coded command through exec(, system(, passthru( or shell_exec also matches. The X-CMD string is the only discriminator; it stays Detection because a custom header of that name in a PHP file is itself uncommon, and a hit still needs a read of the file to confirm the header reaches the call. Blind Spots: Misses webshells that read the command from a POST body, cookie, or a differently-named header instead of X-CMD; misses obfuscated or encoded variants where the exec function call is base64-wrapped or built via string concatenation Validation: Scan a PHP file combining the literal header check with a direct shell_exec/system/passthru/exec call; a PHP file that uses shell_exec for a hard-coded command and never names X-CMD or HTTP_X_CMD must NOT fire. A PHP file that names the header only to display it and separately runs a hard-coded command WILL fire, because the rule tests no data flow Deployment: Web-root file-integrity scanning, upload/WAF content inspection, forensic triage of a compromised web server

rule Webshell_PHP_XCMD_Header_Dispatcher {
   meta:
      description = "Detects a PHP file (under 200 KB) that contains an X-CMD header reference (X-CMD or HTTP_X_CMD) and a shell-execution function name. The report says the operator's script writes a persistent h.php dispatching on an X-CMD request header into a WAMP web root, with no captured outcome. The rule does not test that the header value reaches the execution call"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      family = "Unknown - bespoke single-operator WebLogic/telecom intrusion toolkit"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "49e59582-4d7c-5675-ba0f-0de5de77183b"
   strings:
      $php = "<?php" ascii
      $hdr1 = "X-CMD" ascii nocase
      $hdr2 = "HTTP_X_CMD" ascii
      $exec1 = "shell_exec" ascii
      $exec2 = "system(" ascii
      $exec3 = "passthru(" ascii
      $exec4 = "exec(" ascii
   condition:
      filesize < 200KB and
      $php and
      1 of ($hdr1, $hdr2) and
      1 of ($exec1, $exec2, $exec3, $exec4)
}

File name: webshell_php_xcmd_header_dispatcher.yar

GeoServer_CVE_2024_36401_ValueReference_Exec

Tier: Detection Robustness: 3 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: HIGH False Positives: None known from legitimate GeoServer traffic: OGC-filter requests do not construct a valueReference parameter that literally invokes Runtime.getRuntime() via exec(). The rule reads file or captured-request content, so a proof-of-concept write-up, advisory or scanner template that quotes the payload also matches Blind Spots: Misses variants of the CVE-2024-36401 payload that use a different Java reflection or execution primitive (for example ProcessBuilder instead of Runtime.exec), or that obfuscate the payload string Validation: Scan a captured exploitation script or logged request body containing the literal exec(java.lang.Runtime.getRuntime(), payload; a benign OGC filter request using valueReference for an unrelated property lookup must NOT fire Deployment: File and log scanning, WAF/API-gateway content inspection

rule GeoServer_CVE_2024_36401_ValueReference_Exec {
   meta:
      description = "Detects a script or captured HTTP request implementing the CVE-2024-36401 GeoServer OGC-filter remote-code-execution payload, which passes exec(java.lang.Runtime.getRuntime(),'command') as a valueReference parameter (the report places it against GeoServer's ows endpoint; the rule tests only the two strings, no endpoint path and no authentication state)"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      hash1 = "dcd739dfe08285c08200be926905155576bedc4e5633b5f02561ec7f80d512f1"
      family = "Unknown - bespoke single-operator WebLogic/telecom intrusion toolkit"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "e997f10d-ad79-5abe-bf0b-7bd17a938f25"
   strings:
      $payload = "exec(java.lang.Runtime.getRuntime()," ascii
      $valueref = "valueReference" ascii
   condition:
      filesize < 1MB and
      all of them
}

File name: vuln_cve_2024_36401_geoserver_valuereference_exec.yar

Hunting Rules

Userland Rootkit & AAA-Host Anti-Forensics

Rootkit_Userland_OriginalsBackup_TarSet

Tier: Hunting (re-tiered from Detection 2026-09-13, see note below) Robustness: 1 ATT&CK Coverage: T1554 (Compromise Host Software Binary), T1014 (Rootkit) Confidence: MODERATE False Positives: Confirmed, not merely possible. A plain, uncompressed tar of these seven common Linux administration binaries, carrying nothing but placeholder content and no malware at all, matches this rule. This was reproduced independently twice, once by hand, once by an automated benign-corpus harness (.claude/scripts/yara_fp_check.py) built specifically to test it. The rule’s original False Positives field (“None known… would not present all seven paths as a top-level manifest in this exact combination”) was wrong: an ordinary sysadmin backup that happens to bundle exactly these seven tools presents exactly that manifest, and there is nothing else in the condition to tell the two apart. A hit needs analyst review before any conclusion is drawn, which is why this is Hunting rather than Detection Blind Spots: The rule is a plaintext-token lead, not a tar parser: it matches the ustar marker and the seven path strings anywhere in a file under 5 MB, so a plain text file holding them also matches, and it sees an archive only in uncompressed form. This specific artifact (orig_bins.tgz) is gzip-compressed, and gzip compression destroys the plaintext string patterns this rule keys on, so deploy alongside a scanning pipeline that decompresses archives before scanning, or against extracted/forensic copies. The trojanized replacement binaries themselves were never recovered in either capture and cannot be detected by content; see Coverage Gaps. A tightening was attempted (excluding tars that also carry common non-target binaries such as bash, sh, ls) and it did suppress a realistic broader-backup fixture while still firing on the narrow seven-member shape, but it could only be tested against a synthetic reconstruction of the real evidence, not the actual captured orig_bins.tgz (hash daee2d57...), so it is not shipped as a claimed fix. Re-tiering to Hunting was chosen instead because it needs no unverified claim and matches detection-rule-tiering Gate 2’s own routing (“high-value but meaningfully noisy” to Hunting) Validation: Decompress orig_bins.tgz to a raw .tar and scan it, it fires. Scan a plain administrative backup tar containing exactly these seven paths and nothing else, it also fires, which is the point: this is now documented as an analyst-triage lead, not an alerting-grade signal Deployment: Forensic archive scanning, EDR file-content inspection pipelines that decompress common archive formats before scanning, with analyst triage on every hit

rule Rootkit_Userland_OriginalsBackup_TarSet {
   meta:
      description = "Detects a file under 5 MB holding the ustar marker and all seven path strings of the canonical userland-rootkit target set (ps, top, pstree, netstat, lsof, find, rpm); an archive with more members also matches, and the strings are not checked to be tar member names, consistent with an operator staging pristine originals before trojanizing a Linux host's process, network, filesystem and package-integrity inspection tools. Hunting-tier: this exact manifest also matches an ordinary sysadmin backup with no malware present, confirmed by direct testing, so every hit needs analyst review"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      hash1 = "daee2d57566c88374b5de65ecc04e1321da4d5dc35b84a0eb98893afad9e2664"
      family = "Unknown - bespoke single-operator WebLogic/telecom intrusion toolkit"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "ba89babd-e197-5073-9656-9654215ab3a1"
   strings:
      $ustar = "ustar" ascii
      $m1 = "bin/ps" ascii
      $m2 = "usr/bin/top" ascii
      $m3 = "usr/bin/pstree" ascii
      $m4 = "bin/netstat" ascii
      $m5 = "usr/sbin/lsof" ascii
      $m6 = "usr/bin/find" ascii
      $m7 = "bin/rpm" ascii
   condition:
      filesize < 5MB and
      $ustar and all of ($m1, $m2, $m3, $m4, $m5, $m6, $m7)
}

File name: gen_userland_rootkit_originals_backup_archive.yar

Linux Kernel LPE (Public Dirty Frag)

PublicTool_DirtyFrag_LinuxKernel_LPE

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1068 (Exploitation for Privilege Escalation) Confidence: MODERATE False Positives: None known for the string combination itself, but this rule intentionally detects the public “Dirty Frag” tool broadly. Any red team, researcher, or unrelated intruder running the same unmodified public exploit will also match. That is why this is Hunting rather than Detection: a hit needs analyst confirmation that it belongs to this operator’s campaign rather than independent reuse of the same public tool Blind Spots: The rule matches file content, so renaming the file or recompiling with the required strings intact does not evade it; it misses a variant from which the cipher name or all but one of the five proof-of-concept strings have been removed or encoded; misses the exploit entirely if the analyzed artifact is a stripped compiled binary with no surviving strings Validation: Scan df_exploit or exp.c; an unrelated ELF binary or C source file must NOT fire Deployment: File scanning, hunting sweep across Linux hosts for a known public LPE tool

rule PublicTool_DirtyFrag_LinuxKernel_LPE {
   meta:
      description = "Detects the public Dirty Frag Linux kernel local-privilege-escalation exploit (CVE-2026-43284 and CVE-2026-43500), identified by its pcbc(fcrypt) kernel-crypto cipher name (the report calls it the most distinctive artifact in the binary) together with at least two of its five proof-of-concept strings (four environment-variable names and the su page-cache patch message). The AF_ALG socket family is not tested. This detects the published open-source tool itself, not any operator-specific modification"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      hash1 = "a133809a768c7c6b958d72ff6857677b14ed6bf284b99dc81a121442dfe04f90"
      family = "Public tool - Dirty Frag Linux kernel LPE (not this operator's own code)"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "de68b3f2-e38d-58ef-9878-2bd771b32462"
   strings:
      $cipher = "pcbc(fcrypt)" ascii
      $verbose = "DIRTYFRAG_VERBOSE" ascii
      $seed = "LPE_SEED" ascii
      $iters = "LPE_MAX_ITERS" ascii
      $target = "POC_TARGET_FILE" ascii
      $suoutput = "/usr/bin/su page-cache patched (entry 0x%x = shellcode)" ascii
   condition:
      filesize < 5MB and
      $cipher and 2 of ($verbose, $seed, $iters, $target, $suoutput)
}

File name: susp_dirtyfrag_linux_kernel_lpe_pubtool.yar

WebLogic T3/JNDI Exploitation

PublicTool_CVE_2023_21839_WebLogic_GoExploit

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application), T1588.005 (Obtain Capabilities: Exploits) Confidence: MODERATE False Positives: None known for the string combination, but this detects the public tool broadly, as with the Dirty Frag rule, including any unrelated party running the same unmodified exploit. Hunting tier for the same reason Blind Spots: Misses the exploit if built from a different working directory (the build path is the primary anchor); misses any hand-modified fork that renames the source files Validation: Scan cve21839 or wl_exploit (both confirmed byte-identical except for 106 bytes of build metadata); an unrelated Go ELF binary must NOT fire Deployment: File scanning, hunting sweep for the known public CVE-2023-21839 tool

rule PublicTool_CVE_2023_21839_WebLogic_GoExploit {
   meta:
      description = "Detects the public Go implementation of the CVE-2023-21839 WebLogic T3/IIOP JNDI exploit by its build path and GIOP-request source file names. This detects the published open-source tool itself, not any operator-specific modification - a pristine build and a dirty-tree rebuild of the same tool differ only in 106 bytes of compiler metadata"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/"
      date = "2026-08-17"
      hash1 = "953b668e95e033b34de0373af354cfd1d5557edf8cdfa49887cabf2b44d67b65"
      family = "Public tool - CVE-2023-21839 Go exploit (not this operator's own code)"
      campaign = "WebLogicDeserialization-TelecomHarvester-13.140.145.210"
      id = "2a217b40-6e23-5f5a-9074-4590591d9e3f"
   strings:
      $path = "/tmp/CVE-2023-21839/" ascii
      $f1 = "giop.go" ascii
      $f2 = "locate_request.go" ascii
      $f3 = "resolve_request.go" ascii
      $f4 = "rebind_request.go" ascii
   condition:
      uint32(0) == 0x464c457f and
      filesize < 20MB and
      $path and 1 of ($f1, $f2, $f3, $f4)
}

File name: susp_cve_2023_21839_weblogic_go_exploit_pubtool.yar

Sigma Rules

Detection Rules

WebLogic T3/JNDI Exploitation

Chisel Client Establishing a Reverse SOCKS Tunnel

Tier: Detection Robustness: 2 ATT&CK Coverage: T1572 (Protocol Tunneling) Confidence: HIGH False Positives: Authorized use of chisel for legitimate remote-support or internal tunneling by an IT team Blind Spots: Misses chisel invoked via a renamed binary with the process name changed to something innocuous; misses forward-SOCKS or plain port-forward chisel modes that don’t use the reverse-SOCKS shorthand Validation: Run chisel_win.exe client <server> R:socks on a test host; a chisel invocation without any SOCKS reverse flag (a plain port-forward) must NOT fire Deployment: Windows EDR / Sysmon on internal, network-adjacent hosts

title: Chisel Client Establishing a Reverse SOCKS Tunnel
id: 952efdf0-9d41-4d5b-a720-de3e66546fa1
status: experimental
description: >-
    Detects execution of the chisel tunneling client with the reverse-SOCKS
    shorthand flag, which turns an outbound HTTP/WebSocket connection to an
    operator-controlled chisel server into a local SOCKS proxy usable for
    internal-network pivoting.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
    - https://github.com/jpillora/chisel
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.command-and-control
    - attack.t1572
    - stp.3
logsource:
    category: process_creation
    product: windows
detection:
    selection_image:
        Image|endswith:
            - '\chisel.exe'
            - '\chisel_win.exe'
    selection_flag:
        CommandLine|contains: 'r:socks'
    condition: all of selection_*
falsepositives:
    - Authorized use of chisel for legitimate remote-support or internal tunneling by an IT team
level: high

File name: proc_creation_win_chisel_reverse_socks_tunnel.yml

Internal Windows Post-Exploitation

Registry Hive Save of SAM or SYSTEM via reg.exe

Tier: Detection Robustness: 3 ATT&CK Coverage: T1003.002 (Security Account Manager) Confidence: HIGH Rationale: The report records a script written to export the SAM and SYSTEM hives into a web root (no captured outcome, so whether it ran is not known). The rule is keyed on the reg save of those two hives, which is the same step whatever the destination, and does not test the destination path, so a title that said “Non-Standard Location” was withdrawn. False Positives: Scheduled or scripted backup jobs that export the SAM or SYSTEM hive to a controlled backup location Blind Spots: Matches only the HKLM\SAM and HKLM\SYSTEM spellings, so HKEY_LOCAL_MACHINE\SAM is missed. The save test is a space-delimited token ( save ), so reg.exe query HKLM\SAM /v autosave does not match, while a value literally named save followed by another argument would. Misses hive theft performed via a non-reg.exe method, meaning direct API calls, a custom dumping tool, or volume shadow copy access Validation: Run reg save HKLM\SAM C:\temp\sam.bak on a test host; a legitimate scheduled backup task exporting the SAM hive to a known backup share should be reviewed against the false-positive list, not silently excluded Deployment: Windows EDR / Sysmon, all hosts

title: Registry Hive Save of SAM or SYSTEM via reg.exe
id: 70038c48-829c-4a9c-bab4-540720e0a9b6
status: experimental
description: >-
    Detects reg.exe run with a space-delimited save argument and HKLM\SAM or HKLM\SYSTEM in the
    command line (the match also covers a subkey path under HKLM\SYSTEM), the
    credential-theft precursor to offline extraction of local password
    hashes. The destination is not tested, so a save to any path matches. The
    report says the operator's script is written to save both hives into a web
    server document root under dot-prefixed filenames so they could be
    retrieved over HTTP; no output of that script was captured.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.credential-access
    - attack.t1003.002
logsource:
    category: process_creation
    product: windows
detection:
    selection_image:
        Image|endswith: '\reg.exe'
    selection_cmd:
        CommandLine|contains: ' save '
    selection_hive:
        CommandLine|contains:
            - 'HKLM\SAM'
            - 'HKLM\SYSTEM'
    condition: all of selection_*
falsepositives:
    - Scheduled or scripted backup jobs that export the SAM or SYSTEM hive to a controlled backup location
level: high

File name: proc_creation_win_reg_save_sam_system_webroot.yml

Command Shell Spawned by a Web Server or Application Server Process

Tier: Detection Robustness: 3 ATT&CK Coverage: T1059.001 (PowerShell), T1059.003 (Windows Command Shell) Confidence: HIGH False Positives: Application performance monitoring or health-check agents integrated into the web server that intentionally spawn a shell; legitimate administrative scripting hooked into an IIS or Java application-server deployment pipeline Blind Spots: Misses shells spawned two or more hops downstream of the web-server process (webshell then scheduled task then shell); misses non-Windows web servers Validation: Exploit a test IIS or WebLogic/GeoServer instance to spawn cmd.exe or powershell.exe as a direct child; a legitimate w3wp.exe-hosted management API that shells out to run a signed, known maintenance script should be reviewed rather than silently excluded Deployment: Windows EDR / Sysmon on all IIS, Apache, and Java application-server hosts

title: Command Shell Spawned by a Web Server or Application Server Process
id: 06f9b3ec-3102-4abd-bc06-cbe8310a6495
status: experimental
description: >-
    Detects cmd.exe or powershell.exe spawned directly by a web server or
    Java application server process, consistent with a webshell or an
    unauthenticated remote-code-execution vulnerability such as
    CVE-2024-36401 in GeoServer being used to execute operating-system
    commands.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
    - https://nvd.nist.gov/vuln/detail/CVE-2024-36401
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.execution
    - attack.t1059.001
    - attack.t1059.003
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith:
            - '\httpd.exe'
            - '\java.exe'
            - '\javaw.exe'
            - '\w3wp.exe'
    selection_child:
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
    condition: all of selection_*
falsepositives:
    - Application performance monitoring or health-check agents integrated into the web server that intentionally spawn a shell
    - Legitimate administrative scripting hooked into an IIS or Java application-server deployment pipeline
level: high

File name: proc_creation_win_shell_spawned_from_webserver_process.yml

PowerShell Remoting Session Establishment Command

Tier: Detection Robustness: 2 ATT&CK Coverage: T1021.006 (Windows Remote Management) Confidence: HIGH False Positives: Legitimate remote administration via PowerShell remoting, common where Ansible, DSC, or SCOM manage the WinRM estate Blind Spots: Misses WinRM sessions established via a compiled tool rather than PowerShell’s own cmdlets; misses WMI-based lateral movement entirely Validation: Run New-PSSession -ComputerName <host> on a test host; a known configuration-management tool’s scheduled WinRM session establishment should be allow-listed by source host rather than excluded by rule Deployment: Windows EDR / Sysmon, all hosts, prioritized on internet-facing or recently-exploited application servers

title: PowerShell Remoting Session Establishment Command
id: c838460c-7478-41e4-a9de-ee7d44391023
status: experimental
description: >-
    Detects powershell.exe command lines that contain New-PSSession,
    Enter-PSSession or Test-WSMan (the first two open a WS-Management remoting
    session; Test-WSMan only probes a WinRM listener and opens none, yet it
    satisfies the selection),
    observed in this campaign as the primary lateral-movement method used
    from a compromised web application host against an internal target.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.lateral-movement
    - attack.t1021.006
    - stp.3
logsource:
    category: process_creation
    product: windows
detection:
    selection_image:
        Image|endswith: '\powershell.exe'
    selection_cmd:
        CommandLine|contains:
            - 'New-PSSession'
            - 'Enter-PSSession'
            - 'Test-WSMan'
    condition: all of selection_*
falsepositives:
    - Legitimate remote administration via PowerShell remoting, common where Ansible, DSC or SCOM manage the WinRM estate
level: high

File name: proc_creation_win_winrm_session_establishment_webshell.yml

Net Use Command Targeting an Administrative Share With Explicit Credentials

Tier: Detection Robustness: 2 ATT&CK Coverage: T1021.002 (SMB/Windows Admin Shares) Confidence: HIGH False Positives: IT support scripts that intentionally authenticate to IPC$ with alternate credentials for administrative tasks Blind Spots: Misses credential spraying performed directly via SMB (not through net.exe) or via a compiled tool; misses a single successful authentication with no separately-logged failed attempts Validation: Run net use \\<host>\IPC$ /user:test test on a test host; a known IT helpdesk tool’s scripted use of alternate credentials against IPC$ should be allow-listed by source host Deployment: Windows EDR / Sysmon, all hosts

title: Net Use Command Targeting an Administrative Share With Explicit Credentials
id: 5d2247ea-b600-44f7-b87a-cb8759dcecff
status: experimental
description: >-
    Detects a net use command mapping the IPC$ administrative share with an
    explicit /user: credential argument, the command-line shape of a manual
    credential-spray attempt against a single internal host rather than
    routine drive mapping under the caller's own session credentials.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.lateral-movement
    - attack.t1021.002
    - stp.3
logsource:
    category: process_creation
    product: windows
detection:
    selection_image:
        Image|endswith: '\net.exe'
    selection_share:
        CommandLine|contains: 'IPC$'
    selection_cred:
        CommandLine|contains: '/user:'
    condition: all of selection_*
falsepositives:
    - IT support scripts that intentionally authenticate to IPC$ with alternate credentials for administrative tasks
level: high

File name: proc_creation_win_ipc_share_credential_spray.yml

Linux Kernel LPE (Public Dirty Frag)

Content Change to /etc/passwd or /usr/bin/su by a Non-Package Account Tool

Tier: Detection Robustness: 3 ATT&CK Coverage: T1098 (Account Manipulation), T1222.002 (Linux and Mac File and Directory Permissions Modification) Confidence: HIGH False Positives: Legitimate account provisioning against /etc/passwd via systemd-sysusers, useradd, or chfn is excluded above (filter_system_account_tools); this closed 4 of 4 lifetime alerts, all reproduced legitimate provisioning. A package-manager transaction that patches /usr/bin/su by updating coreutils is NOT filtered and should still be correlated and excluded before alerting. Blind Spots: Misses privilege escalation that creates a new uid-0 account elsewhere in /etc/passwd rather than overwriting line 1, or that patches a different SUID binary instead of /usr/bin/su. filter_system_account_tools also recognizes the invoking tool by binary path, not whether a package manager actually triggered it: an attacker who runs the genuine useradd, chfn, or systemd-sysusers binary directly against /etc/passwd, with no package transaction involved at all, is now silently excluded here too. That gap is exactly what the companion process_creation rule below targets, by watching argument shapes and process ancestry rather than tool identity. Validation: Overwrite /usr/bin/su directly, or touch /etc/passwd from a process whose image path does not end in /systemd-sysusers, /useradd, or /chfn; both must fire. Run systemd-sysusers, useradd, or chfn against /etc/passwd (or trigger the pacman 20-systemd-sysusers.hook or a dpkg adduser --system post-install path) and confirm it does NOT fire, while a parallel /usr/bin/su overwrite in the same test still fires, confirming the filter is scoped to the /etc/passwd arm only. Deployment: Linux EDR / Sysmon for Linux file events (the measured deployment used Elastic Endpoint file events), all hosts, prioritized on any host exposed to a page-cache-write kernel exploit. Raw auditd is not a source as written: it splits the path (PATH record) from the executable (SYSCALL record), and this rule needs TargetFilename and Image in one event, which needs a normalisation pipeline the rule does not declare. Deploy alongside the companion process_creation rule below, which restores the direct-invocation coverage this rule’s package-tool exclusion gives up.

Fixed 2026-09-02 (measured on logs-endpoint.events.file-* over the full 55-day retained window). The rule’s original title claimed detection “outside a package transaction”, which the query never implemented: selection matched any write to /etc/passwd or /usr/bin/su with no correlation to package-manager activity at all, so every legitimate account-provisioning write also alerted. Measured lifetime: 4 of 4 alerts were legitimate provisioning, reproduced independently on two unrelated package ecosystems, pacman’s 20-systemd-sysusers.hook on one host and dpkg’s adduser --system (invoking useradd and chfn) on another. A genuine package-transaction correlation is not achievable with this telemetry: Elastic Endpoint file events carry no process.parent.name or process.parent.executable, only an opaque process.parent.entity_id, and the cross-index join needed to resolve the invoking process returns zero hits on one host and only a generic perl interpreter on the other, neither of which identifies a package transaction. filter_system_account_tools therefore excludes by invoking-tool identity instead, scoped to /etc/passwd only so /usr/bin/su keeps full, unfiltered coverage. Measured 4 to 0, with a residual check confirming zero other /etc/passwd or /usr/bin/su events in the 55-day corpus. The coverage this costs, an attacker running the genuine account tools directly with no package transaction involved, is accepted deliberately and mitigated by the companion rule below (ea34e2ee-aedb-4ead-a572-2fb6531e41a2).

title: Content Change to /etc/passwd or /usr/bin/su by a Non-Package Account Tool
id: 9d64a8dc-f752-4455-9329-73ff8738d150
status: experimental
description: >-
    Detects a file-write event against /etc/passwd or /usr/bin/su, excluding
    writes to /etc/passwd made by the known account-provisioning tools
    systemd-sysusers, useradd, and chfn. Both files are the two overwrite
    targets of a public Linux kernel local-privilege-escalation exploit chain
    that patches the page cache via IPsec/XFRM or AF_RXRPC splice tricks to
    create a uid-0 account or a backdoored su binary without any legitimate
    package installation. This rule recognizes the invoking tool by binary
    path, not whether a package manager actually triggered it, so it does not
    correlate with an actual package transaction: every /usr/bin/su write
    still alerts regardless of what wrote it. See the companion
    process_creation rule, Useradd or Usermod Setting a Root-Equivalent or
    Duplicate UID Outside a Known Package Manager
    (ea34e2ee-aedb-4ead-a572-2fb6531e41a2), for coverage of these same account
    tools when an attacker invokes them directly rather than through a
    package's post-install hook.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.persistence
    - attack.privilege-escalation
    - attack.t1098
    - attack.defense-impairment
    - attack.t1222.002
logsource:
    category: file_event
    product: linux
detection:
    selection:
        TargetFilename:
            - '/etc/passwd'
            - '/usr/bin/su'
    filter_system_account_tools:
        # sourced: measured 2026-09-02 on logs-endpoint.events.file-* over the full
        # 55-day retained window - 4 of 4 lifetime alerts were legitimate account
        # provisioning, reproduced independently via pacman's 20-systemd-sysusers.hook
        # and dpkg's adduser --system (invoking useradd and chfn)
        TargetFilename: '/etc/passwd'
        Image|endswith:
            - '/systemd-sysusers'
            - '/useradd'
            - '/chfn'
    condition: selection and not filter_system_account_tools
falsepositives:
    - >-
        A package-manager transaction that patches /usr/bin/su by updating coreutils.
        This arm is NOT filtered above (the exclusion is scoped to /etc/passwd only)
        and should still be correlated and excluded before alerting.
    - >-
        Legitimate account provisioning against /etc/passwd via systemd-sysusers,
        useradd, or chfn is excluded above and should not appear as an alert; if one
        does, confirm the invoking binary path actually matches one of the three
        filtered tools.
level: high

File name: file_event_lnx_passwd_su_privesc_tamper.yml

Useradd or Usermod Setting a Root-Equivalent or Duplicate UID Outside a Known Package Manager

Tier: Detection Robustness: 3 ATT&CK Coverage: T1136.001 (Local Account), T1098 (Account Manipulation) Confidence: HIGH False Positives: A deliberately provisioned dual-root-equivalent service account documented as a business exception, for example a legacy appliance or application that requires --non-unique or -u 0. A configuration-management tool (Ansible, Puppet, Chef, cloud-init) that shells out to useradd or usermod directly instead of through a package manager, since the parent-image filter below only excludes package-manager parents, not provisioning frameworks. Blind Spots: Misses privilege escalation via useradd/usermod that avoids these specific flags entirely, for example usermod -aG sudo or usermod -aG wheel to add an existing account to a privileged group, or any route that edits /etc/passwd, /etc/shadow, or /etc/sudoers directly rather than going through these two tools; the companion file_event rule (9d64a8dc-f752-4455-9329-73ff8738d150) covers the direct-file-edit path for /etc/passwd and /usr/bin/su specifically. The package-manager parent filter is also a fixed list of known binaries, not a true transaction correlation: a configuration-management tool not on that list, or a bespoke provisioning script that itself shells out to useradd/usermod, is not distinguished from an attacker doing the same thing. Validation: Run usermod -u 0 <existing-non-root-account> or useradd -o -u 0 backdoor directly from an interactive shell on a test host; must fire. Trigger a real package installation whose postinst script calls useradd (for example a package that provisions a system account) and confirm it does NOT fire, because its parent resolves to the package manager. Deployment: Linux EDR / Sysmon for Linux / auditd (SYSCALL and EXECVE records correlated to a resolved parent), all hosts. Deploy alongside the companion file_event rule (9d64a8dc-f752-4455-9329-73ff8738d150), which covers the same technique from the file-write side and gives up direct-invocation coverage that this rule restores.

Authored 2026-09-02 to close the gap recorded against 9d64a8dc-f752-4455-9329-73ff8738d150. That rule’s filter_system_account_tools exclusion recognizes systemd-sysusers, useradd, and chfn by binary path alone, with no way to confirm a package manager actually invoked them, because Elastic Endpoint file events carry no resolved parent-process field. An attacker who runs those same binaries directly, with a shell or an SSH session as the real parent, is therefore invisible to that rule. Process-creation telemetry does carry ParentImage, so this rule targets the same tools from that side instead: a high-signal argument shape that grants a root-equivalent or duplicate UID/GID, which fires unless the parent resolves to a known package manager.

title: Useradd or Usermod Setting a Root-Equivalent or Duplicate UID Outside a Known Package Manager
id: ea34e2ee-aedb-4ead-a572-2fb6531e41a2
status: experimental
description: >-
    Detects useradd or usermod invoked with a flag that grants a root-
    equivalent or duplicate UID/GID (-o, -u 0, -g 0, --non-unique, or their
    long-form equivalents), where the parent process is not a known package
    manager. This is the direct-invocation counterpart to Content Change to
    /etc/passwd or /usr/bin/su by a Non-Package Account Tool
    (9d64a8dc-f752-4455-9329-73ff8738d150): that rule excludes writes to
    /etc/passwd made by these same account tools so it does not re-alert on
    routine package-driven provisioning, and by construction cannot see the
    tools invoked directly by an attacker, because file-write telemetry alone
    carries no reliable process-ancestry field. This rule uses process-
    creation telemetry instead, which does carry ParentImage, to restore that
    direct-invocation coverage.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-09-02
tags:
    - attack.persistence
    - attack.privilege-escalation
    - attack.t1136.001
    - attack.t1098
    - stp.4
logsource:
    category: process_creation
    product: linux
    definition: >-
        Requires process-creation telemetry carrying both CommandLine and a
        resolved ParentImage, for example Sysmon for Linux Event ID 1 or an
        EDR agent process-creation event. Plain auditd EXECVE records alone
        do not carry a resolved ParentImage field without additional PPID
        correlation.
detection:
    selection_tool:
        Image|endswith:
            - '/useradd'
            - '/usermod'
    selection_privileged_flags:
        CommandLine|contains:
            - ' -o '
            - ' -u 0'
            - ' -u0'
            - ' --uid 0'
            - ' --uid=0'
            - ' -g 0'
            - ' -g0'
            - ' --gid 0'
            - ' --gid=0'
            - '--non-unique'
    filter_parent_pkgmgr:
        # sourced: documented platform default - the standard Linux package-manager
        # binaries (dpkg/apt on Debian-family, rpm/yum/dnf on RHEL-family, pacman on
        # Arch-family) that legitimately invoke useradd/usermod from postinst or hook
        # scripts during package installation
        ParentImage|endswith:
            - '/dpkg'
            - '/apt'
            - '/apt-get'
            - '/rpm'
            - '/yum'
            - '/dnf'
            - '/pacman'
            - '/systemd-sysusers'
    condition: selection_tool and selection_privileged_flags and not filter_parent_pkgmgr
falsepositives:
    - >-
        A deliberately provisioned dual-root-equivalent service account on an
        appliance or legacy application that documents a --non-unique or -u 0
        requirement. Verify against change records before treating as a true
        positive.
    - >-
        A configuration-management tool (Ansible, Puppet, Chef, cloud-init) that
        shells out to useradd or usermod directly rather than through a package
        manager. The parent-image filter above only excludes package-manager
        parents, not provisioning frameworks, so an environment using one of
        these should extend filter_parent_pkgmgr with its process name.
level: high

File name: proc_creation_lnx_useradd_usermod_uid0_privesc.yml

Hunting Rules

Tunnelling & Internal Pivot

Chisel or PuTTY Plink Binary Written to Disk

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1105 (Ingress Tool Transfer) Confidence: MODERATE False Positives: Legitimate administrative use of PuTTY plink for scripted SFTP/SCP or SSH automation; authorized use of chisel by an internal red team or IT support function Blind Spots: Misses either tool renamed to a non-standard filename; misses delivery via an archive or installer rather than a direct binary write Validation: Copy chisel_win.exe or plink.exe to a test host; treat any hit as a hunting lead requiring confirmation of the file’s origin (an external HTTP fetch is the high-confidence variant) before escalating Deployment: Windows EDR / Sysmon, all hosts

title: Chisel or PuTTY Plink Binary Written to Disk
id: c6a0fca5-676f-46b7-b4db-bbfaa55a6352
status: experimental
description: >-
    Detects a chisel or plink binary being written to disk. Both are
    legitimate dual-use tools frequently repurposed by intruders for
    reverse-SOCKS tunneling and SSH-based internal pivoting after an initial
    foothold; review the file's origin before treating a hit as malicious,
    since a fetch from an external HTTP server rather than an internal
    software repository is the high-confidence variant of this behavior.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.command-and-control
    - attack.t1105
logsource:
    category: file_event
    product: windows
detection:
    selection:
        TargetFilename|endswith:
            - '\chisel.exe'
            - '\chisel_win.exe'
            - '\plink.exe'
    condition: selection
falsepositives:
    - Legitimate administrative use of PuTTY plink for scripted SFTP/SCP or SSH automation
    - Authorized use of chisel by an internal red team or IT support function
level: medium

File name: file_event_win_chisel_plink_external_fetch_drop.yml

Userland Rootkit & AAA-Host Anti-Forensics

Content Change to a Core Process or Network Inspection Utility

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1014 (Rootkit) Confidence: MODERATE False Positives: Routine package-manager updates to procps, psmisc, findutils, or rpm; operating-system or distribution upgrades that replace these utilities during a normal maintenance window Blind Spots: A single hit alone is expected noise, since individual per-file changes are common after routine updates. Sigma cannot express the “multiple hits across this set on the same host in a short window, outside a package transaction” correlation that is the actual high-confidence rootkit-install signature; an analyst must apply that correlation manually. The Detection-tier coverage for this specific artifact lives in the YARA tar-archive rule instead, which anchors on the structural originals-backup pattern rather than individual file events Validation: Modify any of the seven listed binaries on a test host; a routine yum/apt update touching one of these binaries as part of a scheduled patch cycle is the expected single-hit false positive and should not be escalated alone Deployment: Linux EDR / Sysmon for Linux / FIM tooling, all hosts, especially AAA/RADIUS and other security-relevant infrastructure

title: Content Change to a Core Process or Network Inspection Utility
id: 2581fa99-4d4b-412d-a2b5-46a119e87aa5
status: experimental
description: >-
    Detects a file-write event against one of the seven Linux binaries most
    commonly replaced by a userland rootkit to hide processes, network
    connections, files and package tampering (ps, top, pstree, netstat,
    lsof, find, rpm). A single hit is common after routine package updates;
    multiple hits across this set on the same host in a short window,
    outside a package-manager transaction, is the high-confidence signature
    and should be triaged as a probable rootkit install.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.stealth
    - attack.t1014
logsource:
    category: file_event
    product: linux
detection:
    selection:
        TargetFilename:
            - '/bin/ps'
            - '/usr/bin/ps'
            - '/bin/top'
            - '/usr/bin/top'
            - '/usr/bin/pstree'
            - '/bin/netstat'
            - '/usr/bin/netstat'
            - '/usr/sbin/lsof'
            - '/usr/bin/lsof'
            - '/usr/bin/find'
            - '/bin/find'
            - '/bin/rpm'
            - '/usr/bin/rpm'
    condition: selection
falsepositives:
    - Routine package-manager updates to procps, psmisc, findutils or rpm
    - Operating-system or distribution upgrades that replace these utilities during a normal maintenance window
level: medium

File name: file_event_lnx_userland_rootkit_binary_tamper.yml

Creation or Modification of the safe_pollRadiusLog Watchdog Script

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1543 (Create or Modify System Process), T1070.006 (Indicator Removal: Timestomp, contextual; the file’s mtime was backdated, but the file_event category does not carry that field) Confidence: MODERATE False Positives: Unlikely. This is a campaign-specific filename, and any legitimate script sharing it should be independently verified rather than excluded outright Blind Spots: A single hardcoded path (/usr/local/bin/safe_pollRadiusLog.sh, matched exactly, so a copy of the file elsewhere does not match); a renamed variant in a future campaign evades entirely. This rule has genuine retrospective-hunting and attribution value for this specific campaign but is not durable against operator rotation, which is why it is capped at Hunting despite the very low false-positive rate Validation: Create or modify a file at this exact path on a test host; there is no legitimate software distribution that ships a file with this name at this path Deployment: Linux EDR / Sysmon for Linux, prioritized on AAA/RADIUS infrastructure

title: Creation or Modification of the safe_pollRadiusLog Watchdog Script
id: 2f9c1dfd-3d00-402b-81ff-86e441136d3e
status: experimental
description: >-
    Detects a file-write event against safe_pollRadiusLog.sh under
    /usr/local/bin. In this campaign the operator rewrote this exact path
    into a self-healing watchdog for a RADIUS statistics daemon on a
    carrier AAA host, then backdated the file's modification time to
    2010-10-07 to blend it in with genuinely old system files.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.persistence
    - attack.privilege-escalation
    - attack.t1543
logsource:
    category: file_event
    product: linux
detection:
    selection:
        TargetFilename: '/usr/local/bin/safe_pollRadiusLog.sh'
    condition: selection
falsepositives:
    - Unlikely; this is a campaign-specific filename, and any legitimate script sharing it should be independently verified rather than excluded outright
level: medium

File name: file_event_lnx_radius_watchdog_backdoor_script.yml

Java Process Spawning a Unix Shell With an Inline Command

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1059.004 (Unix Shell) Confidence: HIGH Rationale: The rule tests one shape: a Java process (parent image ending in /java) directly starting bash, sh or dash with the text ` -c ` in the command line. That is a common shape of command execution after a JVM compromise, but not an unavoidable one: an exploit that reaches a shell through an intermediate process, or that runs a command without a shell, does not produce it (see Blind Spots), so the durability is that of one process relationship (Robustness 2). The rule tests nothing about the exploitation that came before, and any Java service that shells out with ` -c ` matches; the title previously claimed that the shell followed WebLogic JNDI exploitation. It is Hunting tier at level medium for that reason. False Positives: Java-based build, backup, or health-check tooling that intentionally shells out to run a maintenance command; application servers configured to invoke OS-level scripts as part of legitimate scheduled jobs Blind Spots: Misses RCE payloads that reach a shell through an intermediate process rather than java spawning the shell directly; misses non-Java application servers entirely Validation: Have a test Java process start /bin/bash -c 'id' directly: the rule must fire. A Java process starting /bin/bash script.sh without ` -c , one starting a tool such as /usr/bin/id directly, and one reaching a shell through an intermediate process, must NOT fire. A Java backup or health-check tool that itself runs bash -c` WILL fire and is reviewed against the false-positive list. Deployment: Linux EDR / Sysmon for Linux on WebLogic, GeoServer, or any Java application-server host

title: Java Process Spawning a Unix Shell With an Inline Command
id: a14ad5ee-c455-49ce-8c4d-92064c64b03b
status: experimental
description: >-
    Detects a Java process (a parent image ending in /java) directly spawning
    a Unix shell with an inline command argument. The test does not look for the
    exploitation that preceded it. The pattern is consistent with WebLogic T3/IIOP JNDI
    deserialization exploitation (CVE-2023-21839, CVE-2024-21182) reaching a
    reverse-shell or beacon payload such as bash -i redirected to /dev/tcp or
    a curl proof-of-execution callback.
references:
    - https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/
    - https://nvd.nist.gov/vuln/detail/CVE-2023-21839
    - https://nvd.nist.gov/vuln/detail/CVE-2024-21182
author: The Hunters Ledger
date: 2026-08-17
tags:
    - attack.execution
    - attack.t1059.004
    - stp.3
logsource:
    category: process_creation
    product: linux
detection:
    selection_parent:
        ParentImage|endswith: '/java'
    selection_shell:
        Image|endswith:
            - '/bin/bash'
            - '/bin/sh'
            - '/bin/dash'
    selection_flag:
        CommandLine|contains: ' -c '
    condition: all of selection_*
falsepositives:
    - Java-based build, backup or health-check tooling that intentionally shells out to run a maintenance command
    - Application servers configured to invoke OS-level scripts as part of legitimate scheduled jobs
level: medium

File name: proc_creation_lnx_java_spawns_shell_weblogic_rce.yml

Tunnelling & Internal Pivot

Suricata Signatures

Detection Rules

Cisco IOS-XE WSMA Exfiltration

Network-Device Self-Exfiltration via Outbound PUT with User-Agent cisco-IOS

Tier: Detection Robustness: 3 ATT&CK Coverage: T1048.003 (Exfiltration Over Unencrypted Non-C2 Protocol), T1041 (Exfiltration Over C2 Channel) Confidence: HIGH False Positives: None known. Legitimate Cisco IOS-XE devices do not PUT their own firmware, core dumps, or configuration files to arbitrary internet destinations outside a vendor-managed workflow, and that workflow does not use this method Blind Spots: Misses the exfiltration if a future campaign spoofs a different User-Agent string, or if the compromised device is a different vendor whose self-identifying User-Agent differs from cisco-IOS Validation: Configure a lab IOS-XE device to WSMA fileCopy a file to an external HTTP listener and confirm the alert fires; a legitimate software check-in from the same device class to vendor update infrastructure (which uses GET, not PUT, for that purpose) must NOT fire Deployment: Perimeter / egress sensor, prioritized on any network segment carrying traffic from carrier-managed customer-premises equipment

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"THL DETECT WebLogicTelecomHarvester Network-Device Self-Exfiltration Outbound PUT UA cisco-IOS (WSMA Abuse)"; flow:established,to_server; content:"PUT"; http_method; content:"cisco-IOS"; http_user_agent; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:trojan-activity; sid:9301801; rev:2; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Cisco IOS-XE Double-Encoded WSMA Path Bypass (Operator Fingerprint)

Tier: Detection Robustness: 3 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: HIGH False Positives: None known. This exact double-encoded string does not occur in legitimate WSMA client traffic or in the public CVE-2023-20198 proof-of-concept tooling, which uses a different, single-encoded lowercase form Blind Spots: Misses the wider CVE-2023-20198 exploitation class entirely; see the companion GENERIC rule below for that coverage. Misses a future campaign where this operator changes the encoding pattern Validation: Send a test HTTP POST containing this exact URI string to a lab web server and confirm the alert fires; a request using the generic, single-encoded public proof-of-concept path must NOT fire this rule (it fires the separate GENERIC rule instead) Deployment: Perimeter sensor in front of any IOS-XE WebUI management interface

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL DETECT WebLogicTelecomHarvester Cisco IOS-XE Double-Encoded WSMA Path Bypass (CVE-2023-20273 Operator Fingerprint)"; flow:established,to_server; content:"%2577eb%2575i_%2577sma_Http"; http_uri; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:trojan-activity; sid:9301802; rev:2; metadata:author The_Hunters_Ledger, date 2026-08-17;)

GENERIC-CVE-2023-20198 Cisco IOS-XE WebUI Auth-Bypass URI

Not operator-specific. This rule fires on the generic public CVE-2023-20198 auth-bypass URI, which is a materially broader detection than the operator fingerprint above. It also fires on the five other, unrelated intruders confirmed hitting the same victim router with this exact public URI. Do not treat a hit on this rule alone as attribution to this operator.

Tier: Detection Robustness: 2 ATT&CK Coverage: T1190 Confidence: HIGH False Positives: None known. This specific URI and query-string combination is the confirmed public CVE-2023-20198 auth-bypass confirmation path and does not occur in ordinary IOS-XE WebUI browsing Blind Spots: Deliberately broad by design (see the callout above); cross-reference with the operator-specific double-encoded-path rule or source IP before attributing a hit to this campaign Validation: Send a test HTTP POST to /webui/logoutconfirm.html?logon_hash=1 against a lab web server and confirm the alert fires; ordinary logout traffic on an unrelated web application lacking the logon_hash=1 parameter must NOT fire Deployment: Perimeter sensor in front of any IOS-XE WebUI management interface

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL DETECT GENERIC-CVE-2023-20198 Cisco IOS-XE WebUI Auth-Bypass Confirmation URI (Public Exploit Class, Not Operator-Specific)"; flow:established,to_server; content:"/webui/logoutconfirm.html"; http_uri; content:"logon_hash=1"; http_uri; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:web-application-attack; sid:9301803; rev:2; metadata:author The_Hunters_Ledger, date 2026-08-17;)

GENERIC-CVE-2023-20198 Cisco IOS-XE Forged Bare-Hex Authorization Token

Not operator-specific. This rule matches the forged-token shape used across the public CVE-2023-20198 exploitation class, not this operator’s specific literal value (0123456789abcdefab).

Tier: Detection Robustness: 2 ATT&CK Coverage: T1190 Confidence: HIGH False Positives: None known for a well-formed HTTP Authorization header. Legitimate clients always send a recognized auth scheme (Basic, Bearer, Digest, and similar) as a prefix; a bare 18-character hex string with nothing else (upper or lower case, because the PCRE is case-insensitive) is not a real credential format used by any standard client Blind Spots: Generic CVE-class signature. Will fire on any of the other observed intruders or future unrelated actors using a forged bare-hex token of the same length. Misses a forged token of a different length or one wrapped in a scheme prefix to evade this exact-length check Validation: Send a test HTTP request with Authorization: 0123456789abcdefab (no scheme) against a lab web server and confirm the alert fires; a request with a genuine Authorization: Basic <base64> header must NOT fire Deployment: Perimeter sensor in front of any IOS-XE WebUI management interface

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL DETECT GENERIC-CVE-2023-20198 Cisco IOS-XE Forged Bare-Hex Authorization Token (Public Exploit Class)"; flow:established,to_server; content:"Authorization"; http_header; pcre:"/^Authorization:\s*[a-f0-9]{18}\s*$/mHi"; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:web-application-attack; sid:9301804; rev:2; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Design note: The H PCRE flag pins the match to the normalized HTTP header buffer, and the fixed {18} count (not a variable-length run) means this pattern cannot absorb the buffer’s own CRLF line terminator the way a greedy quantifier could.

WebLogic T3/JNDI Exploitation

WebLogic T3/IIOP JNDI OpaqueReference Injection

Tier: Detection Robustness: 3 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: HIGH False Positives: None known. Legitimate WebLogic T3/IIOP administrative traffic does not carry these specific JNDI reference class names; they are the CVE-2023-21839/CVE-2024-21182 exploitation primitive itself Blind Spots: Port-scoped to 7001, this campaign’s observed target port, so it misses the same exploitation traffic against a WebLogic instance running on a non-default T3 port. Misses the exploit entirely if the payload is fragmented such that OpaqueReference never appears as a contiguous string within a single inspected segment Validation: Send a captured or reconstructed CVE-2023-21839/CVE-2024-21182 exploitation payload against a lab WebLogic instance on port 7001 and confirm the alert fires; ordinary WebLogic T3 administrative traffic (console login, cluster heartbeat) must NOT fire Deployment: Perimeter / internal segment sensor in front of any WebLogic T3 listener

alert tcp $EXTERNAL_NET any -> $HOME_NET 7001 (msg:"THL DETECT WebLogicTelecomHarvester WebLogic T3-IIOP JNDI OpaqueReference Injection (CVE-2023-21839/CVE-2024-21182)"; flow:established,to_server; content:"OpaqueReference"; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:attempted-admin; sid:9301806; rev:2; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Design note: This rule matches on OpaqueReference as a suffix common to both AggregatableOpaqueReference and ForeignOpaqueReference, the two class names that co-occur in every observed variant of this exploitation chain.

GeoServer OGC-Filter RCE via valueReference exec()

Tier: Detection Robustness: 3 ATT&CK Coverage: T1190 Confidence: HIGH False Positives: None known. Legitimate GeoServer OGC-filter requests do not construct a valueReference value that invokes exec( Blind Spots: Misses obfuscated or URL-encoded variants of the payload where exec( does not appear as a contiguous literal string in the URI; misses exploitation of the same CVE delivered via a request body rather than the URI Validation: Send the CVE-2024-36401 test payload (valueReference=exec(java.lang.Runtime.getRuntime(),'whoami')) against a lab GeoServer instance and confirm the alert fires; an ordinary WFS GetPropertyValue request using a benign valueReference must NOT fire Deployment: Perimeter sensor in front of any GeoServer instance

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL DETECT WebLogicTelecomHarvester GeoServer OGC-Filter RCE via valueReference exec() (CVE-2024-36401)"; flow:established,to_server; content:"valueReference"; http_uri; content:"exec("; http_uri; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:web-application-attack; sid:9301809; rev:2; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Hunting Rules

Tunnelling & Internal Pivot

WebSocket Upgrade Handshake to an External Host (Tunnel Hunting Lead)

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1572 (Protocol Tunneling) Confidence: LOW Rationale: The report records chisel v1.23.1 (a reverse tunnel carried over WebSocket). The rule matches an Upgrade: request header followed within 16 bytes by the word websocket, in any letter case and with any spacing in that gap, from $HOME_NET to $EXTERNAL_NET, and nothing chisel-specific, so it flags any outbound WebSocket upgrade handshake that the sensor can read as HTTP as a lead for tunnel hunting. It reads the header text itself, so it fires only on a plaintext or decrypted (TLS-inspected) handshake; an ordinary TLS connection hides the header and does not match. False Positives: Any legitimate application using WebSockets. Chat applications, live dashboards, monitoring tools, and many modern web apps use this same upgrade handshake. This rule is intentionally broad and requires analyst triage of the destination and subsequent traffic pattern; a persistent, otherwise-idle connection carrying periodic small frames is more consistent with a tunnel than an interactive WebSocket application Blind Spots: Cannot distinguish chisel specifically from any other WebSocket-based tool without deeper protocol fingerprinting. The four captured chisel server key fingerprints in the IOC feed are a stronger pivot once a candidate connection is identified, but they are not wire-visible without TLS interception, since chisel typically runs over HTTPS Validation: Send a plaintext HTTP/1.1 request with an Upgrade: websocket header (or a differently cased or spaced form such as Upgrade:WebSocket) from a lab host to an external server and confirm the alert fires; a chisel or other WebSocket connection over TLS fires only where the sensor decrypts it. Expect it to also fire on unrelated legitimate WebSocket traffic, which is the reason for the Hunting tier. An Upgrade: h2c request must NOT fire Deployment: Egress sensor, hunting sweep rather than a blocking rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"THL HUNT WebLogicTelecomHarvester WebSocket Upgrade Handshake to an External Host (Broad Tunnel Hunting Lead, Not Chisel-Specific)"; flow:established,to_server; content:"Upgrade|3a|"; nocase; http_header; content:"websocket"; nocase; http_header; distance:0; within:16; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:trojan-activity; sid:9301808; rev:4; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Monitoring-Plane Credential Harvest (PRTG)

PRTG Bulk Device Inventory Query via table.json

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1018 (Remote System Discovery) ATT&CK Note: T1555 was listed here as contextual and is withdrawn. The rule matches a table.json?content=devices&count=500 request, which enumerates up to 500 monitored devices with their hosts and groups (the fleet-enumeration step in the operator’s script); it observes no password-store access. The credential-extraction rule below carries T1555. Confidence: LOW False Positives: Legitimate bulk device-inventory queries are a normal part of PRTG dashboard usage, monitoring integrations, and reporting tools; this specific query shape is not inherently malicious on its own Blind Spots: Cannot distinguish an operator’s reconnaissance pull from a legitimate administrator’s or integration’s bulk query without additional context (source IP reputation, time of day, or correlation with the credential-extraction rule above) Validation: Send a test table.json?content=devices&count=500 request against a lab PRTG instance and confirm the alert fires; expect this to also fire on legitimate administrative and integration traffic, which is the reason for the Hunting tier Deployment: Perimeter or internal sensor, hunting sweep rather than a blocking rule

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL HUNT WebLogicTelecomHarvester PRTG Bulk Device Inventory Query via table.json (Broad, Legitimate Bulk Queries Exist)"; flow:established,to_server; content:"table.json"; http_uri; content:"content=devices"; http_uri; content:"count=500"; http_uri; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:attempted-recon; sid:9301812; rev:2; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Malicious LDAP-JNDI Callback Response

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 Confidence: MODERATE False Positives: Round 2, 2026-10-10: the rule matches the string javaCodeBase anywhere in the payload of any inbound TCP response to a $HOME_NET client. It does not establish that the traffic is LDAP or that the string is an attribute value, so a downloaded web page, source file or document that contains the text also fires. The string is uncommon in ordinary LDAP directory responses (user lookups, group membership, authentication binds), which is why it is still a useful lead; it is not proof of a JNDI callback. Re-tiered from Detection to Hunting Blind Spots: Covers only the reference mode (javaCodeBase); a serialized-object response (javaSerializedData, documented as a separate mode in the report at lines 653 to 655) is not tested, and the earlier msg that listed both was corrected. Misses the callback if it uses RMI instead of LDAP for the JNDI response. Port-agnostic by design (any dest port), trading a small amount of specificity for coverage across this operator’s non-standard port 1389 and any future port choice Validation: Stand up a malicious JNDI/LDAP callback server serving a javaCodeBase reference and trigger a test JNDI lookup against it from a lab Java application; ordinary LDAP directory traffic (an Active Directory bind and search, for example) must NOT fire (an LDAP bind and search carries no javaCodeBase); a web page or file download containing that text will fire Deployment: Egress sensor, prioritized on any segment where a Java application server can reach the internet

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"THL HUNT WebLogicTelecomHarvester Inbound TCP Response Carrying javaCodeBase (JNDI Reference Callback Lead)"; flow:established,to_client; content:"javaCodeBase"; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:attempted-admin; sid:9301807; rev:4; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Direction fix 2026-10-10: the header read $HOME_NET any -> $EXTERNAL_NET any with flow:established,to_client. to_client selects packets sent by the server of the flow, so that pairing matched an internal host answering an external client, not an external callback server answering the victim. The attacker-side LDAP server is the $EXTERNAL_NET source and the Java application server is the $HOME_NET destination, so the header is now $EXTERNAL_NET any -> $HOME_NET any; rev 2 to 3. Round 2: msg narrowed from a malicious-LDAP claim covering javaCodeBase/javaSerializedData to the one string the rule tests, tier token changed to HUNT, rev 3 to 4. Not replayed against a capture in this pass.

Internal Windows Post-Exploitation

PRTG getobjectproperty.htm Request With passhash Authentication

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1555 (Credentials from Password Stores) Confidence: HIGH Rationale: The report describes a seven-stage script that, using working administrative API credentials, pulls stored Windows, Linux and SNMP credentials for monitored devices (staged, with no captured outcome). The rule matches a request URI that contains getobjectproperty.htm and passhash=. It tests no property name, so it does not tell a credential-property read from any other property read, and it applies no count and no threshold, so every matching request alerts. It was re-tiered from Detection to Hunting because PRTG integrations and scripts that authenticate with a passhash call this endpoint routinely. False Positives: PRTG API clients, integrations and administrator scripts that authenticate with passhash= and read object properties through getobjectproperty.htm; the endpoint is ordinary API usage, so the request is not specific to extraction Blind Spots: Requires visibility into plaintext HTTP. If the target serves PRTG exclusively over HTTPS/TLS without SSL inspection, this signature will not fire, and detection should rely on the corresponding PRTG audit-log signal instead (see Coverage Gaps). Misses credential extraction performed via a session cookie rather than a passhash= parameter Validation: Send a test getobjectproperty.htm?name=windowsloginpassword&passhash=<value> request against a lab PRTG instance and confirm the alert fires; an ordinary authenticated PRTG dashboard page load must NOT fire, and a request for getobjectproperty.htm that does not carry passhash= must NOT fire. An API client reading any other property with passhash= WILL fire Deployment: Perimeter sensor in front of any PRTG instance. The rule needs an $EXTERNAL_NET source and a $HOME_NET destination, so a sensor on an internal segment sees nothing from it for PRTG traffic that stays inside $HOME_NET unless $EXTERNAL_NET is redefined.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL HUNT WebLogicTelecomHarvester PRTG getobjectproperty.htm Request With passhash Authentication (Credential Read Primitive, No Count)"; flow:established,to_server; content:"getobjectproperty.htm"; http_uri; content:"passhash="; http_uri; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:attempted-recon; sid:9301811; rev:3; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Non-Standard X-CMD Webshell Dispatch Header

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1505.003 (Web Shell) Confidence: MODERATE False Positives: An internal API or proxy that legitimately uses a custom X-CMD header for an unrelated purpose. Uncommon, but the header name alone is not unique enough to guarantee zero collision Blind Spots: Misses the webshell entirely if the operator renames the header in a future campaign; misses command dispatch via a POST body or cookie instead of a header Validation: Send a test HTTP request carrying a header named X-CMD against a lab web server and confirm the alert fires. The test is on the header name (the http.header_names buffer), so a request that carries only standard headers, and one whose User-Agent value merely contains the text X-CMD:, must NOT fire Deployment: Perimeter sensor in front of the specific compromised web root, or broadly as a hunting sweep given the MODERATE confidence

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL HUNT WebLogicTelecomHarvester Non-Standard X-CMD Webshell Dispatch Header"; flow:established,to_server; http.header_names; content:"|0d 0a|X-CMD|0d 0a|"; nocase; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:trojan-activity; sid:9301810; rev:3; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Cisco IOS-XE WSMA Exfiltration

Cisco WSMA fileCopy Request With a dstURL Parameter

Tier: Hunting Robustness: 3 ATT&CK Coverage: T1048.003 Confidence: MODERATE Rationale: The report describes the operator invoking fileCopy with srcURL=nvram:/<file> and a dstURL=http://<operator-host>/<file>, so the router uploads its own files. The rule matches the WSMA filesystem namespace, fileCopy and a dstURL= parameter in the request body; the value of dstURL is never inspected, so any scheme (http://, ftp://, tftp://) and any destination host, external or internal, qualifies. The report also records fileCopy as legitimate WSMA functionality, and the discriminator it supplies (an external HTTP destination) is not tested here. The rule is therefore a lead on fileCopy requests with a destination parameter, re-tiered from Detection to Hunting, and not a detector of exfiltration. False Positives: Legitimate WSMA fileCopy administrative usage carries the same three strings: a management platform or script copying a file to an internal server through WSMA fires when its request arrives from an address outside $HOME_NET (a management platform hosted elsewhere, or a sensor that defines $EXTERNAL_NET broadly). The strings together describe the fileCopy primitive the operator used, not the operator’s use of it Blind Spots: Matches only the request body within the sensor’s stream-reassembly depth, so an unusually fragmented SOAP body could evade. The dstURL value is not inspected, so the rule does not separate an external HTTP destination from an internal or non-HTTP one; pair with network context (the rule assumes $EXTERNAL_NET as the source contacting $HOME_NET, which covers this campaign’s shape) Validation: Send a test WSMA fileCopy SOAP request with a dstURL= parameter from an $EXTERNAL_NET address against a lab IOS-XE device and confirm the alert fires, with an http://, an ftp:// or an internal destination alike. A request with fileCopy but no dstURL=, or without the WSMA filesystem namespace, must NOT fire. A legitimate fileCopy with a dstURL= sent from an $EXTERNAL_NET address WILL fire Deployment: Perimeter sensor in front of any Cisco IOS-XE device with WSMA enabled

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL HUNT WebLogicTelecomHarvester Cisco WSMA fileCopy Request With a dstURL Parameter (Self-Exfiltration Lead)"; flow:established,to_server; content:"urn:cisco:wsma-filesystem"; http_client_body; content:"fileCopy"; http_client_body; content:"dstURL="; http_client_body; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/; classtype:trojan-activity; sid:9301805; rev:4; metadata:author The_Hunters_Ledger, date 2026-08-17;)

Coverage Gaps

Artifacts absent from the corpus: no rule is possible

• The custom multi-session C2 console (console.py) was never archived. Only its client side is known: a TCP service on 127.0.0.1:19999 presenting a JSON banner and accepting sessions / use <cid> verbs. Nothing is known about its wire format, so no Suricata signature can be built, and the console binds to localhost only, which puts it outside any Sigma network-connection rule’s reach as well.
• The trojanized userland-rootkit replacement binaries are unrecoverable. Both source captures were searched exhaustively; the replacements for ps, top, pstree, netstat, lsof, find, and rpm were never exposed in the open directory. No hash-based or content-based YARA rule is possible for them, so the Hunting-tier coverage in this file (Rootkit_Userland_OriginalsBackup_TarSet) targets the originals-backup staging pattern instead, which is the closest observable proxy and, confirmed by direct testing, also matches an ordinary backup with no malware present, hence the Hunting tier rather than Detection.
• andinet.sh is known only by name and a single error line (/tmp/andinet.sh: line 122: timeout: command not found). At least 122 lines of a carrier-targeting script exist that were never captured. No content-based detection is possible from one error line.
• evil.dtd is absent from the corpus. Its purpose, out-of-band XXE parameter-entity exfiltration, is known from context elsewhere in the recovered corpus, but the specific template was never recovered, so no signature can be built from its content.
• No packet capture exists for this campaign. Every network-layer detail in this file is reconstructed from the operator’s own logs and captured HTTP responses. Byte-level protocol nuances beyond what those logs record (for example, the exact framing of the chisel WebSocket handshake) cannot be confirmed, which is why the chisel-handshake Suricata rule is a broad Hunting-tier heuristic rather than a protocol-specific Detection signature.

Techniques with no viable rule-language mapping

• The smgmt2.lua:336 IOS-XE WebUI nginx crash trace has no established Sigma logsource. Network-device syslog and vendor-internal WebUI error logs do not map cleanly onto any SigmaHQ-recognized category/product/service combination without inventing a non-standard logsource that would not pass validation. Network-layer coverage for the same exploitation attempt is provided instead by the two Suricata rules on the WSMA request path (WSMA_CVE_2023_20198_DoubleEncode_Exfil-equivalent and the GENERIC auth-bypass URI rule), which fire on the request that causes the crash rather than the crash trace itself. Any core-dump file appearing on an edge router with no known maintenance event correlates with this same signal but likewise has no portable Sigma mapping. Treat both as raw SIEM-query material against vendor syslog exports rather than portable rules.
• The PRTG notification-trigger RCE step is only visible in PRTG’s own audit log, which, like the IOS-XE syslog above, has no SigmaHQ-recognized logsource. The Suricata Detection rule on getobjectproperty.htm covers the credential-extraction call that precedes it; the actual setobjectproperty.htm?id=300&name=active&value=1 trigger call and the subsequent execution have no network-observable signature distinct from ordinary PRTG administration traffic once an attacker holds valid passhash= credentials.
• The XFRM security-association burst (SPI 0xDEADBE10 to 0xDEADBE37) and the unshare(CLONE_NEWUSER|CLONE_NEWNET) plus AF_ALG socket sequence in the Dirty Frag kernel exploit are both local, syscall-level behaviors with no network component. AF_ALG is Linux’s local kernel-crypto API socket family, and it never touches the wire, so no Suricata signature is possible. A Sigma rule would need raw auditd SYSCALL/NETFILTER_CFG records with confirmed field names for the netlink SPI value and the socket cipher argument; the commonly-documented auditd service fields (type, syscall, exe, comm, key, a0…) do not include a confirmed field for either value, and shipping a rule built on an unconfirmed field would risk publishing something that silently never matches. The static YARA rule on the exploit’s distinctive strings (pcbc(fcrypt), DIRTYFRAG_VERBOSE, and related constants) is the practical detection path for this specific tool until a confirmed auditd field mapping exists.
• Mtime-older-than-ctime skew on files under /usr/local/bin/ (the general version of the safe_pollRadiusLog.sh timestomp signature) requires a periodic stat() sweep, not an event stream. Sigma rules match discrete log events; a filesystem-metadata comparison is a scheduled query (Velociraptor, osquery, or a cron-driven FIM sweep), not a portable Sigma rule, so it is intentionally left untranslated here.
• The IOS-XE SNMP engine-time-with-no-reboot indicator (evidence that a memory-resident implant placed months earlier would still be resident) is contextual analytic guidance for an incident responder correlating SNMP polling data against a known exploitation date. It is not event-driven, so it cannot be expressed as a Sigma or Suricata rule at all. It belongs in analyst playbook guidance, not a detection rule file.

Lower-value or high-false-positive areas intentionally not covered

• Internal nmap reconnaissance from the carrier foothold is not covered by a dedicated rule. nmap usage inside a network is common enough among legitimate IT and security teams that a rule discriminating this operator’s sweep from routine internal scanning would need process-genealogy or timing context the available evidence does not establish at the field level required to ship a defensible signature. The chisel reverse-SOCKS Detection rule covers the foothold-establishment moment that precedes this recon, which is the higher-value trigger.
• The bank-probing scripts (vps_bench.sh/2/3) target one specific external retail-bank password-reset endpoint with a timing/enumeration pattern whose intent is best rated MODERATE, since the scripts discard response bodies and self-label “BENCHMARK”. This is single-target-specific rather than a generalizable technique, so it is not translated into a rule here; the URL and target are documented in the IOC feed.
• shodan_full.py’s carrier-scoped reconnaissance queries are operator-side behavior against a third-party API, not victim-observable, and therefore outside the scope of a victim-deployable detection rule.
• decrypt3des.py’s offline attack against GeoServer’s own encrypted datastore passwords is a local, offline cryptographic brute-force against already-exfiltrated data with no network or host execution signature distinct from any other Python process running on the operator’s own machine.
• The Cisco enable/secret wordlist-guessing campaign against the router (evidenced by the bespoke wordlists’ heavy enable/secret/cisco seeding) has no confirmed delivery mechanism in the available evidence. The corpus does not specify whether attempts were sent via the WebUI login form, SSH, or Telnet, and authoring a login-attempt rule without knowing the transport would risk shipping an untested guess rather than an evidence-grounded signature. If a delivery mechanism surfaces in future evidence, a repeated-authentication-failure Suricata or Sigma rule scoped to that specific transport would be straightforward to add.

Atomic indicators routed to the IOC feed instead of authored as rules

Per the routing test in detection-rule-tiering (if removing the single hard-coded literal makes a candidate rule detect nothing, it is an IOC-feed entry, not a rule), the following were deliberately excluded from this file:

• The operator VPS IP-and-port combination 13.140.145.210:4445 hard-coded into the interactive reverse-shell one-liner.
• The two Go compiler build IDs that distinguish the pristine and dirty-tree builds of the CVE-2023-21839 exploit (useful for corpus attribution, too weak and build-specific for a standalone rule).
• The domain radius-sync.com. A single-domain DNS-query match is a pure-IOC selector by definition in both the Sigma and Suricata tiering rubrics, regardless of how distinctive the domain’s naming choice is as investigation narrative.
• The four captured chisel server key fingerprints, genuinely high-fidelity as pivot material once a candidate connection is identified, but not usable as rule content since they are not wire-visible without TLS interception.
• The hard-coded PRTG API credential pair (prtgadmin / passhash withheld, since the hash functions directly as an API authentication token and the target is a live third-party victim) as a bare credential match. The Suricata rule in this file keys on the behavioral combination of the credential parameter alongside the bulk-extraction endpoint and property names, which is durable against credential rotation; the literal credential value itself is IOC-feed material.

All of the above are present in threat-intel-vault/ioc-feeds/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-iocs.json.

License

Detection rules are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).
Free to use, including commercially, with attribution to The Hunters Ledger.

@misc{hunters-ledger-opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections,
  author       = {Harrison, Joseph},
  title        = {Detection Rules: WebLogic Deserialization and Telecom Credential Harvesting, 13.140.145.210},
  howpublished = {The Hunter's Ledger},
  year         = {2026},
  month        = {aug},
  url          = {https://the-hunters-ledger.com/hunting-detections/opendirectory-13-140-145-210-weblogic-deserialization-telecom-harvester-20260817-detections/},
  note         = {Published 18 August 2026. Licensed CC BY 4.0.}
}