Bypassing Web Proxies
When dealing with proxy servers, we should first ensure that our payload
is proxy-aware.
When our payload tries to connect back to the C2 server,
it must detect local proxy settings, and implement those settings
instead of trying to connect to the given domain directly.
Fortunately, Meterpreter’s HTTP/S payload is proxy-aware,
thanks to the InternetSetOptionA API, so we can leverage that.
Armed with a proxy-aware payload,
we must consider many of the protection mechanisms implemented
by the web-proxy filter.
We must ensure that the domain and URL are clean
and that our C2 server is safely categorized
as defined by our client’s policy rules.
If the client has deployed a URL verification or categorization system,
like those provided by Cyren, Symantec Bluecoat, or Checkpoint,
we should factor their policy settings into our bypass strategy.
Lets perform a Bluecoat categorization lookup.
The output indicates that the
makehamburgers.com domain is uncategorized.
If we were using this as our C2 server,
we should follow the prompts to categorize it
according to the company’s allowed use policy,
since an unnamed domain will likely be flagged.
We could also grab a seemingly-safe domain
by hosting our C2 in a cloud service or Content Delivery Network (CDN),
which auto-assigns a generic domain.
These could include domains such as cloudfront.net,
wordpress.com, or azurewebsites.net.
These types of domains are often auto-allowed
since they are used by legitimate websites and hosting services.
Now that we’ve considered our payload and C2 server domains and URLs,
we can consider the traces our C2 session will leave in the proxy logs.
For example, instead of simply generating custom TCP traffic on ports 80 or 443,
our session should conform to HTTP protocol standards.
Fortunately, many framework payloads, including Metasploit’s Meterpreter,
follow the standards as they use HTTP APIs like HttpOpenRequestA.
We’ll also need to ensure that we set our User-Agent
to a browser type that is permitted by the organization.
For example, if we know that the organization we are targeting uses
Microsoft Windows with Edge, we should set it accordingly.
In this scenario, a User-Agent for Chrome running on macOS will likely raise
suspicion or might be blocked.
In order to determine an allowed User-Agent string,
we should consider social engineering
or we could sniff HTTP packets from our internal point of presence.
Additionally, we could use a 'site like whatismybrowser.com
to build the string or choose from a variety of user-supplied strings.
Here we analyzed an Edge-based User-Agent
and received detailed information about the client.
Besides the browser, we also got information about the operating system,
its version number, the engine of the browser, and much more.
If we don’t know what is being used,
we can always check the exact value ourselves with a packet capture.
Once we have selected a User-Agent string,
we can apply it to our framework of choice.
For example, we can set our custom User-Agent in Meterpreter
with the HttpUserAgent advanced configuration option.
In this section, we discussed web proxies,
how they are similar to DNS filters,
and how similar approaches help us bypass these filters.
We also touched briefly on the HTTP protocol standard
and discussed why it’s important to follow it in our payload.
In the next section, we’ll discuss IDS and IPS sensors.