Defender for Endpoint and disconnected environments. Which proxy configuration wins?

News Informatique

Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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:

  1. A static proxy configuration pushed through GPO or registry changes,
  2. WinINET proxy through user sessions,
  3. 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.

  1. WORKSTATION (172.16.11.92/32) – Workstation for tests
  2. PROX01 (172.16.12.10/32) – Receives WinHTTP configured traffic (SYSTEM)
  3. PROX02 (172.16.12.11/32) – Receives WinINET configured traffic (User session, unauthenticated)
  4. PROX03 (172.16.12.12/32) – Receives Static Proxy configured traffic (TelemetryProxyServer)
  5. 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.
  6. All traffic for the workstation is blocked at the gateway except for that which uses the proxy servers above.
  7. The Client Analyzer will be executed between each of the tests.
  8. 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:

thumbnail image 1 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

Validate incoming traffic over PROX01 in gateway:

thumbnail image 2 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

MDE Client Analyzer Results:

thumbnail image 3 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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:

ResultBreakdown
Proxy config: Method=NamedWinHttp, address=172.16.12.10:3128A 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 existThe static proxy is not configured
5 – Command line proxy: Doesn’t existNot 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:

thumbnail image 4 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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:

thumbnail image 5 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

We can also confirm there is no communication by checking the timeline. The user was logged out at 11:50am as demonstrated below.

thumbnail image 6 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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.

thumbnail image 7 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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:

thumbnail image 8 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

You can see from the client analyzer results below that only some of the URL endpoints are reachable over a “WinINET only” proxy configuration:

thumbnail image 9 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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:

thumbnail image 10 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

Live Response is functional as well:

thumbnail image 11 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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):

thumbnail image 12 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

User based services primarily using the WinINET proxy configuration:

thumbnail image 13 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

And all other SYSTEM level services utilize the WinHTTP configuration:

thumbnail image 14 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

Let’s look at the Client Analyzer results:

thumbnail image 15 of blog post titled 
	
	
	 
	
	
	
				
		
			
				
						
							Defender for Endpoint and disconnected environments. Which proxy configuration wins?

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.

Source

Microsoft Defender for Endpoint and disconnected environments

No Comments

Add your comment