All writeups

Detecting the Cicada chain — turning an AD walkthrough into detections

detectionblue-teamCicada
  • detection-engineering
  • wazuh
  • sigma
  • active-directory
  • blue-team
  • siem
Retired HTB machinePublished under HTB's policy — retired machine, sanitized: no flags, no live lab IPs.
TL;DR

The offensive companion showed how an easy AD box falls. This one flips it: every hop — the spray, the LDAP secret read, the backup-privilege hive dump, the pass-the-hash — mapped to concrete Windows telemetry and Wazuh/Sigma logic a SOC can actually ship.

TL;DR — Attacks are noisy if you collect the right events. Password spraying is a burst of 4625s across many accounts from one source. Reading the SAM/SYSTEM hives is a 4688/Sysmon process pattern plus sensitive-privilege use. Pass-the-hash has a recognizable 4624 Type 3 / NTLM signature. Here is how I would detect each stage of the Cicada chain in a Wazuh-based SIEM, with Sigma equivalents.

This is the defensive companion to the Cicada walkthrough. It uses only public technique knowledge and standard Windows telemetry — no live targets or sensitive data.

The premise

I spend my day building and tuning SIEM detections, so a walkthrough only feels finished to me when I have asked the other question: if this had run against a monitored domain, what would have fired? Cicada is a clean test case because every step maps to a well-understood Windows event. This post walks the same chain as the offensive writeup, stage by stage, from the defender’s chair.

Telemetry assumed: Windows Security auditing (logon, account-logon, privilege-use, object-access) plus Sysmon, shipped to Wazuh. If you are not collecting 4625, 4624, 4688/Sysmon 1, and 4673/4674, that is the first fix — no rule detects an event you never ingested.

Stage 1 — Password spray → a burst of 4625

A spray is one password against many usernames. The signal is not a single failed logon; it is many distinct target accounts failing from one source in a short window. Tune on the cardinality of usernames, not the raw failure count.

<!-- Wazuh: many distinct failed usernames from one source in 60s -->
<rule id="100810" level="12" frequency="8" timeframe="60">
  <if_matched_group>windows_logon_failed</if_matched_group>
  <same_source_ip />
  <different_user />
  <description>Possible password spray: 8+ distinct accounts failed from one source in 60s</description>
  <mitre><id>T1110.003</id></mitre>
</rule>

Sigma equivalent (portable to any backend):

title: Potential Password Spray (many users, one source)
logsource: { product: windows, service: security }
detection:
  selection: { EventID: 4625 }
  timeframe: 1m
  condition: selection | count(TargetUserName) by IpAddress > 8
level: high
tags: [attack.credential_access, attack.t1110.003]

Tuning note: exclude known service accounts and NAT egress IPs, or the false-positive rate on a busy domain will bury the signal. A spray also skews toward disabled/nonexistent accounts (sub-status 0xC0000064) — a strong booster feature.

Stage 2 — Secret read from LDAP

Reading a description attribute is, by design, quiet — it is a legitimate directory read. You will not get a clean per-attribute event without SACLs, so this stage is about prevention and hunting, not a single rule:

  • Hunt: periodically scan directory objects for password-like strings in description/info fields and alert on matches. Cheap, high-value, catches the mistake before an attacker does.
  • Detect (best-effort): with an object-access SACL on sensitive OUs, 4662 shows property reads — noisy, but scopeable to tier-0 objects.

The honest answer: the durable control here is hygiene (keep secrets out of directory fields), and the SOC’s job is the recurring hunt that finds them.

Stage 3 — SeBackupPrivilege hive dump

This is the loudest, most reliably-detectable stage. Copying SAM/SYSTEM out of the live registry means a process invoking reg save (or an API equivalent) while holding a sensitive backup privilege. Two independent signals:

title: SAM/SYSTEM hive export via reg save
logsource: { product: windows, category: process_creation }   # 4688 / Sysmon 1
detection:
  selection:
    Image|endswith: '\reg.exe'
    CommandLine|contains|all: ['save', 'hklm\']
    CommandLine|contains: ['sam', 'system', 'security']
  condition: selection
level: critical
tags: [attack.credential_access, attack.t1003.002, attack.t1003.004]

Pair it with sensitive-privilege use (4673/4674 naming SeBackupPrivilege) from a non-backup account, and you have a high-confidence, low-noise alert. In Wazuh I would correlate the two with if_matched_group so the alert only fires when the privilege use and the hive access co-occur on the same host.

<rule id="100820" level="14">
  <if_matched_group>sysmon_process_creation</if_matched_group>
  <field name="win.eventdata.image">reg.exe$</field>
  <field name="win.eventdata.commandLine">save.+hklm\\(sam|system|security)</field>
  <description>Credential theft: SAM/SYSTEM hive export (T1003.002)</description>
  <mitre><id>T1003.002</id></mitre>
</rule>

Stage 4 — Pass-the-hash logon

Authenticating with a recovered NT hash surfaces as a network logon (4624 Type 3) using NTLM where you would expect Kerberos, often to administrative access and frequently from an unusual source host. The tell is NTLM to a machine that normally speaks Kerberos, plus a logon to a privileged account outside its baseline.

title: Possible Pass-the-Hash (NTLM Type 3 to privileged account)
logsource: { product: windows, service: security }
detection:
  selection:
    EventID: 4624
    LogonType: 3
    AuthenticationPackageName: NTLM
  privileged: { TargetUserName|endswith: 'Administrator' }
  condition: selection and privileged
level: high
tags: [attack.lateral_movement, attack.t1550.002]

Tuning note: NTLM is not extinct — legacy apps and some admin tooling still use it. Baseline which hosts/accounts legitimately use NTLM Type 3, and alert on the deviation, not on NTLM itself.

The point

Every hop in an “easy” box is a detection opportunity if the telemetry exists and the rules are tuned to the shape of the technique rather than a brittle string. Password spray = username cardinality, not failure count. Hive dump = privilege-use and process together, not either alone. Pass-the-hash = NTLM deviation, not NTLM presence.

Writing the offensive walkthrough and then the detections back to back is the exercise I find most useful: it forces the attacker’s steps and the defender’s telemetry into the same frame, and that is where good detection engineering actually comes from.

All writeups