Using Microsoft Defender for Endpoint during investigation

Posted on May 14, 2021 by m365guy One comment

Today I’m going to blog about Microsoft Defender for Endpoint, but with the primary goal of investigation. During cases like incident response for example. It can be useful to have an EDR in place, that helps to automate the common tasks, and provide visibility in the process execution layer.

Microsoft Defender for Endpoint is a Cloud delivered EDR solution that includes features like threat & vulnerability management, live response, advanced hunting, and many others.

In this blog post, we are going to demonstrate a scenario and show a few examples of features in Defender for Endpoint, that can be leveraged during a security investigation.

Introduction

At the introduction part of this blog post. We are going to describe a made up scenario of an organization called ”Contoso” that has been targeted by an APT group. A threat group had access to Contoso’s corporate network. We need to investigate all the affected systems and remediate the attack. How can we achieve this with the help of Microsoft Defender for Endpoint?

Scenario

Contoso has reached out to us that they have been targeted by attackers. They have noticed some strange things that didn’t looked good, which is the reason why they reached out. The environment has one single Active Directory domain and all the machines are running on Windows 10 & Windows Server 2019. They don’t have any third-party EDR solution installed on their endpoints, and as many other organizations. There is no central logging and alerting in place.

What will you learn?

How to roll out Defender for Endpoint at scale?
How to initiate an automated investigation?
How to collect an investigation package from a device?
How to hunt in data based on the investigation package?
How to use live response session?

Rolling out MDE on all the endpoints via Group Policy

As discussed earlier, it is so useful to have visibility on all the endpoints. When investigating a security incident, you want to have this in place. Since that is the case, we are going to roll out Microsoft Defender for Endpoint on all the workstations and member servers via GPO.

The first thing we have to do is to install the onboard package via the M365 Security portal. In order to do this, we need to do the following:

Go to the Microsoft 365 security portal
Click on “Settings”
Click on “Onboarding”
Select “Group Policy” at Deployment method

2. We have to extract the content of the onboard package and save it on a location (e.g. file share) with read-only access to all the devices. Here is an example on how you could do it.

Create a folder and name it “MDE”
Click on “Sharing”
Ensure that “Authenticated Users” and “Domain Computers” have read access
Save the content of the extracted onboard package in the folder.

Verify the permission and see if you can access the shared folder.

3. Now we have to configure our Group Policy and roll the onboard package on the OUs that contains the workstations and member servers.

Create a Group Policy Object and give it a name that you prefer.

In the Group Policy Management Editor, go to Computer configuration, then Preferences, and then Control panel settings.

Right-click Scheduled tasks, point to New, and then click Immediate Task (At least Windows 7).

In the Task window that opens, go to the General tab. Under Security options click Change User or Group and type SYSTEM and then click Check Names then OK. NT AUTHORITY\SYSTEM appears as the user account the task will run as.

Select Run whether user is logged on or not and check the Run with highest privileges check box.

Go to the Actions tab and click New… Ensure that Start a program is selected in the Action field. Enter the file name and location of the shared WindowsDefenderATPOnboardingScript.cmd file.

If you have done everything correctly, the scheduled task should look like the following:

At the Actions tab, we should have something that looks like the following:

When we are selecting a program or script that we want to run. We have to specify the exact path of where the .cmd file is located, which may look like the following:

\\APD-DC1\mde\WindowsDefenderATPOnboardingPackage\WindowsDefenderATPOnboardingScript.cmd

4. We now have to link the GPO to the OU that has the workstations.

5. The last thing is to do the same for all the member servers. There is a separate onboard packages for workstations and member servers, but at the end of the day. It is just installing the other onboard package. All the steps are the same.

Receive and respond to alerts

Once we installed Defender for Endpoint on all the workstations and member servers. We now have visibility over all our endpoints. This allows us to receive alerts once an adversary is making a mistake, which can lead to triggering an alert. This is the main reason why we are deploying an EDR solution, because it will help us to identify which device on the network may have been compromised.

As an example, we have received a couple of alerts in a pretty short time of period. Let’s investigate on which devices this alerts has been triggered.

In this example, we can see two devices that have a high risk level. This could be the first pivot point from our investigation to gather more context.

Initiate automated investigation

The first thing is to keep it simple, which is by using the automated investigation response (AIR) capabilities of Microsoft Defender for Endpoint. Automated investigation response uses various inspection algorithms to discover malicious activities on a device, and it does automated remediation. The capabilities of AIR significantly reduce alert volume, allowing security operations to focus more on the other high-value initiatives.

This feature is useful when there is a Medium or High alert on a device for example. Examples of remediation actions include sending a file to quarantine, stopping a service, removing a scheduled task, and more.

Once the automated investigation response has been finished. It will display an investigation graph with all the necessary information such as which, file, process or service has been remediated. In this case, there was one process that just got remediated. I can really recommend organizations start using this more, because it automates the common tasks.

Collecting investigation package

In the second phase, after we finished running automated investigation response. We should start looking manually on an affected device, because there is a chance that AIR didn’t remediated an entity that was considered ”malicious” under our eyes.

There is an investigation package that we can collect from an affected device to get a better understanding of the current state of the device. This includes which (persistence) techniques may have been used to remain persistent.

Hunt in data based of the investigation package

After we have collected our investigation package. It will return a ZIP file, which we can extract. This includes different information about what processes were running, scheduled tasks, programs installed on a machine, services that are running, and so on.

We are now going to ingest data into Azure Data Explorer, which will be all the CSV files that we just extracted from the ZIP file. If you get an error when ingesting CSV files into an ADX cluster. Change the Data Format Type to “TSV” and uncheck the “Ignore the first record” box.

This section will be just a couple of examples on querying the datasets and parse the different fields into columns to make it readable for an analyst.

When we select a table, let’s say the scheduled tasks. It will return one column with an incredible long column name. It is stored in an unstructured format, which makes it difficult to read it properly.

Scheduled Tasks

In this example, we are going to query the dataset that contains all the data of all the scheduled tasks that have been configured on a machine.

Query

ScheduledTasks
| extend data = parse_csv(['HostName___TaskName___Next Run Time___Status___Logon Mode___Last Run Time___Last Result___Author___T'])
| extend HostName = data [0]
| extend TaskName = data [1]
| extend NextRunTime = data [2]
| extend Status = data [3]
| extend LogonMode = data [4]
| extend LastRunTime = data [5]
| extend LastResult = data [6]
| extend Author = data [7]
| extend TaskToRun = data [8]
| extend StartIn = data [9]
| extend Comment = data [10]
| extend ScheduledTaskState = data [11]
| extend IdleTime = data [12]
| extend RunAsUser = data [14]
| extend StartTime = data [18]
| extend StartDate = data [19]
| extend EndDate = data [20]
| extend Months = data [21]
| project-away ['HostName___TaskName___Next Run Time___Status___Logon Mode___Last Run Time___Last Result___Author___T'], data

Result

At the sample result, we are able to see all the details regarding a configured scheduled task.

We are now going to look for scheduled tasks that are enabled and only select a few columns that we think are interesting.

Query

ScheduledTasks
| extend data = parse_csv(['HostName___TaskName___Next Run Time___Status___Logon Mode___Last Run Time___Last Result___Author___T'])
| extend HostName = data [0]
| extend TaskName = data [1]
| extend NextRunTime = data [2]
| extend Status = data [3]
| extend LogonMode = data [4]
| extend LastRunTime = data [5]
| extend LastResult = data [6]
| extend Author = data [7]
| extend TaskToRun = data [8]
| extend StartIn = data [9]
| extend Comment = data [10]
| extend ScheduledTaskState = data [11]
| extend IdleTime = data [12]
| extend RunAsUser = data [14]
| extend StartTime = data [18]
| extend StartDate = data [19]
| extend EndDate = data [20]
| extend Months = data [21]
| project-away ['HostName___TaskName___Next Run Time___Status___Logon Mode___Last Run Time___Last Result___Author___T'], data
| where ScheduledTaskState == 'Enabled'
| project HostName, TaskName, TaskToRun, RunAsUser, LastRunTime

Result

At the sample result, we can see all the enabled scheduled task. Including the task name, etc.

Processes

We can do the exact same thing for processes as well, so here we are running a query to find all the processes that were running during the time we collected our investigation package.

Query

Processes
| extend data = parse_csv(Node_Caption_CommandLine_CreationClassName_CreationDate_CSCreationClassName_CSName_Description_Execu)
| extend Node = data [0]
| extend Caption = data [1]
| extend CommandLine = data [2]
| extend CreationClassName = data [3]
| extend CreationDate = data [4]
| extend CSCreationClassName = data [5]
| extend Description = data [7]
| extend ExecutablePath = data [8]
| extend ExecutionState = data [9]
| extend Handle = data [10]
| extend OSName = data [18]
| extend ParentProcessId = data [25]
| extend ProcessId = data [31]
| project-away Node_Caption_CommandLine_CreationClassName_CreationDate_CSCreationClassName_CSName_Description_Execu, data

Result

At the sample result, we can see all the active processes that were running.

Running these long queries can be annoying, but that’s because how the schema is build of the exported datasets. The good thing is that you can save them, so you only need to type it once.

Live Response session

Live Response is a feature in Defender for Endpoint that provides security analysts a remote shell connection to access a device. This allows a security analyst to perform in-depth investigation on an affected device.

First, we need to ensure that the following settings are enabled.

After we have enabled these two settings, we can start initiate a live response session on an affected device.

Now we are going to share a few examples of the thins that we may consider looking at, when doing investigation on an affected device.

Investigation on affected device

In this example, we are going to show a couple of examples with the Live Response feature in Defender for Endpoint. We are going to look for information that wasn’t included at the investigation package, but may have been relevant to us from a defenders perspective.

Windows Defender AV – Exclusions

Yes an attacker can disable Windows Defender AV, which will ring bells like a Christmas tree. However what if they would create folders and exclude it from AV? This means that everything, that is ran from a specific folder won’t get flagged by AV.

We are now going to look for files and folders that may have been excluded from Windows Defender AV.

Command

registry "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths"

Result

At the sample result, we can see two folders that have been excluded from Windows Defender AV.

We should not just look at the files & folders exclusions, but also the extensions and processes.

File types exclusions are stored in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Extensions

Processes exclusions are stored in:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Processes

Result

At the sample result, there were no file types and process exclusions.

Remediation: Windows Defender AV – Exclusions

We can do live remediation as well and remove an excluded folder for example. In this example, we will remove the C:\APT41 folder from Defenders AV exclusion.

Command

remediate registry "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths\\C:\APT41"

Result

At the sample result, we just remediated it. The folder has now being removed from the Windows Defender AV exclusion.

PowerShell activities

When we receive alerts such as ”Suspicious PowerShell”, we can use that as a pivot point. By default, PowerShell in Windows 10 saves the last 4096 commands that are stored in a plain text file located in the profile of each user.

Every file is named as “ConsoleHost_history.txt”

Command

findfile ConsoleHost_history.txt

Result

At the sample result, we can see two user profiles.

Download file

We can download the file as well to do further analysis.

Command

getfile c:\Users\Colby\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

Result

At the sample results, we can see a couple of commands the particular user has ran.

Disabling PowerShell logging

Attackers are aware that the default PowerShell logging is pretty solid, and since they may rely on using PowerShell based tools in their operations. There is a chance that they will disable PowerShell logging.

By the time this was tested, Windows Defender AV or Defender for Endpoint didn’t alert on it.

PowerShell logs are stored at the following location in Event Viewer:

Windows PowerShell: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Windows PowerShell
Microsoft-Windows-PowerShell/Operational: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PowerShell/Operational

First, we will review if the Windows PowerShell log name has been disabled.

Command

registry "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Windows PowerShell"

Result

At the sample result, we can see that a registry value was configured to disable logging.

The second thing is to review the Microsoft-Windows-PowerShell/Operational log name.

Command

registry "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PowerShell/Operational"

Result

At the sample result, we can see the “Enabled” registry value has been set to 0. This means that logging has been disabled.

WMI Persistence

An event consumer represents the action to take upon the firing of an event. Attackers can use the ActiveScriptEventConsumer and CommandLineEventConsumer classes when responding to their events. Both event consumers offer a tremendous amount of flexibility for an attacker to execute any payload they want all without needing to drop a single malicious executable to disk.

All the WMI activities on a machine are stored at: Microsoft-Windows-WMI-Activity/Operational – If we want to grab a copy of the logs. We need to look at the following location:

C:\Windows\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx

First, we are going to run a command to see if it is really located at the above mentioned location.

Command

fileinfo C:\Windows\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx

Result

At the sample result, we can see that it does.

Download WMI activity log file

We are now going to download the WMI Activity log file of the affected device to do further analysis.

Command

getfile C:\Windows\System32\winevt\Logs\Microsoft-Windows-WMI-Activity%4Operational.evtx

Result

Once the file has been downloaded, we can import it our own Event viewer. When we filter on Event ID 5861. It provides a lot of visibility, which may lead to an attacker rolling out a WMI persistence on a device.

In this example, the affected device should already be isolated from the network. However, an analyst should still do his or her investigation to see which techniques may have been applied.

Summary

First, we kicked off with explaining how we could roll out Defender for Endpoint via GPO. After we have done that, we explained in short what automated investigation and response is. Then we went on to collecting an investigation package and hunt in the data that we just collected from the package. Last, but not least. We showed a few examples on using the live response session to do in-depth investigation on a device.

Reference