About the Machine
NanoCorp is a hard-difficulty Windows Active Directory machine that challenges players to combine enumeration, Kerberos abuse, AD privilege escalation, and Windows post-exploitation techniques to reach full domain compromise. The machine simulates a small corporate network with multiple service accounts, misconfigured permissions, and an exploitable enterprise monitoring tool.
The foothold begins with enumerating SMB shares and identifying a vulnerable service account (WEB_SVC). A captured NTLMv2 hash is cracked offline, granting initial authentication into the domain. After synchronizing time with the domain controller and leveraging Kerberos (via getTGT), the attacker gains their first real foothold in the AD environment.
From there, the machine opens up into deeper privilege escalation. Using BloodHound, several privilege relationships are revealed, including misconfigurations that allow the attacker to add themselves to the IT_Support group and even reset the password of additional privileged accounts like monitoring_svc. With this expanded access, WinRM over Kerberos is used to gain a full Windows shell, leading to the capture of the user flag.
The escalation to SYSTEM is where NanoCorp earns its hard rating. The player must weaponize RunasCs, host payload files over HTTP, transfer binaries and scripts into the target, and exploit a flawed CheckMK MSI repair mechanism. By crafting a malicious PowerShell payload (bad.ps1), seeding Windows Temp directories with read-only files, and forcing an MSI self-repair via msiexec, an attacker triggers a SYSTEM-level command execution that provides a reverse shell as NT AUTHORITY\SYSTEM.
This access enables a full crawl of the filesystem, culminating in retrieving the final root flag from the Administrator desktop.
NanoCorp is an excellent exercise in multi-stage Active Directory exploitation, showcasing:
- NTLMv2 hash cracking
- Kerberos ticket manipulation
- AD privilege escalation via BloodHound and misconfigured ACLs
- WinRM authentication using Kerberos TGS tickets
- Reverse shell creation through MSI repair abuse
- Full SYSTEM compromise and Windows post-exploitation
This machine is ideal for anyone wanting to test their understanding of real-world, enterprise-grade AD exploitation scenarios from foothold to full domain takeover.
The first step in owning the NanoCorp machine like I have always done in my previous writeups is to connect my Kali Linux terminal with Hack the Box server. To establish this connection, I ran the following command in the terminal:
Once the connection between my Kali Linux terminal and Hack the Box server has been successfully established, I started the NanoCorp machine and I was assigned an IP address (10.10.11.93).
Nmap Enumeration
I started the enumeration phase with a full service and version scan against the target using nmap -sCV -A.
The host at 10.10.11.93 responded with a healthy latency, but most ports were filtered - an early indication of a hardened Windows environment behind a firewall.
Despite the filtering, Nmap identified several high-value ports consistent with a Windows Active Directory domain controller. Here's what stood out.
Nmap Scan Result
1. Web Server on Port 80
Port 80 was running Apache 2.4.58 on Windows with PHP 8.2.12. What’s interesting is that the page immediately redirected me to the hostname nanocorp.htb, confirming that this machine serves as the main web endpoint for the domain. The web service isn’t just a static site; it’s likely tied into the broader infrastructure.
2. Full AD Stack Detected
A cluster of ports revealed that this box is almost certainly the primary domain controller:
- Kerberos (88)
- LDAP (389, 636)
- Global Catalog LDAP (3268, 3269)
- SMB/RPC (135, 139, 445)
- Kpasswd (464)
LDAP banners confirmed the domain name: nanocorp.htb, and referenced the server hostname DC01 - classic naming for a domain controller. SMB was configured securely, with message signing required, limiting a few common attack vectors.
3. WinRM (5986)
Port 5986 revealed HTTPS-secured WinRM, suggesting remote management might be possible once valid credentials are obtained. The SSL certificate again exposes the hostname dc01.nanocorp.htb, reinforcing the domain controller theory.
4. DNS on Port 53
The server is also running DNS (Simple DNS Plus), which fits neatly with typical AD responsibilities.
Adding the Domain to /etc/hosts
Since the earlier Nmap scan revealed that the web server on port 80 automatically redirected to nanocorp.htb, and multiple services referenced the hostname dc01.nanocorp.htb, I needed to ensure my machine could properly resolve these internal domain names.
In a typical enterprise Active Directory setup, the Domain Controller handles DNS internally. But because we’re interacting with it from outside that network, our local machine won’t know how to resolve those hostnames unless we tell it explicitly.
To fix this, I edited my /etc/hosts file and manually mapped the target’s IP to the domain names identified during enumeration:
This lets my machine correctly resolve:
- nanocorp.htb – the main domain name
- dc01.nanocorp.htb – the hostname of the domain controller
- nanocorp.htb0 – an alternate form that appeared in LDAP banners
With these entries added, accessing the website and interacting with Kerberos, LDAP, and SMB becomes seamless. Tools like ldapsearch, evil-winrm, rpcclient, and even a regular browser will now automatically route requests to the correct target. This step is crucial in almost any Active Directory CTF, as many services expect domain-qualified hostnames.
Web Enumeration - DirBuster Discovery
With the domain properly resolved, my next step was to enumerate the web application for hidden directories or files. I launched DirBuster against the main site:
The scan didn’t uncover any particularly exotic endpoints, but it did give a clearer picture of how the site is structured and what technologies it relies on.
DirBuster identified several public directories:
- /img/ – static images
- /js/ – JavaScript files
- /css/ – the project’s stylesheets
- /slick/ – assets belonging to the Slick carousel library
- /icons/ – Apache’s default icon directory
Most of these are typical for a static or template-based website. They don’t directly expose sensitive functionality, but they do confirm the site is built around a premade theme (Slick + Bootstrap).
A single directory returned a 403 Forbidden:
- /cgi-bin/ – A restricted directory often associated with older CGI scripts
This one is worth keeping in mind. A 403 means the directory exists but is intentionally protected, which can sometimes hint at legacy scripts or administrative tooling.
DirBuster also picked up several theme-related files such as:
main.js,jquery-3.2.1.slim.min.js- Bootstrap and custom CSS
- Multiple
slick.*files (JS, CSS, SCSS, LESS, fonts)
These mostly confirm that the web front-end is static and likely not the primary attack surface.
During the scan, DirBuster generated a series of HTML parsing warnings relating to unclosed <div> tags. These aren’t vulnerabilities, they’re simply part of how the page’s template is written, and DirBuster logs them as informational noise.
Fixing the Clock Skew
During my initial Nmap scan, I noticed that one of the host scripts reported a clock skew between my machine and the domain controller. This is more than just a cosmetic issue, Kerberos authentication is extremely sensitive to time differences, and even a small drift can cause ticket requests to fail. Since I knew I would eventually be interacting with Kerberos-based services, I needed to fix my system clock before moving forward.
To synchronize my time with the target, I used the domain controller itself as an NTP source:
The adjustment was significant:
My system clock was off by roughly 29 seconds, which is more than enough for Kerberos to reject authentication attempts. After this correction, my machine was finally in sync with the domain controller, removing a major pitfall before attempting any Kerberos, LDAP, or SMB operations.
With the time fixed, I could now safely continue with domain enumeration and authentication attacks without worrying about false negatives caused by clock drift.
SMB / RPC Enumeration – enum4linux
With the web frontend looking fairly static, I shifted my focus toward the backend services, especially SMB and RPC. Since the earlier Nmap scan confirmed SMB, LDAP, and Kerberos were active, I used enum4linux to see what anonymous access (null sessions) might reveal:
The tool ran successfully, but the results immediately showed that this domain controller was locked down much tighter than many CTF machines.
Domain Information Leaked via Null Session
Even though the target rejected most enumeration requests, enum4linux was able to pull one important piece of data:
- Domain Name: NANOCORP
- Domain SID:
S-1-5-21-2261381271-1331810270-697239744
This confirmed beyond any doubt that the machine is an Active Directory domain controller. Knowing the Domain SID is especially important for future attacks such as RID cycling or Kerberos enumeration.
Enum4linux also verified that anonymous sessions are technically allowed, but they provide almost no privileges:
This is typical in hardened AD environments: null sessions can connect, but almost everything is restricted by ACLs.
Kerberos User Enumeration - Kerbrute
Since SMB enumeration was heavily restricted and most RPC queries were blocked, the next logical step was to pivot into Kerberos-based enumeration. Kerberos often leaks valid usernames even when everything else is locked down, making it an excellent vector for discovering accounts in hardened Active Directory environments.
To do this, I used Kerbrute, a powerful tool for identifying valid domain users by interacting directly with the KDC:
Kerbrute began spraying the domain controller with user enumeration requests against Kerberos port 88, confirming it was communicating with 10.10.11.93:88.
After a few minutes, Kerbrute finally returned hits, meaning the domain controller acknowledged the existence of those accounts:
Even though Kerberos usernames are case-insensitive, Kerbrute still reports them as separate matches when found in the wordlist.
This confirmed that the Administrator account is present in the domain. While this is expected for a domain controller, validating it through Kerberos is significant because:
- It proves Kerberos is functioning normally (especially important after fixing clock skew).
- It allows targeted password spraying attempts.
- It may allow AS-REP roasting if other accounts are identified later.
Although only the built-in Administrator account was discovered, this result established that Kerberos enumeration is viable and primed the next phase of the attack.
Exploring the Website - Discovering a Secondary Subdomain
After gathering initial enumeration data, I headed over to the main web interface at:
The landing page presented a sleek corporate-themed interface with four large clickable tiles: Home, About Us, Our Work, and Contact. Everything looked static at first glance, but interacting with the site quickly revealed something more interesting.
Clicking the “About Us” tile opened a modal-style pop-up containing a short company description. Most of it was typical marketing fluff until the last line:
“…we’re growing, we are hiring! Join us in shaping the future of cybersecurity and tech innovation.”
Below the description was a prominent “Apply Now” button. This immediately caught my attention. CTF machines rarely include hiring portals just for aesthetics; they usually hide something more functional (or vulnerable) under the hood.
Clicking the button redirected me to a new subdomain:
Since this hostname wasn’t in my /etc/hosts file, I added it so the page could resolve correctly.
The Hiring Portal - File Upload Functionality
The hire.nanocorp.htb page looked like a simple job application portal branded “Join Nanocorp.” It included:
- Full Name input
- Email Address input
- Position selection dropdown (Software Engineer, Network Engineer, Cybersecurity Consultant)
- A file upload field
- A “Submit Application” button
That file upload field immediately stood out. In CTF challenges, file uploads are almost always potential entry points especially when the instructions explicitly mention uploading a ZIP file.
This suggested two possible avenues:
-
Client-side validation bypass (uploading a non-ZIP disguised as a ZIP)
-
Server-side ZIP extraction vulnerability (e.g., ZIP slip, unsafe file handling)
Since the form accepted attachments directly, this likely represented the next major attack surface on the machine.
With the hiring portal discovered and the upload functionality exposed, the next step was to test how the server handled ZIP files and whether it could be coerced into executing or extracting malicious content.
Leveraging CVE-2025-24071 - Generating a Malicious ZIP Payload
Once I identified that the hiring portal accepted ZIP file uploads, I started researching potential vulnerabilities related to unsafe ZIP extraction or insecure file handling. During this search, I came across CVE-2025-24071, a recently published flaw affecting web applications that improperly process user-supplied ZIP archives.
The vulnerability aligned perfectly with the behavior I observed on hire.nanocorp.htb, so I decided to test whether the target was susceptible. I cloned the publicly available proof-of-concept exploit:
The repository downloaded successfully, and after navigating into the directory, I saw the exploit script:
The poc.py file appeared to be an automated payload generator designed to craft a malicious ZIP archive tailored for this vulnerability. Running it launched an interactive prompt:
I supplied a filename (boltech) and my local VPN IP (10.10.15.26) so that any reverse shell or callback payload inside the ZIP would be correctly configured to reach my machine.
Once the script completed, it reported Completed
Listing the directory again confirmed that the exploit had successfully generated a new file:
This ZIP archive was the malicious payload produced by the CVE-2025-24071 exploit script. The next step was clear: upload exploit.zip to the hiring portal and observe how the server processed it, potentially triggering arbitrary file write or code execution on the target machine.
Capturing NTLMv2 Hashes with Responder
With my malicious exploit.zip ready, the next objective was to observe how the hiring portal handled file extraction or network-based callbacks. Since many vulnerable ZIP-processing engines attempt to fetch external resources or accidentally trigger UNC path resolutions, I prepared Responder to capture any NTLM authentication attempts leaking from the target.
I launched Responder on my VPN interface:
Responder spun up its full suite of spoofing services - LLMNR, NBT-NS, SMB, HTTP, LDAP, and even Kerberos emulation - all listening for unintended authentication traffic from the domain controller.
Once everything was armed and waiting, I returned to hire.nanocorp.htb, filled in the fake job application fields, uploaded the malicious ZIP, and clicked Submit.
Almost immediately, Responder lit up.
The domain controller at 10.10.11.93 attempted to authenticate back to my machine, sending multiple NTLMv2 challenge-response hashes. Every packet revealed the same domain account:
Each authentication attempt landed perfectly:
This confirmed two critical points:
-
The hiring portal was indeed vulnerable - the malicious ZIP caused the server to reach out over SMB.
-
We had successfully captured NTLMv2 hashes for the
web_svcdomain service account.
These hashes could now be fed into a cracking tool or used directly for pass-the-hash or relay attacks, depending on the environment's configuration.
Cracking the Captured NTLMv2 Hash
With valid NTLMv2 hashes captured from the domain controller, the next step was to attempt cracking them offline. I took one of the captured challenge-response pairs and saved it into a file called hash.txt:
With the hash isolated, I handed it over to John the Ripper using the RockYou wordlist - a classic go-to for CTFs and real-world pentesting alike:
John immediately recognized the format (netntlmv2) and spun up 24 threads to brute-force it. Within seconds, it cracked the service account’s password:
This confirmed that the domain account NANOCORP\web_svc was using a weak, wordlist-crackable password, a serious misconfiguration for a production Active Directory environment.
With valid domain credentials now in hand, I was ready to authenticate directly against the DC and begin enumerating the internal network from an authenticated perspective.
Enumerating SMB Shares with Valid Credentials
Now that I had valid domain credentials for the WEB_SVC account, the next logical step was to re-enumerate SMB - this time as an authenticated user. Anonymous checks revealed nothing earlier, but authenticated enumeration often exposes additional internal shares.
I queried the server using smbclient:
After entering the newly-cracked password, SMB responded with a full list of available shares:
The presence of NETLOGON and SYSVOL immediately confirmed that this machine is indeed the domain controller - these are core Active Directory shares used to store login scripts, group policy objects, and domain-wide configuration.
While ADMIN$ and C$ are standard administrative shares (typically requiring higher privileges), authenticated users often have read access to SYSVOL. This share can contain sensitive information such as:
- Group Policy files
- Login scripts
- Passwords stored in plaintext or reversible encryption
- Configuration files for domain-level services
Finding readable content here often leads directly to privilege escalation, so this share became the next focus of the enumeration process.
Synchronizing Time & Obtaining a Kerberos TGT
Before attempting any Kerberos-based attacks, I needed to ensure my local machine’s clock was synchronized with the domain controller. Kerberos is extremely strict about time drift, even a few minutes of mismatch will cause ticket requests to fail.
To avoid unnecessary debugging later, I synced my system clock directly with the DC:
The output confirmed that my clock was successfully adjusted:
With my timing aligned, I moved on to generating a valid Kerberos Ticket-Granting Ticket (TGT) for the compromised domain account WEB_SVC. Using the credentials I cracked earlier, I requested a TGT using Impacket’s getTGT tool:
The attack succeeded, and Impacket saved the resulting Kerberos TGT locally:
To make use of the ticket for authenticated Kerberos operations (like SMB, LDAP, or DCE-RPC enumeration), I exported it into my session:
At this point, my machine was effectively holding a legitimate Kerberos authentication token for the WEB_SVC domain user, allowing me to operate inside the domain as that account without repeatedly supplying the password.
Enumerating the Domain with BloodHound & Abusing ACLs for Privilege Escalation
With Kerberos authentication properly configured and the WEB_SVC TGT loaded, the next step was to get a full picture of NanoCorp’s Active Directory structure. For that, I turned to BloodHound, using the Python ingestor to pull as much information as possible from the domain.
I launched the collection phase with:
BloodHound confirmed it recognized the domain and that my Kerberos ticket was being used successfully:
The ingestor then began pulling AD objects, yielding a surprisingly small but telling dataset:
- 1 domain
- 1 computer (the domain controller itself)
- 6 users
- 53 groups
- 2 GPOs
- 2 OUs
- 19 containers
Once the JSON files were generated (domains.json, groups.json, users.json, etc.), I began digging for misconfigurations. Two accounts caught my attention:
- The IT_Support group inside groups.json
- A service account monitoring_svc inside users.json
This suggested there might be exploitable delegation or overly-permissive ACLs applied to WEB_SVC.
To test this theory, I used bloodyAD, a tool that weaponizes Active Directory ACL abuse. First, I attempted to add WEB_SVC to the IT_Support group:
The result confirmed my suspicion - the account had rights it absolutely should not have:
Being able to modify group membership is a critical escalation path on any Windows domain. But it got even better. I tested whether WEB_SVC could manipulate other user accounts. Targeting the monitoring_svc account, I attempted a password reset:
BloodHound’s ACL map was right - I had full control over this account too:
With this, I now controlled a second domain account, potentially with higher privileges or different access paths. The foothold gained through WEB_SVC had escalated into a broader compromise of the NanoCorp AD environment, simply by abusing misconfigured ACLs.
Pivoting to the monitoring_svc Account via Kerberos
Now that I had successfully reset the password for the monitoring_svc user, the next logical step was to assume the identity of this newly compromised account and use it to continue enumerating or escalate even further.
To do this, I generated a fresh Kerberos TGT for monitoring_svc using Impacket’s getTGT tool:
The command executed cleanly, and Impacket confirmed that the ticket had been created '[*] Saving ticket in monitoring_svc.ccache'
This .ccache file is essentially the Kerberos “identity” of the monitoring_svc account with it, I could authenticate to domain services without repeatedly supplying the password.
Next, I exported the ticket so Linux tools would automatically use it:
With this environment variable set, any Kerberos-aware tool (BloodHound, ldapsearch, Impacket modules, etc.) would now operate as the monitoring_svc user.
This step effectively pivoted my access from the low-privileged WEB_SVC account to a potentially more powerful service account, setting the stage for deeper enumeration or domain compromise.
Gaining an Interactive Shell via WinRM (and Capturing the User Flag)
With a valid Kerberos ticket for the monitoring_svc account in hand, I was ready to attempt remote execution on the domain controller. SMB access was limited and LDAP enumeration had already given everything it could - the next logical attack surface was WinRM, which was exposed on port 5986 according to my earlier Nmap scan.
To take advantage of WinRM using Kerberos authentication, I cloned a lightweight Python utility designed for exactly this purpose:
After the repository finished pulling, I launched the tool and instructed it to authenticate using my cached Kerberos ticket:
The -k and -no-pass flags ensured that authentication relied entirely on the Kerberos ticket (monitoring_svc.ccache) rather than a plaintext password.
The tool validated the ticket, requested a service ticket for the HTTP/dc01.nanocorp.htb SPN, and moments later dropped me into a fully interactive PowerShell session - running directly on the domain controller:
At this point, I navigated through the directories to explore the account’s accessible files:
Everything looked standard, but the Desktop folder was the most likely place for a user flag, so I checked it next:
There it was - a familiar sight in any HTB-style Windows machine:
Displaying the file gave me the flag:
And with that, I secured the user flag, proving full control of the monitoring_svc account and stable remote execution on the domain controller - the perfect stepping stone toward privilege escalation and eventual domain compromise.
With the user flag secured, my next objective was clear: escalate privileges and hunt down the root flag. From enumeration, I suspected that leveraging token impersonation or privilege escalation tools might give me the access I needed. To prepare, I grabbed RunasCs, a well-known post-exploitation utility for executing processes under alternative credentials.
I cloned the tool directly from GitHub:
After cloning the repository, I moved into the RunasCs directory to inspect its contents. Inside, I found the main C# source file (RunasCs.cs), a PowerShell invocation script, and a few supporting files. Since I needed the binary on the target machine, my next step was to transfer the source code over to the Windows host where I could compile and execute it.
To do that, I spun up a quick Python HTTP server on my attacking machine:
This exposed the RunasCs files over HTTP. Immediately afterward, I switched back to my WinRM shell on the victim and navigated to the Documents directory. From there, I pulled down the C# source file directly:
The file downloaded successfully, confirming the server connection. With the source code now sitting inside the Documents folder on the target, I was ready to compile and run it to continue my privilege escalation path.
Copying Netcat for Windows to RunasCs Directory
With the RunasCs source file now on the target, I needed a simple, reliable payload to execute once I gained elevated privileges. For this machine, I chose the classic nc.exe (Netcat for Windows), which would allow me to spawn a reverse shell from the victim back to my attacking machine.
To prepare the file for transfer, I navigated through Kali’s built-in Windows resources. These tools are stored under /usr/share/windows-resources, so I dropped into that directory and browsed its contents. Inside the binaries folder, I found a collection of common Windows executables including the one I was looking for: nc.exe.
Once confirmed, I copied Netcat directly into my working directory where the RunasCs project was located:
This ensured that both the privilege-escalation tool (RunasCs) and the reverse shell payload (nc.exe) were in the same place, ready to be served to the victim over my Python web server in the next step. At this point, my setup on the attacker machine was complete, I had everything needed to attempt privilege escalation and capture the root flag.
With both RunasCs.cs and nc.exe prepared on my attacker machine, the next step was to get them onto the victim. I started by switching over to the victim’s C:\Windows\Temp directory, an ideal location because it’s writable by low-privileged users and routinely used for staging files during engagements.
To pull down my reverse shell payload, I used PowerShell’s wget to download nc.exe directly from my Python web server:
The download completed successfully, so the payload was now ready on the target.
Next, I needed to turn the RunasCs source code into an actual Windows executable. Windows conveniently ships with a built-in C# compiler located under the .NET Framework directory. I navigated back to my working directory and invoked the compiler manually:
The compiler spun up and generated RunasCs.exe, though it did display a warning noting that the built-in compiler only supports features up to C# 5. Despite the outdated version message, the compilation completed without errors meaning I now had a functioning binary ready to attempt privilege escalation.
With both RunasCs.exe and nc.exe on the target system, I had everything I needed to move toward capturing the root flag.
With my foothold as monitoring_svc and the supporting binaries in place, the next objective was to weaponize the RunasCs privilege-escalation vector. For this machine, the privilege escalation revolves around abusing a misconfigured Checkmk MSI repair routine, which can be hijacked to execute arbitrary code as SYSTEM. To take advantage of that, I prepared a malicious PowerShell script named bad.ps1 and pasted the following content in it:
Inside this script, I defined a reverse shell payload that uses the nc.exe binary I previously dropped into C:\Windows\Temp. The script dynamically generates hundreds of read-only .cmd files with predictable names, exactly the naming pattern Checkmk’s repair process looks for. Each of these files contains my Netcat one-liner:
Meaning: the moment the repair service touches one of these seeded files, it will unknowingly execute my reverse shell with SYSTEM integrity.
The script then locates the vulnerable Checkmk MSI by scanning the Installer registry hive:
Once it finds the correct MSI package, the script sprays all the malicious .cmd files across C:\Windows\Temp, marks them read-only (matching the expected behavior), and finally triggers a silent MSI repair:
This action is what ultimately forces the system to execute the malicious payload under SYSTEM context.
After creating the script locally on my attacker machine, I hosted it via my Python HTTP server and then pulled it down to the victim:
With bad.ps1 now staged on the target and ready to run, everything was in place to trigger the exploit and capture a SYSTEM shell.
Triggering the Exploit Chain
With the malicious script and binary payloads in place, all that was left was to trigger the exploit chain and catch the resulting SYSTEM shell. I began by setting up my listener on port 7001, waiting for the reverse shell callback:
Once the listener was ready, I executed the final payload on the compromised Windows machine using RunasCs, leveraging my previously escalated web_svc credentials:
RunasCs immediately kicked the entire chain into motion. The output confirmed everything was lined up correctly:
This told me three things:
-
The vulnerable Checkmk MSI package had been identified
-
The malicious
.cmdfiles were successfully seeded across the Temp directory -
The MSI repair routine was triggered, forcing Windows Installer to process my poisoned files
A few seconds later, my listener lit up - proof that the system executed my Netcat payload with elevated privileges:
I now had a reverse shell running as SYSTEM, confirmed by the working directory and full access to C:\Windows\system32:
At this point, the privilege escalation had succeeded - my foothold as monitoring_svc was now replaced with full SYSTEM-level control of the machine.
With SYSTEM-level access fully established through the reverse shell, the final objective was straightforward: locate and capture the root flag. From the SYSTEM shell, I began by navigating to the root of the filesystem:
A quick directory listing confirmed the standard Windows structure, including the Users folder where both user and administrator profiles are stored:
I moved into the Users directory to enumerate the available accounts:
Among the familiar accounts, the one that mattered now was Administrator, the profile that traditionally stores the root.txt flag on Windows-based HTB machines:
I switched into the Administrator profile and continued exploring:
After confirming the directory structure, I navigated into the Desktop directory, typically the final resting place of the root flag:
And there it was:
With full SYSTEM privileges, reading the flag was trivial:
Hurray! I got the root flag. With that the machine was officially pwned.
If you enjoy reading my walkthrough, do not forget to like, comment, and subscribe to my YouTube channel and also connect with me on LinkedIn. Also, don't forget to turn on post notification on my YouTube channel and Medium to get notification as soon as I write.
Subscribe to my YouTube channel and Follow me on: LinkedIn | Medium | Twitter | Boltech Twitter | Buy Me a Coffee
Keywords:
NanoCorp Hack the Box Writeup
NanoCorp Hack the Box Machine Writeup
NanoCorp Hack the Box Walkthrough
NanoCorp Hack the Box Machine Walkthrough
NanoCorp HTB Writeup
NanoCorp HTB Walkthrough
NanoCorp HTB Machine Walkthrough
NanoCorp HTB Machine Writeup
NanoCorp Hack the Box HTB Machine Walkthrough Writeup
NanoCorp HTB Solution
NanoCorp Hack the Box Solution
NanoCorp Hack the Box Complete Walkthrough
NanoCorp Hack the Box Complete Writeup
NanoCorp Hack the Box Complete Solution
NanoCorp htb write up
HackTheBox NanoCorp Writeup
HTB NanoCorp Writeup
HackTheBox NanoCorp Writeup
HackTheBox - NanoCorp (Writeup)
HTB Writeups - NanoCorp
HackTheBox NanoCorp Writeup
NanoCorp | HTB Writeup | Linux
nanocorp htb
HTB - NanoCorp Writeup
Owned NanoCorp from Hack The Box
Hack The Box - HTB NanoCorp Writeup
HTB NanoCorp Detailed Writeup English
HackTheBox | NanoCorp HackTheBox · HackTheBox | NanoCorp
NanoCorp HTB Writeup | HacktheBox | Season 9
HTB Writeup - NanoCorp
Write-ups Category Posts | Hack The Box Blog
NanoCorp - Hack the Box - Walkthrough
NanoCorp - HTB - Walkthrough
NanoCorp - Hack the Box - Writeup
0 Comments