HTB CAPE study materials
HTB CAPE study resources

The Workgroup Web Shell Behind an Egress Filter

HTB CAPE · Put your knowledge to work in context.

All case studies

The Workgroup Web Shell Behind an Egress Filter

During an authorized external test you obtain command execution as NT AUTHORITY\SYSTEM on an internet-facing IIS server, WEB-DMZ-01, through a deserialization flaw. The host is workgroup-joined, sits in a DMZ, and has no domain credentials cached. Outbound firewall rules allow only TCP 443 and UDP/TCP 53 from WEB-DMZ-01 to 10.0.0.0/16; SMB, RDP, WinRM, LDAP, and Kerberos are blocked. Internal DNS resolves dc01.corp.local to 10.0.0.10. In web.config you find a connection string with CORP\svc_web and a 24-character password; the account is a normal domain user. You confirm the password is valid by authenticating to an internal HTTPS application on 10.0.0.50, which returns a welcome page. EDR is deployed on internal servers and blocks PowerShell and C# payloads. You have two hours and must obtain a domain-joined foothold, not just proof of credential validity.

1. Given only 443/53 egress, evaluate three candidate paths: SMB relay, AD CS web enrollment, and internal HTTPS application abuse. Which do you pursue and why?

Read the worked answer

SMB relay is out: 445 is blocked both ways and there is no inbound authentication path from internal hosts to the DMZ host. AD CS web enrollment is tempting, but a certificate request alone does not give a foothold; without Kerberos or LDAP egress, PKINIT and certificate-based LDAP/WinRM are not reachable. The remaining viable path is the internal HTTPS application that already accepted CORP\svc_web. I would enumerate its endpoints for file upload, template injection, SSRF, or an admin interface, using only 443. The goal is to turn a valid domain credential into code execution on an internal, domain-joined host. I would not spray the credential across other 443 services; one authentication per candidate service, with delays, to avoid lockout and SOC correlation. If the app has an upload, test with a benign text file first. If it has SSRF, target only internal 443 hosts in scope. This path respects the egress constraints and avoids noisy SMB or Kerberos traffic that the firewall would drop anyway.

2. How would you use the valid credential without triggering lockout or EDR, and what would you avoid?

Read the worked answer

Use the credential sparingly and from the web shell, not from a new tool that needs PowerShell or C#. I would make a single authenticated request to the internal app, capture the session cookie, and then interact through that session. If upload is available, upload a minimal web shell in a language the app already executes, avoiding encoded PowerShell and known EDR signatures. Avoid LSASS, service creation, scheduled tasks, and repeated login attempts. Do not use runas or net use; SMB is blocked and would fail noisily. Keep a log of each request and timestamp. If the app uses NTLM, remember that each request is an authentication event; a lockout policy of 5 attempts could be reached quickly if scripts retry. Use a single valid session and do not parallelize. EDR on internal servers may still catch web-shell commands, so start with discovery commands that match the app's normal behavior.

3. What is your fallback if the internal app has no upload and only returns static content?

Read the worked answer

If the internal app is static and has no upload, SSRF, or admin function, I would stop rather than burn the remaining time. I would document the confirmed credential, the reachable 443 service, and the blocked protocols. The fallback is to use the allowed 443 channel for discovery of other internal HTTPS services that might accept the account, such as OWA, SharePoint, GitLab, or Jenkins, but only one attempt per service. If none provide execution, the correct finding is 'valid domain credential with no reachable foothold under current egress rules', plus a recommendation to review the firewall rule. I would not attempt DNS tunneling as a foothold; DNS can carry command-and-control but does not give a domain-joined shell. I would not request a firewall change mid-test unless the client authorizes it. Reporting the blocker is more valuable than noisy failed exploitation.