This article is a follow-up to a previous one discussing conflicting proxy configurations and how Microsoft Defender for Endpoint behaves in these situations. The first article can be found in here.
As outlined in the documentation, Defender for Endpoint supports three different types of proxy configurations:
- A static proxy configuration pushed through GPO or registry changes,
- WinINET proxy through user sessions,
- WinHTTP proxy through the SYSTEM account.
However, when these configurations are mixed, it can cause confusion as to which proxy configuration is being used. To understand the path that Defender for Endpoint is taking, it is recommended to use the Client Analyzer script found here.
The setup
In order to test the different configurations, I’ve set up three different proxy servers and a Windows 11 workstation in a lab environment.
- WORKSTATION (172.16.11.92/32) – Workstation for tests
- PROX01 (172.16.12.10/32) – Receives WinHTTP configured traffic (SYSTEM)
- PROX02 (172.16.12.11/32) – Receives WinINET configured traffic (User session, unauthenticated)
- PROX03 (172.16.12.12/32) – Receives Static Proxy configured traffic (TelemetryProxyServer)
- As it’s unsupported to decrypt Defender for Endpoint traffic we’ll just be looking at which proxy server the endpoint is communicating with to determine the proxy server being chosen.
- All traffic for the workstation is blocked at the gateway except for that which uses the proxy servers above.
- The Client Analyzer will be executed between each of the tests.
- A live response session will be initiated from security.microsoft.com.
Test – Only the WinHTTP Proxy is configured
Enabled outbound traffic via WinHTTP (PROX01) server on WORKSTATION. Test connectivity via a Live Response session and monitored traffic from PROX01 through gateway.
Live Response Session successful:
Validate incoming traffic over PROX01 in gateway:
MDE Client Analyzer Results:
When you’re initially deploying Defender for Endpoint in a disconnected environment, the client analyzer script is the best tool to help diagnose networking issues. As you can see from the screenshot above, the test results are positive. Let’s break them down:
|
Result |
Breakdown |
|
Proxy config: Method=NamedWinHttp, address=172.16.12.10:3128 |
A WinHTTP proxy has been detected on the endpoint and configured with the address listed. |
|
1 - Default proxy: Succeeded (200) |
If at least one of the connectivity options returns status (200), then Defender for Endpoint sensor can properly communicate with the tested URL using this connectivity method. |
|
2 - Proxy auto discovery (WPAD): Succeeded (200) |
Same result as above |
|
3 - Proxy disabled: Failed (12002: WinHttpSendRequest: 12002: The operation timed out) |
The proxy is not disabled. |
|
4 - Named proxy: Doesn't exist |
The static proxy is not configured |
|
5 - Command line proxy: Doesn't exist |
Not configured |
Test – Which one wins? WinINET or WinHTTP?
Now that we’ve confirmed we have an internet connection via WinHTTP proxy settings let’s add a separate WinINET configuration into the mix for our user account and see which proxy Defender for Endpoint will prefer for communication. We’ll leave our user logged in for this test.
We can see that Defender for Endpoint still prefers the WinHTTP proxy over the WinINET:
Our Live Response session initializes correctly and goes through the WinHTTP proxy connection. When we have both a WinHTTP and WinINET configuration it appears that the WinHTTP proxy takes precedence for Defender for Endpoint connections. This makes sense as the service is running as the SYSTEM account.
Test – WinINET proxy configuration only
As outlined in the article here, a WinINET proxy configuration without a logged an active user session will not allow Defender for Endpoint to connect. It will instead cache and upload signals once a when a user logs in and establishes a proxy connection via WinINET.
The following is a test of a live response session on the workstation while no user is logged in and monitoring traffic. The result is that no traffic from Defender for Endpoint is detected and the Live Response session times out as expected:
We can also confirm there is no communication by checking the timeline. The user was logged out at 11:50am as demonstrated below.
Once a user has logged in, we can validate the timeline and see that events start to get uploaded through the proxy as the cache is emptied.
Often in disconnected environments we’ll see a WinINET proxy for user session activities and a static proxy for specific services.
In this situation the only proxy currently configured on the computer is WinINET. Most of the Defender for Endpoint functionalities will be available. Live Response is the only one that will not work with the standalone WinINET configuration.
You’ll see a session timeout. However, when combined with a Static Proxy configuration (via GPO or Registry) all the services will work appropriately even when a user is not logged in. The specific proxy can be used for Defender for Endpoint services and no change is required on the user experience.
Live Response session timeout over WinINET:
You can see from the client analyzer results below that only some of the URL endpoints are reachable over a “WinINET only” proxy configuration:
In this case, we won’t get the complete experience out of Defender for Endpoint as only the SampleUpload and MdeConfigMgr service URLs are reachable.
Test – Static proxy configuration only
As you can imagine, this scenario will work fine for the workstation and Defender for Endpoint configuration/communications. As this is a static proxy assigned to both the Telemetry service (for Endpoint Detection & Response) and the Defender for Endpoint anti-virus, no other internet access will be available for the workstation. This is a great setup scenario for disconnected environments or servers as the users connecting to these endpoints should not have or do not require internet access.
After applying the static proxy settings and rebooting the workstation we can already start seeing inbound traffic on PROX03:
Live Response is functional as well:
The Defender for Endpoint configuration works as expected. Again this is a good use case in a scenario where nothing else on the machine has internet access, that includes Windows Update.
Test – WinINET, WinHTTP and Static Proxy configuration. Which one wins?
Let’s have some fun. Now we’ll configure the static proxy, the WinHTTP proxy, and the WinINET proxy and observe the traffic flow through the gateway to understand which proxy configuration will be preferred.
We can see that the Live Response session that’s initialized still uses the Static Proxy (to be expected):
User based services primarily using the WinINET proxy configuration:
And all other SYSTEM level services utilize the WinHTTP configuration:
Let’s look at the Client Analyzer results:
Summary
Ultimately, if you are looking for good user experience on a workstation in a disconnected environment and to provide full feature availability to your Security Operations Center (SOC) team, using a combination of WinINET and Static Proxy will offer the most feature-rich experience without impacting existing configurations in your environment. Hopefully, the tests above will help you gain a better understanding of what to expect from Microsoft Defender for Endpoint, given your configuration.
Resources
Disconnected environments, proxies and Microsoft Defender for Endpoint
Download the Microsoft Defender for Endpoint client analyzer | Microsoft Learn