Detection Rules — CyberStrike AD Intrusion Workbench

Campaign: INV-2026-080 Date: 2026-11-12 Author: The Hunters Ledger License: CC BY 4.0 Reference: https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/

Detection Coverage Summary

Detection vs Hunting: Detection rules are high-fidelity and evasion-resilient, safe to alert on. Hunting rules are broader or key on a name the operator can change, for scoping and threat-hunting. Expect to review the hits.

The file carries 23 rules: 7 Detection and 16 Hunting. A “Considered and Cut” section near the end lists what I looked at and did not write, with the reason for each.

How this file was built, and what it does not claim

These rules come from a static reading of an operator’s open directory. The operator drove an AI penetration-testing platform (CyberStrikeAI) against Portuguese public-sector and hosting targets from one server, and left a workbench of scripts, builds and logs behind. I found no victim-side telemetry in the capture, so no rule below was confirmed by a victim log. Where a rule keys on something I read in a binary or a script, the rule says so, and where a technique was attempted but no held result shows it working, the rule says that as well.

This version grades each step by what the evidence shows. Where a step is only attempted or its success is not shown (PwnKit, either GodPotato fork, the DNS plugin, the LSASS dumpers, the certificate requests), each rule says so, and no rule claims that a privilege step worked on a victim.

Four limits apply to every rule here.

• Execution was never observed. Nothing from the capture was run. A rule that depends on how Windows or Linux logs an event (a pipe name in Sysmon, a path in a file event) is derived from the artifact’s strings and from how the public technique works, and is marked NOT CHECKED against live telemetry.
• Upstream coverage was read from local clones. The SigmaHQ clone is dated 2026-09-12 and the signature-base clone 2026-09-13, so anything merged after those dates is not reflected. Suricata coverage was read from the ruleset loaded on the sensor.
• No operator or victim value appears in a rule. The one operator-chosen account name that two rules key on is the platform’s own name.
• Upstream novelty is not established for the Sigma rules. The SigmaHQ rule “HackTool - Rubeus Execution” already covers Rubeus.exe, kerberoast and asktgt, so the Rubeus rule here keeps only the asktgs service-ticket request. I read an upstream condition by hand only where a rule’s Validation line says so; for the other rules a broader upstream rule may exist. Whether upstream covers “PwnKit Exploit Staging Via GCONV_PATH Named Directory” (a Linux file event) or “User Account Named Cyberstrike Created” (Windows Security event 4720) is NOT CHECKED. The 7 YARA rules have no close match among 5,791 signature-base rules, which is a comparison of string sets and nothing more.

YARA Rules

Detection Rules

MAL_CyberStrike_DnsPlugin_ServerLevelPluginDll_DomainAdmin_Backdoor

Tier: Detection Robustness: 2 Upstream Coverage: not_covered ATT&CK Coverage: T1136.002 (Domain Account) ATT&CK Note: The DLL also adds the new account to Domain Admins and to the local Administrators group, which is T1098 behaviour, but the rule keys on the file and I tag the technique the file exists for. Confidence: HIGH False Positives: None known. A legitimate DNS Server plugin has no reason to call WinExec with three net commands that create a domain account and grant it Domain Admins. Blind Spots: Misses a variant that creates the account through the Windows API instead of net.exe, one that builds the command strings at run time, and a packed copy. Validation: Hits dnsplugin.dll (sha256 prefix 02a98b325408) in a scan of the held sample; 0 hits on four stock System32 DLLs and on the other 10 held PE and ELF controls; a benign Windows corpus scan (64,867 files) returned 0 hits but the scanner’s own self-test could not exercise a pe[.]is_dll() condition, so I treat that scan as supporting only. Upstream: I scanned the sample with all 748 rule files of the signature-base clone (external variables set to placeholders, 0 of 748 failed to compile or run) and none matched, so signature-base does not cover it. Deployment: Endpoint AV and EDR file scan and a hunt of the file shares reachable from DNS servers. The rule tests filesize, so it does not match inside process memory. Basis: The DNS plugin DLL’s behaviour when loaded and its distinctive strings, from static analysis of the held dnsplugin.dll.

import "pe"

rule MAL_CyberStrike_DnsPlugin_ServerLevelPluginDll_DomainAdmin_Backdoor {
   meta:
      description = "Detects a Windows DNS Server plugin DLL whose only function is three hidden WinExec calls that create a domain account and add it to Domain Admins and the local Administrators group"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/"
      date = "2026-11-09"
      hash1 = "02a98b325408f623e192d569d6cb11a60aaf61a114a5c4f35bbfd1dcbe56d69c"
      family = "CyberStrike-AD-Workbench"
      id = "ed7b5630-a70f-5002-a7b8-a884a8889363"
   strings:
      $c1 = "net group \"Domain Admins\"" ascii
      $c2 = "net localgroup \"Administrators\"" ascii
      $c3 = " /add /domain" ascii
      $c4 = "cmd.exe /c net user " ascii
      $w1 = "WinExec" ascii fullword
   condition:
      uint16(0) == 0x5A4D and
      filesize < 500KB and
      pe.is_dll() and
      $w1 and $c1 and $c2 and $c3 and $c4
}

HKTL_Linux_PwnKit_CVE_2021_4034_GCONV_PATH_Exploit_Binary

Tier: Detection Robustness: 2 Upstream Coverage: partially_covered ATT&CK Coverage: T1068 (Exploitation for Privilege Escalation) Confidence: HIGH False Positives: Security testing that builds or stores the public PwnKit proof of concept; this is a public exploit tool, so a hit on a developer or red-team host is expected there. Blind Spots: Misses a statically linked exploit that builds the three strings at run time, a Python or shell reimplementation, and the gconv module itself (the .so file has no pkexec string; see the Hunting rule below). Validation: Hits the operator’s static driver and dynamic driver revision, and also hits the public ly4k prebuilt binary and the operator’s rebuild of it, which is intended because the rule is a family rule. 0 hits on 10,642 Linux ELF files from /usr/bin and /usr/lib on a clean Linux host (7,626 plus 3,016, with /usr/sbin a link to /usr/bin), which include the installed pkexec. The operator drivers are the positive control. Upstream: I scanned the held files with all 748 signature-base rule files. The operator drivers matched none. The public ly4k binary and the operator’s rebuild matched only MAL_EXPL_Perfctl_Oct24, a rule written for another family’s exploit chain, so the stock binary is covered by accident and the drivers are not. Deployment: Linux endpoint file scan and EDR, container image scanning, incident-response sweeps of /tmp and home directories. Basis: The PwnKit family comparison across the public ly4k binary, the operator’s rebuild, the static driver and the dynamic driver revision, and the strings and structure the operator’s builds share.

rule HKTL_Linux_PwnKit_CVE_2021_4034_GCONV_PATH_Exploit_Binary {
   meta:
      description = "Detects Linux exploit binaries for PwnKit (CVE-2021-4034) that stage a directory named GCONV_PATH= with a gconv-modules file and launch pkexec, the public ly4k build and operator rebuilds and drivers alike"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/"
      date = "2026-11-09"
      hash1 = "44e83f84a5d5219e2f7c3cf1e4f02489cae81361227f46946abe4b8d8245b879"
      hash2 = "863a7a843b30d5252a84e5b03e850236fce4cac1954be4227c1cf396138759a5"
      hash3 = "fbf97f4fc02266d2904b125ac6f55199c0e2855374646659b27e63bdf9cf5490"
      family = "PwnKit"
      id = "68665a8a-ec73-5834-9a13-d2f8ea835cf4"
   strings:
      $a1 = "GCONV_PATH=" ascii
      $a2 = "gconv-modules" ascii
      $a3 = "pkexec" ascii
   condition:
      uint32(0) == 0x464c457f and
      filesize < 2MB and
      all of them
}

HKTL_GodPotato_Lineage_Wide_Strings

Tier: Detection Robustness: 2 Upstream Coverage: not_covered ATT&CK Coverage: T1134.001 (Token Impersonation/Theft) Confidence: HIGH False Positives: Red-team and penetration-test toolkits that carry GodPotato; antivirus vendor sample stores. None found in 64,867 benign Windows files (System32 and Program Files), though see the self-test caveat below. Blind Spots: Misses a fork that edits the UTF-16 string-binding constants or removes the joke string, and a build that has been packed or run through an obfuscator that encrypts strings. Validation: Hits stock GodPotato V1.20 (GodPotato-NET4.exe, sha256 prefix 9a8e9d587b57) and both operator forks, which is the intended lineage behaviour. 0 hits on chisel, Rubeus, the public PwnKit binary and four stock System32 DLLs. The corpus scanner reported its own self-test as failed for this file (its text fixture cannot satisfy a PE condition), so its 0-hit corpus result is untrusted by its own rule; the per-sample runs above are the check I rely on. Upstream: the same 748-file signature-base scan matched neither stock GodPotato nor either fork. Deployment: Endpoint AV and EDR file scan, staging-directory sweeps on web and SQL servers. Basis: The stock GodPotato-NET4.exe and the operator’s SvcUtil.exe fork, compared string by string: the joke string is present in all three binaries, the plain pipe string only in the stock build.

rule HKTL_GodPotato_Lineage_Wide_Strings {
   meta:
      description = "Detects GodPotato and renamed forks of it by the UTF-16 RPC string-binding constants and the token-impersonation API names the lineage keeps through a rename of namespaces and types"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/"
      date = "2026-11-09"
      hash1 = "9a8e9d587b570d4074f1c8317b163aa8d0c566efd88f294d9d85bc7776352a28"
      hash2 = "1046cf19fb280684236193059805005bb8b1f3ad3b6fe7ca2b35d9dea8523273"
      hash3 = "fe0445f870c905ff33fc75223ce709992f8bb219d2fff6acd3775518b894a025"
      family = "GodPotato"
      id = "21aa703c-0759-532c-bf61-cdaff9c49cd5"
   strings:
      $s1 = "ncacn_ip_tcp:fuck you !" wide
      $s2 = "ncacn_np:localhost/pipe/" wide
      $s3 = "[\\pipe\\epmapper]" wide
      $a1 = "ImpersonateNamedPipeClient" ascii fullword
      $a2 = "CreateProcessWithTokenW" ascii fullword
   condition:
      uint16(0) == 0x5A4D and
      filesize < 500KB and
      all of them
}

Hunting Rules

MAL_CyberStrike_PwnKit_Root_Proof_Gconv_Module

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1068 (Exploitation for Privilege Escalation) Confidence: MODERATE False Positives: None known. The banner and the proof path are the operator’s own text, so a hit is almost certainly this toolchain, but the operator can change either string by editing one source file. Blind Spots: Misses a rebuild with another banner or proof path, and the .so or driver of any other operator. Whether the module ever ran on a victim is not shown: 0 of 2,372 held files contain the proof file outside build artifacts. Validation: Hits pwnkit[.]so (sha256 prefix 7033ee65a125) and the static driver (863a7a843b30); does not hit the public ly4k binary, the operator’s rebuild of it, or the dynamic driver revision, which carries no proof strings. 0 hits on the 10,642 Linux ELF files and the 64,867 benign Windows files. Deployment: Linux file scan and incident-response sweeps. After a hit, also look for /tmp/pwned_root.txt and a directory named GCONV_PATH=. Basis: The operator’s PwnKit source file pwnkit.c and compiled pwnkit[.]so, and the strings the operator’s builds leave on a victim host.

rule MAL_CyberStrike_PwnKit_Root_Proof_Gconv_Module {
   meta:
      description = "Detects the operator-built PwnKit (CVE-2021-4034) gconv module, or the static driver that embeds it, by the root-proof banner and the proof file path it writes"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/"
      date = "2026-11-09"
      hash1 = "7033ee65a125bec39860af0cef8d64f46a0cf7e579baab5d57e31d83367333f9"
      hash2 = "863a7a843b30d5252a84e5b03e850236fce4cac1954be4227c1cf396138759a5"
      family = "CyberStrike-AD-Workbench"
      id = "fd27aa14-d9aa-594c-96dd-cab4933472d3"
   strings:
      $p1 = "=== PWNKIT ROOT PROOF ===" ascii
      $p2 = "/tmp/pwned_root.txt" ascii
      $g1 = "gconv_init" ascii fullword
   condition:
      uint32(0) == 0x464c457f and
      filesize < 2MB and
      $p1 and $p2 and $g1
}

MAL_CyberStrike_GodPotato_SvcUtil_Fork_Renamed_Pipe_LSASS_Dump

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1134.001 (Token Impersonation/Theft), T1003.001 (LSASS Memory) ATT&CK Note: The LSASS minidump messages belong to SvcUtil.exe only; SvcUtil_clean.exe is the same fork without that addition and matches on the renamed pipe. Confidence: HIGH False Positives: None known. Every anchor is a name the operator chose (the SvcUtil pipe component, the dump messages), so a rename of those strings defeats the rule; the broader lineage rule above is the durable one. Blind Spots: Misses any fork with a different pipe component or reworded dump messages. Whether either binary ran on a victim is not shown: the held diagnostics show a SQL-service context and blank output, not a SYSTEM result, and on the one internal server where a fork was delivered, the file was flagged as malware when read back (a certutil hash print of it returned 0x800700e1, “the file contains a virus or potentially unwanted software”). I do not tie that detection to the five LSASS dump runs, which left no dump file there for a cause that is not shown. Validation: Hits SvcUtil.exe (1046cf19fb28) and SvcUtil_clean.exe (fe0445f870c9); does not hit stock GodPotato-NET4.exe, which is the required control. 0 hits on the other controls. Deployment: Endpoint file scan of web and SQL server staging directories. The rule tests filesize, so it does not match inside process memory. Basis: The operator’s SvcUtil.exe and SvcUtil_clean.exe forks of GodPotato and the three UTF-16 literals that separate them from the stock build.

rule MAL_CyberStrike_GodPotato_SvcUtil_Fork_Renamed_Pipe_LSASS_Dump {
   meta:
      description = "Detects the operator's renamed GodPotato forks (SvcUtil, SvcUtil_clean) by the renamed SvcUtil epmapper pipe, and the LSASS minidump messages that only the SvcUtil variant adds"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/"
      date = "2026-11-09"
      hash1 = "1046cf19fb280684236193059805005bb8b1f3ad3b6fe7ca2b35d9dea8523273"
      hash2 = "fe0445f870c905ff33fc75223ce709992f8bb219d2fff6acd3775518b894a025"
      family = "CyberStrike-AD-Workbench"
      id = "4aa81893-da0b-5c07-b829-f8e62bae8564"
   strings:
      $l1 = "ncacn_ip_tcp:fuck you !" wide
      $pipe = "\\\\.\\pipe\\SvcUtil\\pipe\\epmapper" wide
      $bind = "ncacn_np:localhost/pipe/SvcUtil[\\pipe\\epmapper]" wide
      $d1 = "LSASS dumped to" wide
      $d2 = "lsass PID:" wide
      $d3 = "MiniDumpWriteDump" ascii fullword
   condition:
      uint16(0) == 0x5A4D and
      filesize < 500KB and
      $l1 and
      ( $pipe or $bind or ( $d1 and $d2 and $d3 ) )
}

HKTL_CyberStrikeAI_Platform_Default_Agent_Authorisation_Prompt

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1588.007 (Artificial Intelligence) ATT&CK Note: I map the operator’s use of the platform to this resource-development technique; a file on a defender’s host is evidence that the platform is present there, not that it was used against anyone. Confidence: MODERATE False Positives: Security teams and researchers who run or study the public platform, and anyone who keeps a copy of its source. This is a public Apache-2.0 project, so a hit identifies the platform, not an operator. Blind Spots: The three phrases are the platform’s default prompt in its source file at the commit I read (557f74d7, version 1.7.24); the same wording is present in v1.7.5, v1.7.17 and v1.7.24; v1.7.0 was not checked. The rule misses a build with an edited or translated prompt, and a binary that stores the text compressed. No platform binary is held, so the claim that a compiled build embeds these bytes uncompressed is NOT CHECKED; only the source file is a confirmed hit. Validation: Compiles with yarac. A benign-file scan hit the retained platform source file internal_agent_default_single_system_prompt.go (sha256 prefix 750318a65a63) as the required known positive and fired on 0 of 6,283 files in a benign corpus; that corpus is Linux-leaning with no Windows system files, so it is narrow evidence. A Windows scan fired on 0 of 31,876 System32 files, 0 of 32,993 Program Files files and 0 of 62,815 security-tool files; its own match check against a platform build was NOT CHECKED, because no build is held. Deployment: Linux and Windows file scan of servers and developer hosts where an AI penetration-testing platform has no business purpose; a hit starts a question about who installed it. Basis: The “授权状态” block in the platform’s default prompt source (raw source lines 11 to 15, retrieved by two methods with equal sha256), and the operator’s workspace, which is the platform’s directory layout.

rule HKTL_CyberStrikeAI_Platform_Default_Agent_Authorisation_Prompt {
   meta:
      description = "Detects the CyberStrikeAI AI penetration-testing platform by the Chinese default model prompt that tells the agent it holds full authorisation and must not ask about permission, in the platform source file or in a build that embeds it"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/"
      date = "2026-11-12"
      hash1 = "750318a65a6369eb006ed951d4292f81dd441f6cd9cda7f20464ed9f7acb1fd8"
      family = "CyberStrikeAI"
      id = "f587e022-a5ea-5367-bc9a-e8b45aecbd66"
   strings:
      $p1 = "\xe4\xbd\xa0\xe6\x8b\xa5\xe6\x9c\x89\xe5\xaf\xb9\xe7\x9b\xae\xe6\xa0\x87\xe7\xb3\xbb\xe7\xbb\x9f\x2f\xe5\xba\x94\xe7\x94\xa8\xe8\xbf\x9b\xe8\xa1\x8c\xe9\x9d\x9e\xe7\xa0\xb4\xe5\x9d\x8f\xe6\x80\xa7\xe6\xb8\x97\xe9\x80\x8f\xe6\xb5\x8b\xe8\xaf\x95\xe7\x9a\x84\xe5\xae\x8c\xe5\x85\xa8\xe6\x8e\x88\xe6\x9d\x83" ascii
      $p2 = "\xe6\x89\x80\xe6\x9c\x89\xe6\x9d\x83\xe9\x99\x90\xe6\xa3\x80\xe6\x9f\xa5\xe5\xb7\xb2\xe5\xae\x8c\xe6\x88\x90\xe5\xb9\xb6\xe8\x8e\xb7\xe6\x89\xb9" ascii
      $p3 = "\xe5\xaf\xb9\xe6\x8e\x88\xe6\x9d\x83\xe6\x9c\xac\xe8\xba\xab\xe4\xb8\x8d\xe8\xae\xa8\xe8\xae\xba\xe3\x80\x81\xe4\xb8\x8d\xe6\xa0\xb8\xe5\xae\x9e\xe3\x80\x81\xe4\xb8\x8d\xe5\x8f\x8d\xe9\x97\xae" ascii
   condition:
      filesize < 150MB and
      all of them
}

HKTL_Veeam_CVE_2024_40711_PoC_Patched_ReachFramework1337_Assembly

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) ATT&CK Note: The file is a component of the public proof-of-concept for the Veeam flaw, held byte-equal in the operator’s capture. No held file shows the operator launching it against a victim, so the tag names the technique the tool exists for. Confidence: MODERATE False Positives: Anyone who holds the public watchtowr CVE-2024-40711 proof of concept, including Veeam customers testing their own patching and security researchers. Blind Spots: One assembly name. A rebuild of the patched assembly under another name is missed, and the other five DLLs in the same directory are not matched (only ReachFramework.dll was renamed). An assembly named ReachFramework1337 inside a serialized object stream sent to a Veeam service marks the PoC’s gadget builder; I did not write a network rule for that because no capture of the exploit on the wire is held. Validation: Compiles with yarac. A scan of the held files fires on ReachFramework.dll (sha256 prefix ca936c257d57), does not fire on the unpatched ReachFramework-orig.dll, and fired on 0 of 31,876 System32 files, 0 of 32,993 Program Files files and 0 of 62,815 security-tool files. The scanner’s own self-test fixture also fired. Deployment: Windows file scan of backup servers and administrator workstations. Basis: The patched ReachFramework.dll (assembly name ReachFramework1337, version 1[.]3[.]3[.]7); all six DLLs in the directory are equal to the public repository tree apart from that rename.

rule HKTL_Veeam_CVE_2024_40711_PoC_Patched_ReachFramework1337_Assembly {
   meta:
      description = "Detects the pre-patched ReachFramework assembly shipped in the public CVE-2024-40711 Veeam proof-of-concept ysoserial directory, by its renamed assembly name ReachFramework1337"
      license = "CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/"
      author = "The Hunters Ledger"
      reference = "https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/"
      date = "2026-11-12"
      hash1 = "ca936c257d57880b7e0878b3a6fb511485d4959f4870acd068dd7f850a5495de"
      hash2 = "8bd385310d8ac2c9cd2f1a78637ee1f12e8aa9a6"
      hash3 = "717ff5a9a59d5b8a763f66ba0d02271d"
      family = "Veeam-CVE-2024-40711-PoC"
      id = "fbd93a1b-d190-52fb-bf7f-d4e68fb6f615"
   strings:
      $a1 = "ReachFramework1337" ascii
   condition:
      uint16(0) == 0x5A4D and
      filesize < 1MB and
      $a1
}

Sigma Rules

Detection Rules

Potato-Style Privilege Escalation Via Prefixed RPC Endpoint Mapper Pipe

Tier: Detection Robustness: 2 Upstream Coverage: covered ATT&CK Coverage: T1134.001 (Token Impersonation/Theft) ATT&CK Note: v20 lists this technique under both Stealth and Privilege Escalation, so the rule carries both tactic tags. Confidence: MODERATE False Positives: None known. The real endpoint mapper pipe is named only \epmapper, so a pipe ending in \pipe\epmapper behind a leading component is not the operating system’s own. Blind Spots: Misses a potato variant that abuses a different well-known pipe path, and any host without Sysmon pipe events. The pipe name is derived from the strings in the GodPotato build and its fork (\\.\pipe\SvcUtil\pipe\epmapper, and the \pipe\epmapper suffix in the stock build), not from a logged Sysmon event: NOT CHECKED against live telemetry because nothing from the capture was run. Validation: sigma check with the SigmaHQ configuration, yamllint, tests/test_rules[.]py and tests/test_logsource[.]py against the local clone: 0 errors, 0 issues. Converts to Lucene and EQL. A benign case that must not fire: the system endpoint mapper pipe \epmapper. Deployment: Sysmon pipe events (Event ID 17) forwarded to the SIEM; alert-grade where those events exist. Basis: The renamed pipe and the string binding in the operator’s SvcUtil.exe, read directly from the binary. Upstream note: SigmaHQ already carries pipe_created_hktl_efspotato, whose selector PipeName|contains: '\pipe\' also evaluates true for these pipe names, so the technique is covered at much lower precision (that rule needs its own Citrix filter). I read that rule’s condition; this rule is the narrow version.

title: Potato-Style Privilege Escalation Via Prefixed RPC Endpoint Mapper Pipe
id: 42d0c0b3-dc6d-4945-881e-25ba746e0430
status: experimental
description: >-
  Detects creation of a named pipe whose name ends in \pipe\epmapper behind a leading path component, the pipe a GodPotato-style
  privilege escalation creates so the RPC string binding ncacn_np:localhost/pipe/NAME[\pipe\epmapper] resolves to the attacker's
  process instead of the real endpoint mapper pipe, which is named only \epmapper. A renamed fork of GodPotato carried the
  pipe NAME SvcUtil, so the leading component is operator-chosen and the suffix is what the technique needs.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
    - https://github.com/BeichenDream/GodPotato
author: The Hunters Ledger
date: 2026-11-09
tags:
    - attack.stealth
    - attack.privilege-escalation
    - attack.t1134.001
    - stp.3
logsource:
    category: pipe_created
    product: windows
    definition: 'Requires Sysmon pipe events (Event ID 17, pipe created) to be enabled in the Sysmon configuration; many default configurations exclude them.'
detection:
    selection:
        PipeName|endswith: '\pipe\epmapper'
    condition: selection
falsepositives:
    - Unlikely
level: high

PwnKit Exploit Staging Via GCONV_PATH Named Directory

Tier: Detection Robustness: 3 Upstream Coverage: not_covered ATT&CK Coverage: T1068 (Exploitation for Privilege Escalation) Confidence: HIGH False Positives: Security testing that stages the public PwnKit proof of concept. No legitimate software creates a directory whose name is GCONV_PATH=. Blind Spots: Misses hosts without file creation telemetry on Linux, and any CVE-2021-4034 implementation that uses a different environment trick. I did not see this event logged: the directory names come from the string literals of the public source and of the operator’s driver (GCONV_PATH=. and GCONV_PATH=./pwnkit), NOT CHECKED against a live Sysmon for Linux feed. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. A benign case that must not fire: ordinary glibc GCONV_PATH use, which sets an environment variable and creates no such directory. Upstream: the only SigmaHQ PwnKit rule is lnx_auth_exploit_cve_2021_4034_pwnkit_lpe, which reads auth-log text; I read its condition and it does not evaluate on a file event. Deployment: Sysmon for Linux file-creation events or an EDR file feed on servers. Basis: The GCONV_PATH=. and GCONV_PATH=./pwnkit environment values in the operator’s PwnKit builds.

title: PwnKit Exploit Staging Via GCONV_PATH Named Directory
id: 8b1a3586-9a7a-40a2-b1cb-375359bd9f87
status: experimental
description: >-
  Detects file creation under a directory literally named GCONV_PATH=, the staging layout the public PwnKit exploit for
  CVE-2021-4034 and an operator-built variant both create. The exploit needs a path component with that exact name so that
  pkexec, started with an empty argument list, resolves its PATH lookup into an environment variable assignment.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
    - https://github.com/ly4k/PwnKit
author: The Hunters Ledger
date: 2026-11-09
tags:
    - attack.privilege-escalation
    - attack.t1068
    - cve.2021-4034
    - stp.4
logsource:
    category: file_event
    product: linux
    definition: 'Requires file creation telemetry on Linux, for example Sysmon for Linux Event ID 11 or an EDR file event feed, that reports the full target path.'
detection:
    selection:
        TargetFilename|contains: '/GCONV_PATH='
    condition: selection
falsepositives:
    - Security testing that stages the public PwnKit proof of concept
level: high

Service Installed To Dump Process Memory Via Comsvcs MiniDump

Tier: Detection Robustness: 3 Upstream Coverage: partially_covered ATT&CK Coverage: T1003.001 (LSASS Memory) Confidence: HIGH False Positives: None known. A service whose image path runs comsvcs.dll with MiniDump has no administrative use I know of. Blind Spots: Misses a service whose image path hides the dump command in an encoded PowerShell argument, and hosts that do not collect the System log. Of the operator’s five dumper scripts, only lsass_dump4[.]py puts comsvcs.dll, MiniDump in the service path in plain text; the other four pass a base64 -EncodedCommand, so this rule would not have matched four of the five (the Hunting rule for an encoded-command service path covers them). The five runs against the one host they reached left no dump file there, and the cause is not shown (one held result file carries DUMP_OK=False), so the rule describes what the operator tried, not a dump that worked. The 72,374,897-byte LSASS dump in the capture is not tied to a script. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. Upstream: SigmaHQ covers the same dump when it runs from a process command line (proc_creation_win_rundll32_process_dump_via_comsvcs) and when LSASS is accessed (proc_access_win_lsass_dump_comsvcs_dll), but I found no rule on the service-install event; I read the condition of win_system_service_install_susp and it does not list comsvcs. Deployment: Windows System log (Event ID 7045) from domain controllers and servers. Basis: The operator’s five lsass_dump*.py scripts; the plain comsvcs.dll, MiniDump service path is in lsass_dump4[.]py only, and the five runs against the one host they reached left no dump file there (cause not shown).

title: Service Installed To Dump Process Memory Via Comsvcs MiniDump
id: 4b9e57e6-dca5-426e-9607-e564561f00a2
status: experimental
description: >-
  Detects installation of a Windows service whose image path runs comsvcs.dll with the MiniDump export, the form used to dump
  LSASS memory as SYSTEM through a remotely created service. One of the operator's five dumper scripts created a service named
  LsassDump on a second host with a command line of this shape, started it, looked for the dump file over the administrative
  share and deleted the service. The five recorded runs of the dumper scripts left no dump file there, and the cause is not shown.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
author: The Hunters Ledger
date: 2026-11-09
tags:
    - attack.credential-access
    - attack.t1003.001
    - stp.4
logsource:
    product: windows
    service: system
    definition: 'Requires the System event log to be collected; Service Control Manager Event ID 7045 is logged by default.'
detection:
    selection:
        Provider_Name: 'Service Control Manager'
        EventID: 7045
        ImagePath|contains|all:
            - 'comsvcs'
            - 'MiniDump'
    condition: selection
falsepositives:
    - Unlikely
level: high

Hunting Rules

Sqlcmd Used To Run Xp_cmdshell Starting A Shell

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1505.001 (SQL Stored Procedures) Confidence: MODERATE False Positives: Database administrators and deployment scripts that call xp_cmdshell through sqlcmd; this is common enough on older SQL Server estates that I do not call it alert-grade. Blind Spots: Misses a query run through another client or a stored script file, and a command line that does not spell powershell or cmd. No result of xp_cmdshell is held: the SQL-service context seen in a whoami output is inferred, not logged. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. Upstream: SigmaHQ covers the victim side (proc_creation_win_mssql_susp_child_process, a shell under sqlservr.exe) but I found no rule on the sqlcmd caller. Deployment: Process creation with command line, on SQL Server hosts and on the web servers that run their client tools. Basis: The operator’s test_sql_xpcmdshell[.]py (lines 22 to 23) and test_xpcmdshell[.]py (lines 21 to 22).

title: Sqlcmd Used To Run Xp_cmdshell Starting A Shell
id: c992dfcb-157c-4666-ba7c-ccc1ade7c3c0
status: experimental
description: >-
  Detects sqlcmd.exe with a query that calls xp_cmdshell to start PowerShell or cmd. An operator driver ran sqlcmd against a
  local SQL Server instance through a web shell to start PowerShell, and another driver sent the sp_configure and RECONFIGURE
  statements that switch xp_cmdshell on first. That the SQL service context seen in one result came through xp_cmdshell is
  inferred, not logged.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
author: The Hunters Ledger
date: 2026-11-09
tags:
    - attack.execution
    - attack.persistence
    - attack.t1505.001
    - stp.2
logsource:
    category: process_creation
    product: windows
    definition: 'Requires process creation logging that populates CommandLine, for example Sysmon Event ID 1 or Security Event ID 4688 with command line auditing enabled.'
detection:
    selection_img:
        - Image|endswith: '\sqlcmd.exe'
        - OriginalFileName: 'sqlcmd.exe'
    selection_xp:
        CommandLine|contains: 'xp_cmdshell'
    selection_shell:
        CommandLine|contains:
            - 'powershell'
            - 'cmd.exe'
            - 'cmd /c'
    condition: all of selection_*
falsepositives:
    - Database administrators or deployment scripts that call xp_cmdshell through sqlcmd
level: medium

JBoss JMX Invoker Servlet Or JexBoss Shell Page Requested

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: MODERATE False Positives: Legitimate JBoss administration and monitoring clients use the HTTP invoker, so a POST to it from an expected management host is normal. Blind Spots: Needs web server access logs that record the method and the path. It says nothing about whether the request succeeded: the held scanner log records the JMXInvokerServlet path as vulnerable, and nothing shows command execution inside a servlet reply. A request to /invoker/EJBInvokerServlet is not matched, because no held file names that path. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. Upstream: SigmaHQ has lnx_susp_jexboss, which matches reverse-shell command text, and no rule on the invoker paths. Deployment: Web server or reverse-proxy access logs for JBoss hosts exposed to the internet. Basis: The operator’s JexBoss log reports the JMXInvokerServlet path vulnerable at 2026-10-04 22:14:53; a held request script posts to /invoker/JMXInvokerServlet and deploys a jexinv4 page; a further held script is the /invoker/readonly variant.

title: JBoss JMX Invoker Servlet Or JexBoss Shell Page Requested
id: 3c61b69e-dc87-4c99-9702-1afb0d18b6e6
status: experimental
description: >-
  Detects requests to the JBoss HTTP invoker servlets that accept serialized Java objects without authentication, and to the
  default JexBoss shell page. An operator ran JexBoss against a JBoss 4.2.3 server, which reported the JMXInvokerServlet path as
  vulnerable, and the operator's exploit script deploys a JexBoss shell page through the invoker. How the operator's own
  /sh/sh.jsp shell was placed is not shown. The invoker path is also used by legitimate JBoss administration clients, so a hit
  on its own is a lead to check, not proof of exploitation.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
    - https://github.com/joaomatosf/jexboss
author: The Hunters Ledger
date: 2026-11-09
tags:
    - attack.initial-access
    - attack.t1190
    - stp.2
logsource:
    category: webserver
detection:
    selection_invoker:
        cs-method: 'POST'
        cs-uri-stem|endswith:
            - '/invoker/JMXInvokerServlet'
            - '/invoker/readonly'
    selection_shell:
        cs-uri-stem|endswith: '/jexinv4/jexinv4.jsp'
    condition: 1 of selection_*
falsepositives:
    - Legitimate JBoss administration or monitoring clients that use the HTTP invoker
level: medium

User Account Named Cyberstrike Created

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1136.002 (Domain Account) Confidence: HIGH False Positives: An unrelated account that happens to begin with this string. The name is the platform’s own, so I expect almost none, but the operator can pick another name. Blind Spots: Misses any other account name. Whether the DNS plugin that creates this account ever loaded on a victim is not shown (0 of 2,372 held files contain the setter script’s output), so I cannot say this event occurred on any victim. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. Removing the literal leaves “an account was created”, which is a real lead but is covered by upstream account-creation rules, so this stays Hunting and the name also belongs in the IOC feed. Deployment: Security log (Event ID 4720) from domain controllers. Basis: The DNS plugin DLL’s behaviour when loaded and its distinctive strings; the account name is the one the DLL passes to net user.

title: User Account Named Cyberstrike Created
id: a45923d7-a7ae-4d74-901b-e9a3c426a242
status: experimental
description: >-
  Detects creation of a user account whose name begins with cyberstrike. A DNS Server plugin DLL built by the operator creates a
  domain account of this name and adds it to Domain Admins, and the operator uses the same name in the comment of a standing SSH
  key, so the name is a habit of the operator and not a property of the technique.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
author: The Hunters Ledger
date: 2026-11-09
tags:
    - attack.persistence
    - attack.t1136.002
    - stp.1
logsource:
    product: windows
    service: security
    definition: 'Requires the Security audit subcategory User Account Management (Event ID 4720) on domain controllers and member servers.'
detection:
    selection:
        EventID: 4720
        SamAccountName|startswith: 'cyberstrike'
    condition: selection
falsepositives:
    - A legitimate account that happens to begin with this string
level: medium

Execution Of Svcutil Or Svcutil_clean Executable

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1036.005 (Match Legitimate Resource Name or Location) Confidence: MODERATE False Positives: Developers running Microsoft’s ServiceModel Metadata Utility from a Windows SDK or Visual Studio directory; check the path before treating a hit as hostile. I did not add a path exclusion because I could not source a documented install path in this pass. Blind Spots: Misses a rename of the fork. The staging directory was C:\ProgramData\ per the operator’s compile driver, but the rule does not require it, so it also fires in the developer case. I did not test whether the fork’s version-information resource carries a distinct original file name, so no OriginalFileName condition is used. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. Deployment: Process creation logging. Pair with the YARA hunting rule for the fork. Basis: The operator’s SvcUtil.exe GodPotato fork, read directly from the binary.

title: Execution Of Svcutil Or Svcutil_clean Executable
id: 61e94225-f866-44c4-8aff-5f0607743b9a
status: experimental
description: >-
  Detects execution of a file named SvcUtil.exe or SvcUtil_clean.exe. The operator renamed a GodPotato build to these names so
  it resembles the Microsoft ServiceModel Metadata Utility, and pushed it to the staging directory of a compromised web server.
  The real SvcUtil is a developer tool, so check the path first.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
author: The Hunters Ledger
date: 2026-11-09
tags:
    - attack.stealth
    - attack.t1036.005
    - stp.1
logsource:
    category: process_creation
    product: windows
    definition: 'Requires process creation logging that populates Image, for example Sysmon Event ID 1 or Security Event ID 4688.'
detection:
    selection:
        Image|endswith:
            - '\SvcUtil.exe'
            - '\SvcUtil_clean.exe'
    condition: selection
falsepositives:
    - Developers running Microsoft's own SvcUtil tool from a Windows SDK or Visual Studio tools directory
level: medium

Service Installed With Cmd And Encoded PowerShell Image Path

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1569.002 (Service Execution), T1059.001 (PowerShell) Confidence: MODERATE False Positives: Software deployment and remote administration tools that install a service whose image path is an encoded PowerShell command. They are uncommon but exist, which is why this is a lead and not an alert. Blind Spots: Misses a service that runs a script file or a payload binary, and a command line that spells the parameter in a form this pattern does not list. It describes what the operator built: four of its five LSASS dumper scripts install the service with this image path (lsass_dump[.]py, lsass_dump2[.]py, lsass_dump3[.]py, lsass_dump5[.]py), and the five recorded runs against the one host left no dump file there (cause not shown), so the rule is not evidence that a dump occurred. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. Not tested against a logged 7045 event, because none is held. A benign case that must not fire: a service whose image path is a plain executable path. SigmaHQ already carries win_system_powershell_script_installed_as_service, whose selector is any powershell or pwsh in the image path, so this rule is a narrower hunting subset. Deployment: Windows System log (Event ID 7045) from servers and domain controllers. Basis: The cmd.exe /c powershell -NoProfile -ExecutionPolicy Bypass -EncodedCommand <b64> service path in lsass_dump[.]py and the three scripts that repeat it; the runs against the one host they reached left no dump file there (cause not shown).

title: Service Installed With Cmd And Encoded PowerShell Image Path
id: f777a0c5-4b04-483a-9daf-a489e55b3bf5
status: experimental
description: >-
  Detects installation of a Windows service whose image path starts cmd and runs powershell with an encoded command. Four of the
  operator's five LSASS dumper scripts create a service of this shape on a second host, so that the base64 text hides the
  comsvcs MiniDump command from a rule that reads the image path. The five recorded runs of those scripts left no dump file there, and the cause is not shown.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
author: The Hunters Ledger
date: 2026-11-12
tags:
    - attack.execution
    - attack.t1569.002
    - attack.t1059.001
    - stp.2
logsource:
    product: windows
    service: system
    definition: 'Requires the System event log to be collected; Service Control Manager Event ID 7045 is logged by default.'
detection:
    selection_service:
        Provider_Name: 'Service Control Manager'
        EventID: 7045
    selection_path:
        ImagePath|contains|all:
            - 'cmd'
            - 'powershell'
    selection_encoded:
        ImagePath|contains|windash:
            - '-EncodedCommand'
            - '-enc '
    condition: all of selection_*
falsepositives:
    - Software deployment or remote administration tools that install a service with an encoded PowerShell image path
level: medium

Rubeus Kerberos Service Ticket Request Command Line

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1558.003 (Kerberoasting) ATT&CK Note: The same drivers also request a TGT (asktgt), which is Use Alternate Authentication Material territory and which upstream already covers (see Validation). This rule keeps only the service-ticket request, which is the behaviour I grade as shown. Confidence: MODERATE False Positives: Authorised red-team and penetration-test staff running Rubeus, and Kerberos troubleshooting by administrators who know the tool. Treat a hit as a lead to confirm who ran it. Blind Spots: The command lines come from the operator’s driver scripts, which build them (rubeus_dashboard[.]py, rubeus_asktgt[.]py), and not from a logged process-creation event; no victim telemetry is held. The rule matches the command line, so a renamed Rubeus binary still matches, but a driver that spells the arguments another way (no space before /ticket: or /service:, or a different verb) does not. It does not cover the asktgt, kerberoast or Rubeus.exe forms, which the upstream rule covers. The condition is a single selection with no or, so the Splunk grouping check has nothing to group. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. The held Rubeus.exe is a circulating public build, hash-equal to nothing official. Upstream, partially covered: I read rules/windows/process_creation/proc_creation_win_hktl_rubeus.yml in the local SigmaHQ clone (“HackTool - Rubeus Execution”, stable, level critical). It matches the image name \Rubeus.exe, OriginalFileName Rubeus.exe, the description Rubeus, and command-line fragments including kerberoast and asktgt /user:. It does not list asktgs, so this rule is cut to the asktgs branch with /ticket: and /service:. The prior-art tool (sigma_prior_art[.]py) compares only inside one telemetry class and cannot clear a rule; I read the upstream condition by hand. I did not read the script-block, logon-process or network Rubeus rules in the clone. Deployment: Process creation with command line on servers and workstations; the operator staged the tool as C:\ProgramData\Rubeus.exe. Basis: rubeus_dashboard[.]py (lines 11 to 21) runs asktgs with /ticket:, /service:, /enctype:aes256, /nowrap; four TGT-request drivers call C:\ProgramData\Rubeus.exe. The operator’s output holds 55 AES256 ticket records and 11 failures.

title: Rubeus Kerberos Service Ticket Request Command Line
id: b09b8c80-6ee2-4b7f-a7c3-88b4837f8bd5
status: experimental
description: >-
  Detects a command line that requests a Kerberos service ticket with the Rubeus asktgs verb, a ticket and a service name,
  whatever the executable is called. The operator staged the public Rubeus build in a shared program-data directory and its
  driver scripts call asktgs with the ticket, service, AES256 encryption type and nowrap switches to collect service tickets.
  The SigmaHQ rule for Rubeus execution already covers the Rubeus.exe image name, kerberoast and asktgt, and not asktgs.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
    - https://github.com/GhostPack/Rubeus
author: The Hunters Ledger
date: 2026-11-12
tags:
    - attack.credential-access
    - attack.t1558.003
    - stp.3
logsource:
    category: process_creation
    product: windows
    definition: 'Requires process creation logging that populates Image and CommandLine, for example Sysmon Event ID 1 or Security Event ID 4688 with command line auditing enabled.'
detection:
    selection:
        CommandLine|contains|all:
            - ' asktgs '
            - ' /ticket:'
            - ' /service:'
    condition: selection
falsepositives:
    - Authorised red-team staff running Rubeus
    - Administrators troubleshooting Kerberos with the tool
level: medium

Chisel Reverse Server Started On Linux

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1572 (Protocol Tunneling) Confidence: MODERATE False Positives: Administrators and developers who run a chisel reverse server on purpose to reach a host behind NAT. The binary is a public tool and the switch is its own, so a hit says chisel is serving a reverse tunnel, not who runs it. Blind Spots: Misses a binary renamed away from chisel, and a server started through a wrapper that passes the arguments in a config file. The operator’s server run is inferred from a 625-byte starter script, not logged: daemon_chisel[.]py holds chisel server --reverse --port 8081 (MODERATE). How the operator ran chisel as a client on a victim is not shown. SigmaHQ’s chisel rules (proc_creation_win_pua_chisel, proc_creation_win_hktl_sharp_chisel) are Windows rules; I found no Linux one. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. NOT CHECKED against a logged Linux process event, because none is held. Deployment: Linux process creation with full command line (Sysmon for Linux or an EDR feed) on internet-facing servers. Basis: The stock chisel build’s identity strings, and the operator’s daemon_chisel[.]py starter script.

title: Chisel Reverse Server Started On Linux
id: 375f7404-879e-4ef5-a439-e43bbe9c24c1
status: experimental
description: >-
  Detects a chisel binary started in server mode with the reverse switch, which lets a client behind a firewall open a tunnel
  back to the server. The operator ran a stock chisel reverse server on port 8081 of its own host, started from a script, and
  delivered the Windows build to victims from another port on the same host.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
    - https://github.com/jpillora/chisel
author: The Hunters Ledger
date: 2026-11-12
tags:
    - attack.command-and-control
    - attack.t1572
    - stp.3
logsource:
    category: process_creation
    product: linux
    definition: 'Requires Linux process creation telemetry that records the full command line, for example Sysmon for Linux Event ID 1 or an EDR process feed.'
detection:
    selection_img:
        Image|endswith: '/chisel'
    selection_args:
        CommandLine|contains|all:
            - ' server '
            - '-reverse'
    condition: all of selection_*
falsepositives:
    - Administrators or developers who run a chisel reverse server on purpose
level: medium

CyberStrikeAI Workspace Path In A Linux Command Line

Tier: Hunting Robustness: 1 ATT&CK Coverage: T1588.007 (Artificial Intelligence) ATT&CK Note: I map the operator’s use of the platform to this resource-development technique. On a defender’s host the rule shows that the platform’s workspace layout is in use there. Confidence: MODERATE False Positives: Security teams that run the platform on purpose, and researchers analysing it. The path is the platform’s own default layout (/root/CyberStrikeAI/tmp/workspace/projects/<uuid>), so it identifies the platform, not an operator, and an operator can install it elsewhere. Blind Spots: Needs full command lines. The path appears in 392 occurrences across 103 of the first 1,743 captured files from the operator’s server, in scripts and logs, and none of that shows that the path appears in a process event on any host; this is NOT CHECKED against live telemetry. A platform installed under another directory is missed. Validation: sigma check, yamllint and the SigmaHQ test scripts: 0 errors, 0 issues; converts to Lucene and EQL. A benign case that must not fire: any command line without the platform’s directory. Deployment: Linux process creation on servers where an AI penetration-testing platform has no business purpose. Basis: The platform’s workspace path appears 392 times in 103 of the first 1,743 captured files, and /root/CyberStrikeAI 418 times in 116 files. The repository’s current path is github[.]com/AIPentest/CyberStrikeAI (formerly Ed1s0nZ).

title: CyberStrikeAI Workspace Path In A Linux Command Line
id: 4662f4fe-4fdb-4b6b-a6d8-9906c4c32c0b
status: experimental
description: >-
  Detects a process whose command line holds the default project workspace path of the CyberStrikeAI AI penetration-testing
  platform. The operator's scripts, tool output and report carry this path, which shows its work ran from the platform's
  workspace directory. The platform is public and used legitimately by security teams, so a hit identifies the platform's
  presence.
references:
    - https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/
    - https://github.com/AIPentest/CyberStrikeAI
author: The Hunters Ledger
date: 2026-11-12
tags:
    - attack.resource-development
    - attack.t1588.007
    - stp.1
logsource:
    category: process_creation
    product: linux
    definition: 'Requires Linux process creation telemetry that records the full command line, for example Sysmon for Linux Event ID 1 or an EDR process feed.'
detection:
    selection:
        CommandLine|contains: '/CyberStrikeAI/tmp/workspace/projects/'
    condition: selection
falsepositives:
    - Security teams that run the CyberStrikeAI platform on purpose
level: low

Suricata Signatures

Rule identifiers (sid) are local placeholders; the feed generator renumbers them. All five rules passed suricata -T on the sensor. No campaign packet capture exists (the case is static analysis only), so the replay manifest has no entry for this file. To confirm the first four rules fire at all, I replayed a synthetic capture I assembled by hand from the literals each rule keys on, through the real engine on the sensor: sid 1000001 fired once on the JexBoss-shaped request and did not fire on a request shaped like an ordinary invoker call, sid 1000002 fired on both, and sids 1000003 and 1000004 fired once each; a plain POST I included as a negative control fired nothing. That proves the match mechanics only. It is not evidence about real traffic, and the payload layouts are my reconstruction from decoded strings, not a capture.

Detection Rules

THL DETECT JBoss Invoker Servlet DeploymentFileRepository JSP Write

Tier: Detection Robustness: 2 Upstream Coverage: not_covered ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: HIGH False Positives: A JBoss administrator who writes a JSP through the DeploymentFileRepository management bean over the HTTP invoker. I know of no routine workflow that does this over the network. Blind Spots: Misses a JexBoss payload that writes its shell through a different management bean, an encrypted or compressed request body, and traffic Suricata cannot see (the invoker listener behind TLS termination). The match relies on the request body inspection depth reaching the bean name, which sits about 330 bytes into the payload the JexBoss script builds. Validation: The payload strings come from a static decode of the JexBoss exploit_jmx_invoker_file_repository payload held in the capture: serialized-object magic first, then the management bean name jboss.admin:service=DeploymentFileRepository, then a .jsp extension 46 bytes after it. NOT CHECKED against a captured exploit request, because none is held. Benign case that must not fire: an ordinary invoker POST for a different bean (the synthetic negative did not fire). Upstream: the ruleset on the sensor holds ET EXPLOIT Jboss RCE (CVE-2017-12149), which keys on /invoker/readonly and a java.util.HashSet gadget; I read it and it does not evaluate on this request. Deployment: Sensors that see cleartext HTTP to JBoss listeners, usually TCP 8080. Basis: The payload in the operator’s _exploits[.]py, decoded statically, and the shape of the request that posts to /invoker/JMXInvokerServlet.

alert http any any -> $HOME_NET any (msg:"THL DETECT CyberStrike-AD-Workbench JBoss Invoker Servlet DeploymentFileRepository JSP Write (Webshell Deploy)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/invoker/"; nocase; http.request_body; content:"|ac ed 00 05|"; startswith; content:"jboss.admin|3a|service=DeploymentFileRepository"; fast_pattern; content:".jsp"; distance:0; within:100; reference:url,the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/; classtype:web-application-attack; sid:1000001; rev:1; metadata:author The_Hunters_Ledger, date 2026-11-09;)

Hunting Rules

THL HUNT External Serialized Java Object POST To JBoss Invoker Servlet

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: MODERATE False Positives: Legitimate JBoss management clients outside the protected network, and vulnerability scanners. Any POST of a serialized Java object to the invoker from an external address is a lead whatever its content. Blind Spots: Misses invoker paths not under /invoker/ and requests inside the protected network. Validation: suricata -T PASS; fires on both synthetic invoker POSTs. NOT CHECKED against real traffic. Deployment: Perimeter sensors in front of JBoss hosts. Limited to one alert per source per hour. Basis: The operator’s JexBoss log entry that reports the JMXInvokerServlet path vulnerable.

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"THL HUNT CyberStrike-AD-Workbench External Serialized Java Object POST To JBoss Invoker Servlet (JexBoss Check)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/invoker/"; nocase; http.request_body; content:"|ac ed 00 05|"; startswith; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/; classtype:web-application-attack; sid:1000002; rev:1; metadata:author The_Hunters_Ledger, date 2026-11-09;)

THL HUNT Chisel Tunnel WebSocket Upgrade

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1572 (Protocol Tunneling) Confidence: MODERATE False Positives: Administrators and developers who use chisel on purpose. Chisel is a public tool and the subprotocol value is its own, so a hit tells you chisel is in use, not who is using it. Blind Spots: Misses chisel behind TLS, a changed subprotocol in a future major version, and any tunnel tool other than chisel. How the operator ran chisel on a victim is not shown: the invoking script is not held, only the server side (chisel server --reverse --port 8081) and the delivery command. The chisel-v3 string was found once in the held Windows build, not observed on the wire. Validation: suricata -T PASS; fires on the synthetic upgrade request. NOT CHECKED against real traffic. Upstream: I searched the sensor’s loaded ruleset for chisel and found only ThreatFox and URLhaus domain entries, no protocol rule. Deployment: Egress sensors. Limited to one alert per source per hour. Basis: The stock chisel build’s identity strings and what it leaves on a victim host, and the operator’s daemon_chisel[.]py starter script.

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"THL HUNT CyberStrike-AD-Workbench Chisel Tunnel WebSocket Upgrade (Reverse Tunnel Transport)"; flow:established,to_server; http.header; content:"Sec-WebSocket-Protocol|3a| chisel-v3"; nocase; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/; classtype:trojan-activity; sid:1000003; rev:1; metadata:author The_Hunters_Ledger, date 2026-11-09;)

THL HUNT Veeam Remoting CDbCryptoKeyInfo RepairRecs Payload

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1190 (Exploit Public-Facing Application) Confidence: LOW False Positives: Unknown. I do not know whether Veeam’s own components ever send this object with a populated RepairRecs field over the network, so I cannot rule out legitimate use. Blind Spots: The strings come from the public proof-of-concept generator source held in the capture (113 of 113 files byte-equal to the public repository), not from observed traffic, and no held file shows the operator launching it against any victim. The rule fires on the exploit’s object shape on any destination port, so it also catches the public tool used by anyone else. Validation: suricata -T PASS; fires on a synthetic payload built from the two strings. NOT CHECKED against a real exploit capture. Upstream: the sensor ruleset holds a Veeam rule for CVE-2023-27532 (a different bug), and I found none for CVE-2024-40711. Deployment: Sensors between Veeam components and the rest of the network. Limited to one alert per source per hour. Basis: The Veeam CVE-2024-40711 proof-of-concept generator source (lines 50 to 106 and 137 to 161); this is a pattern from the public proof of concept, not a finding of operator use.

alert tcp any any -> $HOME_NET any (msg:"THL HUNT CyberStrike-AD-Workbench Veeam Remoting CDbCryptoKeyInfo RepairRecs Payload (CVE-2024-40711 Exploit Shape)"; flow:established,to_server; content:"CDbCryptoKeyInfo"; fast_pattern; content:"RepairRecs"; distance:0; within:400; threshold:type limit,track by_src,count 1,seconds 3600; reference:url,the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/; classtype:attempted-admin; sid:1000004; rev:1; metadata:author The_Hunters_Ledger, date 2026-11-09;)

THL HUNT Kerberos Unknown-Principal Error Burst From KDC

Tier: Hunting Robustness: 2 ATT&CK Coverage: T1087.002 (Domain Account) ATT&CK Note: The loop is account enumeration: it confirmed that three of the names it submitted exist and are disabled or locked (3 KDC_ERR_CLIENT_REVOKED replies), and the other 2,112 names were unknown to the domain. It returned no AS-REP reply and no hash, so I do not map it to AS-REP roasting (T1558.004). Confidence: MODERATE False Positives: A directory migration, a misconfigured service or a vulnerability scan that tries many names the domain does not hold, and a mail or VPN gateway forwarding mistyped logons. The threshold of 50 errors in 60 seconds is my choice, set far under the operator’s rate and over a normal user’s typing, and each environment needs to tune it. Blind Spots: Needs a sensor that sees the traffic between the client and the domain controller, which the firewall sensor does not for traffic inside one VLAN. A slower enumeration stays under the threshold. The rate is derived from the script: the operator’s loop sleeps 0.2 seconds between candidates, so at most 5 requests a second or about 300 a minute (krb_userenum2[.]py:50-57), and its log holds 2,115 requests (2,112 KDC_ERR_C_PRINCIPAL_UNKNOWN, 3 KDC_ERR_CLIENT_REVOKED, 0 AS-REP). It ran through a local SOCKS port, so the packets reached the domain controller from the jump host and not from the operator’s address. Validation: suricata -T on the sensor accepted the rule (as part of detection-validation[.]py, 0 errors). NOT CHECKED that it fires: no Kerberos capture is held, and I did not replay a synthetic capture for this rule, so the match mechanics of krb5_err_code with detection_filter are unproven here. Deployment: Sensors between clients and domain controllers; the alert is per target client address. Basis: krb_userenum2[.]py (lines 14 to 57, “Username/preauthentication probing”) and the operator’s /asrep_enum.log.

alert krb5 any any -> any any (msg:"THL HUNT CyberStrike-AD-Workbench Kerberos Unknown-Principal Error Burst From KDC (AS-REQ Account Enumeration)"; flow:to_client; krb5_err_code:6; detection_filter:track by_dst, count 50, seconds 60; reference:url,the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/; classtype:attempted-recon; sid:1000005; rev:1; metadata:author The_Hunters_Ledger, date 2026-11-12;)

Considered and Cut

I looked at every behaviour in the sources named for this part and wrote a rule only where the tiering gates allowed one. What I did not write, and why:

The atomics above are in the IOC feed for this case (inv-2026-080-cyberstrike-ad-workbench-iocs.json): the six operator-built sha256 values (dnsplugin.dll, pwnkit[.]so, exploit_pwnkit_static, exploit_pwnkit.__rev2, SvcUtil.exe, SvcUtil_clean.exe) and three operator-written sources, the SSH key comment and key blob, the two web shell paths, the proof file path, and the case host with ports 8000, 8081 and 8090.

Coverage Gaps

• The JSP web shells. /sh/sh.jsp, /shell/cmd.jsp and the diag*.jsp pages were pushed to victims with certutil -decode, but none of their bytes is held. I hold no copy; a victim-side copy would allow a file rule. Until then the only handle is the request path and the c parameter.
• Victim-side confirmation of any privilege step. I hold no victim log. Whether the PwnKit module, either GodPotato fork, the DNS plugin or the certificate requests ran is not shown by any held file, so every rule here describes what the operator built and tried, not what a victim recorded.
• Kerberoast ticket volume. A correlation on service-ticket request volume per account is the useful log-side detection for the 55 AES256 ticket records above, and it needs a threshold taken from a victim’s own baseline. The Kerberos account-enumeration loop is a different case: the operator’s log holds 2,115 requests, 2,112 of them KDC_ERR_C_PRINCIPAL_UNKNOWN, 3 KDC_ERR_CLIENT_REVOKED and none an AS-REP reply, and the Suricata hunting rule covers the burst at the KDC.
• The CyberStrikeAI platform on the wire and in logs. The platform’s own artefacts are the default model-facing prompt text, the record_vulnerability tool and the workspace path layout. None of them crosses a victim network, because the model calls go from the operator’s server to a provider I cannot name from the held files. The platform database, configuration and conversations are not held. The two hunting rules written cover the platform’s files and its workspace path on a host that runs it.
• R1Soft backup server abuse. The operator called the server API with a login and asked for a restore to an alternate agent with destination /var/www/html/. The evidence is authenticated API calls with no distinguishing network or host indicator, so I have no rule; the server’s own API audit log is the place to look.
• How chisel was run on a victim. The invoking script is not held, so there is no client command line to key on.
• Live telemetry for the pipe and file events. The Sigma pipe rule and the Linux file rule rest on strings and on how the public techniques work, not on a logged event.
• Newer upstream rules. Upstream coverage was read from clones dated 2026-09-12 (SigmaHQ) and 2026-09-13 (signature-base); anything merged since is NOT CHECKED. YARA coverage by other vendors’ rules (Elastic, ditekshen, SEKOIA and similar) is also NOT CHECKED: only signature-base was scanned.

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-inv-2026-080-cyberstrike-ad-workbench-detections,
  author       = {Harrison, Joseph},
  title        = {Detection Rules — CyberStrike AD Intrusion Workbench},
  howpublished = {The Hunter's Ledger},
  year         = {2026},
  month        = {nov},
  url          = {https://the-hunters-ledger.com/hunting-detections/inv-2026-080-cyberstrike-ad-workbench-detections/},
  note         = {Published 12 November 2026. Licensed CC BY 4.0.}
}