HTTP reverse shell through corporate proxy

Question

I'd like to test a scenario where the user receives a mallicious attachment in a phishing email. The attachment is intended to open an HTTP or HTTPS reverse shell to the attacker who sits outside of the corporate network. The network topology looks like this:

Attacker --- Internet --- Firewall --- Proxy --- Victim

The firewall blocks every outbound traffic except web browsing through proxy and DNS requests. The proxy uses authentication.

As I've red through numerous post in this topic, i've got the impression that a basic metasploit reverse http meterpreter shell would do the trick in this environment, but I'm curious how the reverse shell could go through the proxy? First of all how does it detect that there is a proxy and what is its address?

It's maybe kind of a noob question. My only idea is that if the proxy settings are set in the registry, Windows routs all the HTTP and HTTPS traffic toward the proxy transparently.

Answer 1

How does the shell detects what is the proxy and its address?

It does it the same way as any other applications on your OS. On Windows an application can check registry settings for IE proxy, and get relevant proxy settings from other browsers. Or it can use Wininet API, which would handle proxies automatically (including things like NTLM authentication).

On Linux it can check the env variables such as "http_proxy".

A less typical, but still possible ways would be to do port scan (proxy typically listens on 3128 or 8080), or watch the traffic for proxy connection requests.

How does the reverse shell executes the commands?

There are several ways. For example, a reverse shell script/binary can do HTTP GET example.org/cmd.html, pass everything to a shell/powershell/Python, save the output of the executed shell to file, and POST it to example.org/output - those requests are valid HTTP requests, and will go through HTTP proxy. This will not work for interactive shell (for example using vi), but it is not really needed for an attack.

To build on top of that, the commands and responses could be encrypted with a symmetric key (thus making signature-based detections impossible), or could be embedded into regular traffic (for example into EXIF tag of an image).

However if the proxy supports HTTPS proxying through CONNECT command, it is much simpler. A reverse shell then issues CONNECT example.org:443 and has a direct TCP connection through the proxy, which could be used for a direct shell access (including the interactive shell).