Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog Product updates

Validating Microsoft Defender for Endpoint alerts

Learn how Red Canary uses the Microsoft Defender for Endpoint API to validate alerts, and apply the same technique to relieve your infosec team’s alert fatigue.

Matthew Tanous
Originally published . Last modified .

Modern security professionals have more responsibilities than ever. Keeping up with the influx of information from various security products throughout an organization creates a monumental task for small teams, who often carry many internal infosec-related responsibilities. Any opportunity to save time and improve efficiency is worth the investment. Red Canary uses the Microsoft Defender for Endpoint API to validate alerts for our customers, freeing up their teams to tackle more impactful work.

At Red Canary, we retrieve alerts, correlate those alerts to raw endpoint telemetry collected from Defender for Endpoint, analyze correlated information in our 24/7 CIRT (Cyber Incident Response Team) and finally communicate confirmed threats to our customers. Your security team can take a similar technical approach by using the APIs to manage alerts and add additional context before importing them into whatever platform you’ve chosen for your environment.

Familiarizing yourself with the platform

To get familiar with the data available in Defender alerts, start by reviewing them in the Microsoft Defender Security Center console. Alerts contain useful information like users, network connections, and file metadata.

Microsoft Defender Security Center console

You can use the Defender APIs to periodically get the list of recent alerts along with any associated information, including users, network information, and file metadata. First, you will need to authenticate with the Microsoft Defender for Endpoint API. This can be done with a configured user or application context. Application Context is best suited for background services or daemons, whereas User Context is used to perform actions in the API on behalf of a signed-in user. For this example, we authenticate using an application context.

Microsoft Defender for Endpoint leverages OAuth 2.0 for authentication. After the authentication process, Defender for Endpoint issues an access token that your application will use to access the API.

Defender for Endpoint authentication and access token example

Once you have an access token, you can fetch the list of alerts from the Defender Alert API. For more examples on fetching alerts, as well as a comprehensive digest of the Defender for Endpoint API Schema, visit the Microsoft Defender for Endpoint API Schema and Fetch Alerts examples documentation page.

After getting the list of alerts, you can iterate through them to get additional information about each alert, such as endpoint metadata or related files and network information.

Fetching alerts from Defender Alert API

Once you have these alerts, you’ll want to parse them to extract the information that is important for correlating to your other data sources. This information can then be collected into a standardized alert model that can provide a set way of handling the information. A simple way to build such a structure is to create a struct class that contains what information you want to record from each alert:

Creating a struct class containing info to record from each alert

If the alert includes identifying process information like process ID and process creation time, you can often directly correlate the alert to telemetry data without further investigation. In cases when the alert does not include process data, you can use the Advanced Hunting tools in Defender to find related telemetry. Advanced Hunting leverages a separate schema from the Defender API and queries can be run through the Defender portal, or via API. More information on Advanced Hunting, KQL, and the Advanced Hunting Schema is available on the Advanced Hunting documentation page.

Microsoft Defender Security Center console, Advanced Hunting documentation page

Advanced hunting example

An easy way to leverage Defender for Endpoint to automatically generate an Azure Kusto query (KQL) for the relevant information is simply to pivot from an alert to the related incident and view the Evidence tab. From this view, you can select any related file or process and click Go Hunt to automatically generate and run the relevant Advanced Hunting query.

Learn more about how Red Canary analyzes alerts and detects threats using Defender for Endpoint endpoint telemetry here.

 

Red Canary coverage of Google Cloud Platform enters general availability

 

Teaming with Microsoft Copilot for Security

 

Introducing Red Canary’s multicloud launch

 

Red Canary brings MDR expertise to Microsoft Azure Cloud

Subscribe to our blog

 
 
Back to Top