Microsoft Defender for Endpoint: Am I missing something?

Nixu's Digital Forensics and Incident Response (DFIR) team has been using the Microsoft Defender for Endpoint tool in investigating security incidents for some time now. There has been an underlying feeling that not all events are recorded by the tool which has led to further research to see what is being left out. However, this post is not going to cover all the cases where the telemetry data is missing from the Microsoft Defender for Endpoint.

File creations

One of the investigated incidents included the creation of files in the Windows temp folder (c:\windows\temp), which has a .tmp abbreviation. There was another security tool installed on the same device which had recorded the creation of these files, so it was a bit baffling why these were not shown in MDE. The first thought was that all file creations in the temp folder with the .tmp abbreviation were left out. However, running the following KQL query while using the Microsoft Defender for Endpoint Advanced Search feature seemed to give a clearer picture:

DeviceFileEvents

| where FolderPath =~ @"c:\windows\temp"

| summarize count() by ActionType

The only Action Type for file activity in the Windows Temp folder which was recorded was "File Deleted". This was tested in a lab environment, and, sure enough, there were no other Action Types recorded.  This was also tested for the other Windows temp location, %userprofile%\AppData\Local\Temp, and it seems like the events are correctly recorded when writing to the temp folder located under the user profile.

DLL image loads

On another occasion, one of the LOLBASes was investigated – pcwutl.dll (https://lolbas-project.github.io/lolbas/Libraries/Pcwutl/). This can be used to launch binaries. It seemed like the DLL image load event was missing from MDE. To verify the finding, rundll32.exe was used to launch a binary by loading the pcwutl.dll in a lab environment:

rundll32.exe pcwutl.dll,LaunchApplication %windir%\System32\notepad.exe

Interestingly, there were no results returned in the DeviceImageLoadEvents table, as was verified with the following KQL query:

DeviceImageLoadEvents

|where FileName =~ "pcwutl.dll"

Now the same query was run in a production environment, and no results were observed. This could of course be because the DLL was not loaded even once. However, as that is very unlikely, the following KQL query was run:

DeviceProcessEvents

| where ProcessCommandLine contains "pcwutl.dll"

| take 10

This query produced the expected results. In total, there were tens of occasions where the pcwutl.dll was loaded according to the process commandline. For some reason, it seems like this particular DLL load is left out from the DeviceImageLoadEvents table. This appears to be true with some of the other LOLBASes as well, for example url.dll and syssetup.dll. It seems like these are only left out if the process rundll32.exe is loading them, but if other processes load these DLL's, the event is recorded. However, for some of the other LOLBASes, like shell32.dll, image loads ARE being recorded in the DeviceImageLoadEvents table even if loaded by rundll32.exe.

Named pipes

For some reason, Named Pipe creations seem to produce varying results as well. The following KQL Query against DeviceEvents table in MDE should produce all of the named pipe creation events:

DeviceEvents

| where Actiontype == "NamedPipeEvent"

Yet, no results are received in some MDE environments. No apparent reason was found why in some tenants the query does produce results while in others no results are received. Furthermore, in the environments that do get results, some events are still missing, such as psexec.exe which is not generating any Named Pipe events. Given that this feature was added to MDE fairly recently in August, it is likely that it has not been rolled out yet to all tenants or that it is related to the Windows 10 version/configuration.

We haven't been able to find any documentation or public communication from Microsoft which would state why this event is not populated in some environments.

LDAP queries

Defender for Endpoint can save the LDAP queries sent by the endpoint, which is an amazing feature. However, while investigating an incident, it was noted that these are not saved from all the processes which initiate the queries. Running the same LDAP queries while using three different tools (dsquery.exe, PowerShell, and Active Directory Users and Computers) produced results only for PowerShell and ADUC. There were no results recorded for dsquery.exe, although the queries were successfully executed, and they were able to return the queried information from the Domain Controller.

Conclusion

The currently observed missing events might not sound like they are a huge issue. But – what if the missing data is vital for an investigation? We've observed an incident where it was likely that the Windows temp folder was used to collect data for exfiltration purposes, and several files were created inside this folder. These file creation events were missing entirely from the MDE. This also makes us think: What else is missing?

There are other Endpoint Detection & Response software out there that have similar issues. They don't record all of the file creation events. However, so far, the vendors have been able to disclose what is being left out. In this case, we haven't been able to find any documentation stating what is not being recorded. It is not necessarily the biggest issue if the information of what is left out could be acquired.

Detection Engineer Olaf Hartong has written a fantastic article on telemetry, comparing Sysmon to MDE. The article goes much deeper into the subject and is available here.

Authors: Nixu DFIR team members, Jouni Mikkola & Mika Kontio

Interested in optimizing your company's security level? Contact us! You can also download our whitepaper to learn more about Managed Endpoint Detection and Response.