One Host, Two Failed Payloads, and an Egress Policy
An external test targets a single host, 203.0.113.45 - Windows Server 2016 x64 running Tomcat 8 with a manager application reachable over HTTPS. The client's edge firewall permits inbound 443 only, and outbound TCP 80/443 to any destination plus DNS; everything else is dropped. The tester's VM sits behind corporate NAT with internal address 10.1.5.22 and egress address 198.51.100.77, with no inbound port forwarding. Attempt one: the Tomcat manager upload module with windows/meterpreter/reverse_tcp, LHOST 10.1.5.22, LPORT 4444 - no session, and the Tomcat log shows repeated SYNs to 10.1.5.22:4444. Attempt two: windows/x64/meterpreter/reverse_https, LHOST 198.51.100.77, LPORT 443 - the console prints "Meterpreter session 1 opened" but the session dies after about four seconds, every time. The client requires no persistence and a full cleanup record.
1. Explain both failures and justify the LHOST and transport you would use instead.
Read the worked answer
The two failures have different causes, and conflating them leads to the wrong fix.
Attempt one fails at routing plus policy. 10.1.5.22 is an RFC1918 address on the tester's side of corporate NAT; the target has no route to it and no NAT translation would ever deliver it. On top of that, outbound 4444 is outside the permitted 80/443 set, so even a correct address would be dropped. LHOST must be the address the target can actually reach - the egress address 198.51.100.77 - and LPORT must sit in an allowed range.
Attempt two gets further but loses the stage. The stager executed and connected over 443, which is why a session ID appeared. What dies four seconds later is the second connection that pulls the Meterpreter stage. The most likely culprits are an HTTPS-inspecting proxy mangling the stage download, and endpoint protection terminating the stage in memory. The distinguishing evidence is in the handler output: with set VERBOSE true and set ExitOnSession false, the handler shows whether it sent the stage and whether the target reconnected.
The correct move is a stageless payload: windows/x64/meterpreter_reverse_https sends the full agent in a single connection, eliminating the fragile second fetch. Keep LHOST at the egress address, LPORT 443, and keep HandlerSSLCert consistent so inspection devices see a coherent handshake. Use the x64 payload rather than the 32-bit variant - the WoW64 path adds instability on a 64-bit OS and is unnecessary here.
2. What does the delivery mechanism (a Tomcat manager WAR upload) change about payload choice, and how does that constrain your options?
Read the worked answer
The delivery mechanism is not a generic exploit - it deploys a file to a running application server, and that has consequences for both payload selection and client impact.
Format constraints. The upload accepts a WAR containing a JSP, so the payload must be expressible as a JSP (or a JSP that drops and executes a binary). A native Windows executable payload cannot be uploaded directly; the usual pattern is JSP → staging or JSP → command execution → download of the second file. That extra download is another opportunity for egress filtering or inspection, which is exactly the failure seen in attempt two. Where the payload can be delivered in one step, do so.
Size and reliability. Staged payloads are small and fit neatly into a JSP, but each stage is a new connection to a host whose egress is tightly filtered. Stageless payloads are larger but single-shot. Given the observed four-second death, size is the lesser risk.
Blast radius. Deploying a WAR writes to the application server, may restart the web application, and leaves an artifact the client must be told about. If the app is load-balanced or shared, the deploy may propagate to nodes outside the named target. Confirm with the client which nodes the manager controls before uploading, and prefer an existing deployed application's write path if one exists - it is less invasive and equally demonstrative.
Guardrails. Do not use the persistence modules; the client forbade persistence, and in most scopes installing a service is itself a reportable escalation beyond the authorised objective.
3. Design the cleanup and evidence record for this engagement.
Read the worked answer
Cleanup starts before the successful session, not after it.
Capture before you touch anything. Record the pre-state: the deployed WAR filename, a hash of any file you will replace, the application's original deployment descriptor, service state, and the manager's access log entries generated by your upload. If the WAR replaced or shadowed an existing application, back up the original first.
Removal sequence. Kill every job and close every session (jobs -l, sessions -l, sessions -k) rather than letting a session die on its own - an idle Meterpreter session can outlive the test window and becomes an unauthorised foothold. Then remove the deployed WAR and its exploded directory, confirm the application returns to its pre-test state, and verify there are no artefacts left behind: no scheduled task, no new service, no added user, no modified configuration. Do not run the persistence module at any point, so there is nothing to undo.
Do not clear logs. clearev and similar commands destroy the client's evidence, contradict the audit trail they are paying for, and are typically prohibited outright. Your footprint in their logs is part of the deliverable.
Record. Keep file hashes, timestamps, the exact module and payload used, LHOST/LPORT, and the removal verification, and hand the client a signed cleanup statement. Also record what could not be reverted - a JSP that executed a command, a restarted application - so the client's change board knows what happened.