TL;DR
This post demonstrates how to inspect the network communication between Defender for Endpoint and its cloud services. In this analysis, I identified several issues, including an authentication bypass, data/command spoofing, information disclosure, and the ability to upload malicious files to investigation packages destined for security analysts.
A prerequisite for most of these attacks is obtaining the machine ID of a targeted host and/or the corresponding organization (tenant) ID. Therefore, these attacks are primarily relevant post-breach to impede incident response, obtain configuration information, or target security analysts.
All findings were reported to the Microsoft Security Response Center (MSRC) in July 2025. However, Microsoft has classified all of them as low severity, and it is unknown if they will be fixed.
Introduction
EDR solutions are complex software with a large attack surface. A missing piece in our series on attacking EDRs (Part 1: Attack Surface and Intro to Driver Analysis, Part 2: Driver Analysis Results, Part 3: DoS of EDR agents, Part 4: Fuzzing Defender) is the communication between the agent and the cloud. This post is a part of this research. We will publish findings on other EDRs at a later time.
The only other public research I found on this topic is a post from FalconForce here. They analyzed the web communication by dumping the HTTP requests and responses from memory using a debugger. While this is a cumbersome setup for identifying vulnerabilities, they successfully found an authentication issue related to sending alert data (CVE-2022–23278).
Therefore, I decided to use Burp Suite as a proxy and bypass certificate pinning by patching the validation function in memory.
Analyzing network traffic
Analyzing Defender for Endpoint agent’s network traffic requires some effort because it uses certificate pinning.
The proxy settings used by DFE can be configured via: netsh winhttp set proxy <proxy>:<port>
Afterwards, you will notice certificate errors in the proxy and the agent stops the communication.
In order to debug the MsSense.exe process which performs the communication, I used WinDBG as a kernel debugger (see Part 4: 3.1 Debugging Defender). Using a user-mode debugger would require bypassing the agent’s self-protection features.
To my surprise, there is very little information, write-ups or FRIDA-scripts on how to bypass certificate pinning for native Windows libraries such as Wininet. Therefore, I spent some time reverse-engineering the TLS communication in MsSense and examining example certificate pinning implementations for Windows. I ultimately bypassed the check by patching the CRYPT32!CertVerifyCertificateChainPolicy function:
0: kd> a CRYPT32!CertVerifyCertificateChainPolicy
00007ffe`e1215d20 mov eax, 1
00007ffe`e1215d25 ret
00007ffe`e1215d26
0: kd> u CRYPT32!CertVerifyCertificateChainPolicy
CRYPT32!CertVerifyCertificateChainPolicy:
00007ffe`e1215d20 b801000000 mov eax,1
00007ffe`e1215d25 c3 ret
00007ffe`e1215d26 084989 or byte ptr [rcx-77h],clAfterwards, the plain text communication can be analyzed: 
However, I still observed intermittent certificate errors in the Burp logs. Using TCPView, I noticed that the process SenseIR.exe sometimes starts and opens network connections.
These connections can also be intercepted by patching the following functions:
1: kd> a SenseIR!web::http::client::details::winhttp_client::verify_certificate_chain
00007ff6`081404b0 mov eax, 1
00007ff6`081404b5 ret
00007ff6`081404b6
1: kd> a SenseIR!web::http::client::details::winhttp_request_context::on_send_request_validate_cn
00007ff6`0813c6f0 mov eax, 0
00007ff6`0813c6f5 ret
00007ff6`0813c6f6 Now, all requests can be intercepted including the data upload to an Azure Blob: 
Interestingly, the
CloudLRtokens were still valid three months later at the time of writing this blog post.
Findings
Intercept Commands (Authentication Bypass and Spoofing Data)
The agent regularly sends a request to https://[location-specific-host]/edr/commands/cnc. If a command is available from the backend, the server returns it in the response. These commands are for example: isolationcommand, forensicscollectioncommand, scancommand or incidentresponsecommand.
Empty response
Response command
IMPORTANTAlthough the requests sent by Defender contain an
Authorizationtoken and aMsadeviceticket, the backend completely ignores these values.
Therefore, an unauthenticated attacker who knows the machine-ID and tenant-ID can send valid requests to this URL. These values can be read by low-privileged users on the system. Once the backend sends the command in a response, it will not send it again to subsequent requests. The following two screenshots show the Burp proxy on the left side and an Intruder window on the right that continiously makes requests to /edr/commands/cnc. The Intruder request (first screenshot) obtained the response (second screenshot), so the legitimate request from Defender did not receive a response:
Intruder request
Intruder response
An attacker can then upload arbitrary fake data to the provided Azure Blob URI (sasuri in the screenshot). Some other commands such as isolationcommand can be returned with a request to https://[location-specific-host]/commands/status.
Example Attack: Prevent Isolation and Spoof Result
1. Intercept command: First, intercept the isolation command intended for the target host. 
2. Spoof Response: Next, send a spoofed response with the status Already isolated to the corresponding command ID. 
3. Isolation bypassed: The result is an unisolated device that is reported as ‘isolated’ in the Microsoft Defender Portal. 
The serialization format is annoying, so the easiest approach is to capture a legitimate response using a proxy and then modify it. As of October 10, 2025, I noticed that requests to https://winatp-gw-weu3.microsoft.com/commands/cnc are being throttled by the server. This was not the case in July.
Intercept Actions (Authentication Bypass and Spoofing Data)
This vulnerability is very similar to the previous one (Intercept Commands). It involves a different set of “actions” (e.g., Live Response or Automated Investigation) sent via a different URL (/senseir/v1/actions/) and uses different, but still ignored, authentication tokens.
Same as above, the Intruder window on the right obtains a response which the actual target does not receive. The proxy window on the left also obtains an action but it’s a different one that was returned to this request because the intruder requests were running slowly. Therefore, both obtained a response but the actual target only received one instead of many: 
IMPORTANTAgain, there is no effective authentication. An attacker can obtain a valid
CloudLRtoken without authentication by using just the machine ID.
These actions are encoded using Microsoft Bond. To get an idea of their contents, I used a LLM to write a decoder that could decode the data as much as possible without additional metadata:
Afterwards, an attacker needs to send additional requests to obtain the Azure Blob URL and upload the fake data there:
IMPORTANTIf an investigation package is requested, an attacker could place similarly named malicious files within the uploaded data. It is plausible that an analyst might open them without suspicion.
Unauthenticated IR-Exclusions
An unauthenticated user can obtain IR-exclusions by sending a request to the registration endpoint. These are not detection or prevention exclusions, but rather files and folders excluded from automated or manual IR actions. The organization ID required for this request can be read by any user from the registry.
General Agent Configuration
An unauthenticated request to https://[location-specific-host]/edr/commands/cnc returns an 8MB file of configuration data. While the data does not appear to be tenant-specific, it could provide useful information about detection rules and exclusions. It is unclear how exactly this data is used by the agent, but it contains various configurations:
This includes configurations such as RegistryMonitoringConfiguration, DriverReadWriteAccessProcessList, DriverReadOnlyOpenProcessList, ASR-data, and other information that could be valuable to an attacker.
NOTEDepending on the
cncBitmask, it returns different data
Enumeration done by DFE (InvestigationPackage)
If an investigation was previously triggered on a compromised host, the resulting data package might still be available on the filesystem, and it is readable by any user: 
It contains various types of information that are valuable for an attacke (e.g. Autoruns, installed programs, network connections, …) : 
Conclusion
These findings were straightforward to identify once the web traffic was intercepted. This demonstrates that simple vulnerabilities can remain undiscovered for years in components that are difficult to analyze.
I disagree with MSRC’s assessment that these findings do not warrant remediation. The ability for an unauthenticated attacker to impede the incident response process post-breach should be addressed. Furthermore, the risk of security analysts being targeted with malicious files via investigation packages is significant. The agent uses three different types of authentication tokens, yet all of them are either ignored by the backend or obtainable without any real authentication.