I spend a lot of time thinking about what my tools can and can’t do. One of the weakest points for penetration testing tools is their (in-)ability to get past some egress restrictions. I previously wrote about why this is a problem and how you might get past different egress restrictions.
My general advice is this: reverse TCP payloads are a dead option. HTTP and HTTPS payloads are fine for transparent proxies or proxy servers that use NTLM authentication. Use DNS as an egress channel otherwise. If DNS fails you, then you’re out of luck.
Keep in mind, this advice assumes a hardened target.
My general advice isn’t bad, but it falls short in this situation: What happens if your target sets up a proxy server that requires the user to authenticate with a separate set of credentials to get out to the internet. Further, let’s assume that these workstations are otherwise isolated from the internet and they also can’t resolve DNS names for external systems. What do you do in this situation?
Recently, I decided to look into this problem. Here’s what I found:
WinINet is the Windows Internet API and it’s the library that manages the cache, credential store, and communication for Internet Explorer and other applications. If you configure a proxy server in Internet Explorer, WinINet applications will communicate through it.
When WinINet connects to a URL (through a proxy server), it first checks its credential store for a username and password. If there is no value in this credential store, WinINet will attempt to get the URL through the proxy server.
If the proxy server requires authentication, WinINet will get a 407 Proxy Authentication Required response from the server. What happens next is up to the program that made the WinINet call.
If that program is Internet Explorer, the user will see a dialog where they are asked to enter their username and password for the proxy server. The user also has an option to check the Remember my credentials box. This option will put the username and password into the credential store.
The proxy username and password, when stored in the credential store, are available to any application that runs as the current user. If my target uses Internet Explorer and uses the Remember my credentials option to save retyping, then Meterpreter and Beacon get a free pass to authenticate and communicate through the configured proxy server—no code changes required. Better, these remembered credentials survive a reboot too.
It’s possible for a network administrator to change this behavior though. There is a GPO to disable storage of passwords and credentials for network authentication. When this option is set to enabled, the user will see the same dialog as above. The user will even see the Remember my credentials option. The main difference is that the automatic authentication will only happen for the current application. When the current application closes, the proxy username and password go with it. The user will have to re-authenticate to the proxy the next time they run that application.
Google Chrome and Mozilla Firefox use WinINet to get ahold of proxy settings, but they manage proxy authentication on their own. The behavior of Google Chrome and Mozilla Firefox is similar to Internet Explorer with the disable storage of passwords and credentials for network authentication option turned on.
If you’re worried about establishing a communication channel, through a proxy server, what does all of this mean to you?
If your target uses Internet Explorer (*cough*System Profiler*cough*) and this GPO is not enabled (it’s off by default)—then you likely have a free pass through the target’s configuration.
If your target uses Google Chrome, Mozilla Firefox, or the network authentication GPO is enabled, then you have a little more work to do.
Beacon and Meterpreter’s HTTP stagers use WinINet to communicate. If either of these go through a proxy server without the credentials to authenticate to it, then they will fail. Neither of these stagers know how to prompt the user for their credentials in the same way Internet Explorer does it.
Fortunately, the above problem isn’t too hard to solve. Microsoft provides an API to analyze an HTTP response for “hidden errors”. A 407 HTTP response is an example of a hidden error. The same API will also prompt the user with the appropriate dialog to get the information it needs, fix the request, and allow the application to retry the request. The magical function that does all of this is InternetErrorDlg.
In the most recent release of Cobalt Strike, I updated Beacon’s HTTP stager to use InternetErrorDlg to find and correct hidden proxy authentication errors. This little change now allows Beacon’s HTTP stager to get through authenticated proxy servers very reliably. If credentials for the proxy server are in memory, this updated stager will use them like before. If there are no credentials in memory, this updated stager will prompt the user with the same dialog Internet Explorer uses. Once the user puts in their credentials, Beacon’s HTTP stager gets a free pass to the internet.
Pretty cool.