CyberStrike AI - Detection for Defenders: Scripting, Tempo and Residue

CyberStrike is an open-source AI agent for offensive security. It pairs any large language model with more than 56 built-in tools, including a Windows post-exploitation module of roughly 40,000 lines. This article reads its source code the way a defender would: how it executes on Windows, how fast it moves, and what it leaves behind. The result is a set of detection signatures for SOC analysts, detection engineers and DFIR teams, whether the operator is an authorised red team or an adversary who has repurposed the tool. The analysis covers commit a5ed1e0 (package version 1.1.16, 2 November 2026). Defaults may change in later releases.

1. What CyberStrike is

CyberStrike is an autonomous penetration-testing agent written in TypeScript, compiled with Bun and released under AGPL-3.0. Its architecture descends from an open-source AI coding agent: a terminal UI and local server drive an LLM, and the LLM calls tools. The project describes itself as "the first open-source AI agent built for offensive security" and states that it is for authorised testing only. Defenders should still expect to meet it from both red teams and criminals, because it is a free, one-command install (npm i -g @cyberstrike-io/cyberstrike, plus Homebrew, Scoop and a curl installer).

The components that matter for detection:

The winhook module is the core of this analysis. Its 16 source files total about 40,000 lines, and every Windows action it takes passes through one small set of execution wrappers. That design choice is what makes the tool detectable.

2. Execution model and scripting

Every winhook action ends in one function, run(), which calls Bun.spawn with a fresh child process and pipes back stdout, stderr and the exit code. There is no persistent shell and no in-process PowerShell runspace. Each action becomes one or more short-lived children of cyberstrike.exe. When the tool is installed through npm, a small node launcher starts the platform binary first. That parent–child chain is the first anchor for detection.

CyberStrike winhook execution chain · launch, capability probe, five wrappers

The whole Windows module funnels through these five wrappers, so a handful of command-line patterns covers every technique it implements.

2.1 The capability probe

The first time winhook runs, detectEnv() fingerprints the host and caches the result. It launches five processes back to back:

• powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command with a script that reads $PSVersionTable, the language mode, Get-ExecutionPolicy, administrator membership and the OS build, checks for System.Management.Automation.AmsiUtils, and prints the result with ConvertTo-Json -Compress;
• pwsh.exe --version;
• wmic.exe os get caption /format:list;
• cscript.exe //nologo //?;
• where.exe mshta.exe.

The tool then picks an execution method. It prefers PowerShell. If Constrained Language Mode is active it falls back to cmd.exe, or to WMIC when WMIC is available. This is an explicit, coded version of the "fallback chain" behaviour seen in AI-driven intrusions. No administrator runs exactly this sequence.

2.2 The execution wrappers and stealth modes

Two properties hold across every wrapper. The argument order is fixed in code, so a rule can match it exactly. And the scripts are generated per action from templates the agent fills in, so the bodies vary while the wrappers and default names do not. Section 6 builds on that split.

3. Speed and tempo

CyberStrike has two clocks. Inside an action, code runs at machine speed with no deliberate delays. Between actions, the pace is set by the LLM, because each tool call waits for the model to read the last result and choose the next step. The source code does not fix that second clock, so the cadence depends on the model and provider. Measure it in a lab against your own telemetry rather than assuming a number.

What the code does fix:

The pattern for defenders is a pulse: a burst of machine-speed children or HTTP requests, a pause while the model reasons, then the next burst. A human operator does not produce bursts this regular, and a fixed script does not pause to reason. The pulse appears on Windows hosts (process creation) and in web logs (request timing) alike.

4. Behavioural patterns defenders see

4.1 Web and API traffic

The web tooling leaves the most deterministic traces, because its payloads are fixed constants in the code:

• SSTI probe. The expression 7919*6841 is sent inside nine template syntaxes ({{ }}, ${ }, #{ }, <%= %>, @( ), %{ }, *{ }, [[${ }]], {{= }}), plus {{ 7919191|add:6841 }} and {% set _p=7919*6841 %}{{_p}}. A response containing 54173879 or 7926032 means the template engine evaluated it.
• Command-injection probe. The read-only commands id, i''d, i\d, ver and v^er are sent behind ten separators: ;, |, &&, ||, &, $( ), backticks, newline, '; and ";.
• XSS probe. Each payload carries a nonce of m plus ten hex characters, for example <svg onload=alert(m3f9a0c21be)>. The same nonce repeats across one battery.
• Web fetch. Requests use a fixed Chrome 143 Windows User-Agent with Accept-Language: en-US,en;q=0.9, but come from Bun's TLS stack. The code itself notes the resulting TLS-fingerprint mismatch. When Cloudflare answers with a challenge, the tool retries with the literal User-Agent cyberstrike.
• Proxy fan-out. In HackBrowser sessions, each real request is followed by parallel variants from eight sub-testers: swapped tokens between roles (IDOR and authorisation bypass), added fields such as role, price or balance (mass assignment), and injected parameters.

4.2 LLM and control-plane egress

When CyberStrike runs inside your network (an insider, a compromised host, or an unannounced test), its model traffic carries identifiers. Requests to most providers set User-Agent: cyberstrike/<version>. Requests to the project's own provider add x-cyberstrike-project, x-cyberstrike-session, x-cyberstrike-request and x-cyberstrike-client headers. A TLS-inspecting proxy sees all of these. The local server listens on port 4096 by default, and the README documents exposing it through cloudflared.

4.3 Windows host and Active Directory

The winhook catalogue maps onto familiar ATT&CK techniques. What distinguishes CyberStrike is how quickly and adaptively it moves between them, and the default names it uses:

5. Residuals

5.1 On the host where CyberStrike runs

If the agent itself was installed on a Windows machine in your estate, it leaves a clear footprint. Its path handling uses XDG directories under the user profile:

• %USERPROFILE%\.local\share\cyberstrike\ (with bin\ and log\), plus .config\cyberstrike, .cache\cyberstrike (holding a version file) and .local\state\cyberstrike. The data directory holds the session store, which may contain the operator's full conversation with the model. Preserve it first.
• Per-project .cyberstrike\ folders in the working directory.
• The npm packages @cyberstrike-io/cyberstrike and @cyberstrike-io/cyberstrike-windows-x64 under %APPDATA%\npm\node_modules, holding cyberstrike.exe.
• Prefetch CYBERSTRIKE.EXE-*.pf, and AmCache and ShimCache entries for cyberstrike.exe.
• A listener on TCP 4096, and possibly cloudflared.exe.
• Provider API keys in configuration or environment variables.

5.2 On target hosts: default names

Most winhook techniques accept a --name option, but the defaults are hard-coded. Operators in a hurry, and AI agents that do not think to change them, leave these behind:

5.3 What survives the cleanup routine

The built-in cleanup action targets these artefacts directly; the steps below are from its cmd.exe branch. Knowing what it does tells you what survives:

• It clears five logs with wevtutil cl: Security, System, Application, Windows PowerShell and Microsoft-Windows-PowerShell/Operational. That writes event 1102 to the new Security log and event 104 to System, and the code even prints a note saying so.
• It deletes scheduled tasks whose names match cs- or cyberstrike, files matching %TEMP%\cs-*, C:\Windows\Temp\cs-* and %TEMP%\cyberstrike-*, and Prefetch entries matching *CYBERSTRIKE* and *CS-*.
• It removes firewall rules named cs-* or CyberStrike* and runs netsh interface portproxy reset.

What it does not touch: Sysmon, TaskScheduler/Operational, WMI-Activity, Windows Defender/Operational and DNS-Client logs; anything already forwarded to a SIEM; the $MFT and $UsnJrnl, which record the deletions themselves; AmCache and ShimCache; and, in cmd mode, Defender exclusions, which the code admits need PowerShell to remove. The cleanup also misses files whose names use the underscore prefix (cs_bypass_, cs_task_, cs_decoded_) and the CyberStrike* registry persistence. Log forwarding is the decisive control: once events have left the host, clearing them only adds evidence.

6. Detection content

The signatures fall into three tiers. Tier 1 uses hard-coded strings and names, which give near-zero false positives until an operator changes them. Tier 2 uses fixed wrapper structure, which survives renamed artefacts. Tier 3 uses tempo and behaviour, which survives code changes. Deploy all three.

The capability-probe correlation is the strongest Tier 3 rule, because the sequence is hard-coded and has no administrative equivalent:

title: CyberStrike winhook Capability Probe Component (Base) name: cyberstrike_capability_probe_base status: experimental logsource: {category: process_creation, product: windows} detection: sel_ps: Image|endswith: '\powershell.exe' CommandLine|contains|all: ['LanguageMode', 'AmsiUtils', 'ConvertTo-Json -Compress'] sel_pwsh: Image|endswith: '\pwsh.exe' CommandLine|endswith: ' --version' sel_wmic: Image|endswith: '\wmic.exe' CommandLine|contains: 'os get caption /format:list' sel_cscript: Image|endswith: '\cscript.exe' CommandLine|contains: '//nologo //?' sel_where: Image|endswith: '\where.exe' CommandLine|contains: 'mshta.exe' condition: 1 of sel_* level: informational --- title: CyberStrike winhook Capability Probe Burst status: experimental correlation: type: value_count rules: [cyberstrike_capability_probe_base] group-by: [Computer, ParentProcessGuid] timespan: 60s condition: {field: Image, gte: 4} level: high

At the network edge, the probe markers are fixed constants:

alert http any any -> $HOME_NET any (msg:"CyberStrike inject_probe SSTI marker in URI"; flow:established,to_server; http.uri; content:"7919*6841"; fast_pattern; classtype:web-application-attack; sid:9100001; rev:1;) alert http $HOME_NET any -> any any (msg:"CyberStrike SSTI probe evaluated (product in response)"; flow:established,to_client; http.response_body; content:"54173879"; classtype:web-application-attack; sid:9100004; rev:1;) alert http any any -> $HOME_NET any (msg:"CyberStrike fallback User-Agent"; flow:established,to_server; http.user_agent; content:"cyberstrike"; startswith; nocase; classtype:web-application-activity; sid:9100005; rev:1;)

For Microsoft Defender XDR, one hunt covers both the parent process and the probe:

DeviceProcessEvents | where Timestamp > ago(7d) | where InitiatingProcessFileName =~ "cyberstrike.exe" or (FileName =~ "powershell.exe" and ProcessCommandLine has_all ("LanguageMode", "AmsiUtils", "ConvertTo-Json -Compress")) or (FileName =~ "wmic.exe" and ProcessCommandLine has "os get caption /format:list") or (FileName =~ "cscript.exe" and ProcessCommandLine has "//nologo //?") or ProcessCommandLine has "-NoProfile -NonInteractive -ExecutionPolicy Bypass -WindowStyle Hidden -EncodedCommand" | summarize events = count(), tools = make_set(FileName, 20), first = min(Timestamp), last = max(Timestamp), sample = make_set(ProcessCommandLine, 10) by DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessId | order by events desc

The full set of seven Sigma rules was validated with pySigma, and the two YARA rules with yara-python against samples built from the tool's own templates. The Suricata rules and the KQL hunt have not been tested against live traffic or telemetry. Run everything in hunt mode first.

7. Response playbook

When any Tier 1 or Tier 2 signature fires, treat it as hands-on-keyboard activity running at machine speed. The steps below assume the first alert fired on a Windows host.

• Check authorisation first. CyberStrike is a legitimate testing tool. Confirm with the red team or test manager, against the engagement's scope and source IPs, whether a test is running. If nobody claims it within minutes, proceed as for a live intrusion.
• Contain. Isolate the host through EDR. On Tier-0, payments or core-banking systems, contain first and confirm afterwards. The tool's cleanup action clears logs, so waiting costs evidence.
• Preserve, in this order: memory, if feasible; the .local\share\cyberstrike data directory and any .cyberstrike project folders (the session store may hold the operator's full transcript); Sysmon, TaskScheduler, WMI-Activity and Defender logs; $MFT and $UsnJrnl; AmCache and ShimCache; Prefetch.
• Find the operator host. If cyberstrike.exe is the parent, the agent runs locally, so this host is the operator platform. If it is not, look for the remote execution channel (WinRM, WMI, SMB service, scheduled task) and its source, and check for Bolt nodes scanning from cloud IP space.
• Scope by default names. Sweep every endpoint for the artefacts in section 5.2, the cs-* and cs_* file patterns, CyberStrike* registry values, CS_Filter_* WMI subscriptions and the root\cs_persist namespace. Default names spread exactly as far as the operator did.
• Scope the identity plane. Look for Kerberoasting (4769 with RC4 across many SPNs), DCSync (4662 replication rights from non-DCs), new certificate requests with CN=CyberStrike, shadow-credential writes to msDS-KeyCredentialLink, and new accounts or password resets using the default passwords from section 5.2.
• Check for anti-forensics. Look for events 1102 and 104, gaps in forwarded Security and PowerShell logs, Defender exclusions (event 5007), and deleted firewall rules or port-proxy entries.
• Eradicate and reset. Remove the persistence found. Reset the credentials of every account touched, including krbtgt twice if golden tickets or DCSync are suspected. Revoke certificates issued during the window.
• Report. Model provider API keys or session data recovered from the operator host can attribute the activity. Report through the provider's abuse channel, and meet your regulatory clocks (for example, six hours to CERT-In in India).

8. Limitations and evasion

This analysis reflects one commit of an actively developed open-source project, and an attacker can fork and modify it in an afternoon. The signatures degrade in a predictable order:

Two things are hard to change without breaking the tool: an agent loop that waits on a model between actions, and the need to adapt when an action fails. Those are why the behavioural layer (Tier 3) matters most over time.

The strings in this article come from reading the source. They have not been confirmed against a live run of the tool, apart from the YARA tests on reconstructed samples. Before relying on them, validate in an isolated lab: install CyberStrike on a disposable Windows VM joined to a test domain, run its Windows hook actions against lab targets only, and record what your EDR and SIEM actually capture.

In short: default names catch the careless operator, wrapper structure catches the lazy one, and tempo and behaviour catch the rest.

References

Source files studied, all at commit a5ed1e0:

• CyberStrike repository and README, CyberStrikeus, AGPL-3.0.
• winhook/shared.ts: execution wrappers, stealth modes and the capability probe.
• winhook/persistence.ts: default persistence names.
• winhook/exfil.ts: the cleanup routine.
• winhook/evasion.ts: LOLBin staging files and the PPID task.
• tool/inject-probe.ts: XSS, SSTI and command-injection probe constants.
• tool/webfetch.ts and session/llm.ts: User-Agent strings and x-cyberstrike-* headers.
• global/index.ts: on-disk data, config, cache and state paths.

Related reading: Machine-Speed Adversaries: Detecting AI-Driven Intrusions on Windows (companion article) · MITRE ATT&CK · Sigma specification.