All writeups

Cicada — walking an easy Active Directory chain end to end

windowseasyCicada
  • active-directory
  • smb
  • kerberos
  • privilege-escalation
  • windows
Retired HTB machinePublished under HTB's policy — retired machine, sanitized: no flags, no live lab IPs.
TL;DR

A retired, beginner-friendly Windows AD box: how a read-only share, a password reused in an LDAP field, and a backup privilege chain together into full domain compromise — and what each step should have set off in a SOC.

TL;DR — Anonymous SMB access exposes a share that leaks a default password. That password sprays to a valid domain user, whose LDAP object stores another user’s password in a description field. A DEV share holds a script with a third set of credentials, and that account has SeBackupPrivilege — enough to read the SAM/SYSTEM hives, recover the administrator hash offline, and authenticate as administrator. Each hop is small; the lesson is how ordinary misconfigurations compound.

This is a walkthrough of a retired Hack The Box machine, written for education. No live targets, credentials, IP addresses, or flags are included — the focus is the methodology and the defensive takeaways.

Why this box is worth writing up

Cicada is rated easy, and that is exactly why it is a good teaching box: nothing here is an exotic exploit. Every step is a configuration mistake a real domain could have — a share left open, a password typed into a comment field, a service account with one privilege too many. Walking it end to end is a compact tour of how Active Directory environments actually fall over, and — the part I care about more — where a defender gets a chance to notice.

1. Recon

Standard TCP service discovery against the target shows the fingerprint of a domain controller: SMB, LDAP, Kerberos, DNS. That combination sets the whole approach — this is an identity problem, not a web problem.

Terminal window
# service + default-script sweep against the DC (target redacted as box.htb)
nmap -Pn -sV -sC -p- --min-rate 1000 box.htb

2. Foothold — anonymous share → default password → spray

SMB allows an anonymous/guest session, and one share is world-readable. Inside is onboarding material that includes a default password handed to new starters. On its own that is just a string — but a default password is only useful if someone never changed theirs.

Enumerating domain users (again over the anonymous session) gives a name list. Spraying the single default password across that list — slowly, to stay under lockout thresholds — lands on one account that never rotated it.

Terminal window
# password spray: one password, many users, low-and-slow
nxc smb box.htb -u users.txt -p 'Default-Password-Here' --continue-on-success

That is the foothold: a valid, if low-privileged, domain account.

3. Lateral movement — a password stored in an LDAP field

With any authenticated context, LDAP becomes readable. A classic mistake shows up here: a user object stores a password in its description attribute. Description fields are free text, world-readable to any authenticated user, and people treat them like sticky notes.

Terminal window
# read user objects; the description field is the prize
nxc ldap box.htb -u michael -p '...' --query '(objectClass=user)' 'sAMAccountName description'

That second credential opens a DEV share, which contains a backup script with a third account’s password in cleartext. Scripts in shares are a recurring goldmine — automation needs credentials, and credentials in automation get forgotten.

4. Privilege escalation — SeBackupPrivilege

The third account can log in over WinRM. It is not an administrator — but it holds SeBackupPrivilege. That privilege exists so backup software can read any file regardless of ACLs, and that is precisely the problem: it can read the registry hives that store password material.

The chain is mechanical from here:

  1. Use the backup privilege to copy the SAM and SYSTEM hives out of the live registry.
  2. Pull them off the box.
  3. Recover the local administrator hash offline from the two hives.
  4. Authenticate as administrator with the hash — no plaintext ever needed.
Terminal window
# with SeBackupPrivilege, the hives are readable despite ACLs
reg save HKLM\SAM  sam.hive
reg save HKLM\SYSTEM system.hive

Offline, the hives yield the administrator NT hash, and a pass-the-hash login completes the box. Domain compromise achieved with zero exploits — only misconfigurations and one over-broad privilege.

What actually went wrong (and the defensive read)

Strip away the box framing and this is a list of findings any assessor would write up:

  • A default password that was never rotated, sprayable because a world-readable share advertised it.
  • A credential stored in an LDAP description field — readable by every authenticated principal.
  • Cleartext credentials in a script on a share — automation secrets with no vault.
  • SeBackupPrivilege on a non-backup account — a privilege that trivially becomes credential theft.

None of these needs a patch. They need hygiene: rotate defaults, keep secrets out of directory attributes and scripts, and treat backup/restore privileges as tier-0.

The more interesting question for me — the one I answer in the companion post — is: where does a SOC get to catch this? The password spray is a burst of authentication failures. The hive dump is a specific, detectable action. The pass-the-hash login has a signature. Every step above leaves a mark if you are collecting the right telemetry.

→ Companion: Detecting the Cicada chain — mapping each of these steps to Windows event IDs and Wazuh/Sigma logic.

All writeups