This is it, the last part of the Incident Response series. In the past weeks, insight was given on how KQL can be used to perform incident response, even if the data is not ingested in Sentinel or Microsoft 365 Defender. Part three marks the last part which discusses how you can leverage Live Response, which is available in Defender For Endpoint.

The incident response series consists of the following parts:

1. Incident Response Part 1: IR on Microsoft Security Incidents (KQL edition)
2. Incident Response Part 2: What about the other logs?
3. Incident Response Part 3: Leveraging Live Response

Introduction

To explain the value and the needs around Live Response the following items will be addressed:

• Permissions
• Live Response Commands
  • Basic
  • Advanced
  • Practical Examples
• Incident Response Scripts
  • DFIR Script
  • Community Scripts
• Conclusion

Live Response provides security teams with a remote toolkit that enables you to perform additional incident response activities on a device. This provides security teams with a remote shell connection on the device that needs to be investigated.

The Operating Systems that currently support Live Response are:

• Windows 10 & 11
• macOS
• Linux
• Windows Server

Before you can use Live Response it needs to be enabled in the Advanced feature tab of the Defender For Endpoint settings, as seen below.

Once Live Response is enabled and the proper roles are assigned, the analyst can initiate a Live Response Session from the device actions, as seen below.

Permissions

The RBAC model in Defender For Endpoint has a specific section for Live Response Capabilities, which are based on the commands an analyst can run:

• Basic
• Advanced

Those RBAC rules can be assigned to specific DeviceGroup. I advise using those DeviceGroups to only assign the least privileges (as you should do for all roles) thus the least devices an analyst can perform Live Response on.

Remember that Live Response is a remote shell on an endpoint, so what could go wrong? Limit the accounts that can perform Advanced Commands on devices, since it has the option to run PowerShell scripts from the library, but if you can run one, you can also add one (hey red team!). So in theory you can upload custom scripts to tier0 devices and do a lot of damage, so be aware of this. There is an option in MDE that is off by default but can be turned on which lets you run unsigned PowerShell scripts. As also said in the Microsoft docs: Allowing the use of unsigned scripts may increase your exposure to threats.

Live Response Commands

Microsoft has documented all the commands that can be executed via Live Response. The tables below go over what the syntax is, what the command does and which platforms support the command.

Basic commands

The following commands are available for user roles that are granted the ability to run basic live response commands.

Table source: https://github.com/MicrosoftDocs/microsoft-365-docs/blob/public/microsoft-365/security/defender-endpoint/live-response.md

Advanced commands

The following commands are available for user roles that are granted the ability to run advanced live response commands.

Table source: https://github.com/MicrosoftDocs/microsoft-365-docs/blob/public/microsoft-365/security/defender-endpoint/live-response.md

Practical Examples

Once a Live Response session is initiated on a device the fun can begin. You know that you have established a successful connection with the device if the connect status returns Session established, as seen in the image below. The Live Response prompt provides some additional information about the device, such as its IP, which OS it is running and some data related to the Live Response session. This section will discuss some examples, Microsoft has documented more examples

Fileinfo

The fileinfo command gets information about a file, awhich OSn example of the execution is seen below. You need to use the cd command to change to the folder you are interested in. This lists when the file was created and when it was last modified. Furthermore, a lot of metadata is shared, for example, if the file is hidden or not. Lastly, the SHA1, MD5, LSH and SHA256 hashes are shared, which can be used in later stages to add them as IOC or hunt for related activities.

More Examples? Check the Live Response Example section in the Microsoft Docs.

Analyzing files

Based on the file information you might want to analyze the file, which is also possible. This can be done by running:

analyze file FileName.txt

This will again provide some information about the file, but it will mainly provide the file’s behaviour. In the case of this file, MDE performed two scans on the file:

• Deep Analysis
• Microsoft Defender static analysis

Both scans did not find malicious behaviour, resulting in a clean file status. The last part of the report is the most interesting, it shares the behaviour of the file. Which connections are made and what file interactions have been performed.

C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads> analyze file DFIR-Script.ps1
{
  "report": {
    "status": "clean",
    "file_hash": "bb395fced74d4a36446be8ce8af7e3aedf9d801e28167472d1c0a87c31cf7b9a",
    "not_found": 1,
    "clean": 1,
    "suspicious": 0,
    "infected": 0,
    "total": 2,
    "scans": [
      {
        "status": "clean",
        "scan_time": "2023-09-20T16:32:11.6164503Z",
        "source": "Deep Analysis",
        "report": null
      },
      {
        "status": "not_found",
        "scan_time": "2023-09-20T16:28:04.3376221Z",
        "source": "Microsoft Defender static analysis",
        "report": null
      }
    ],
    "rescan": null,
    "threat_type": null,
    "behavior": {
      "networkTcpIps": [
        "fe80::5052:d740:21d8:bb2c",
        "ff02::1:3",
        "224.0.0.252",
        "13.107.4.50",
        "ff02::1:2",
        "fe80::e8ce:93e9:5411:20b",
        "168.62.124.16",
        "13.107.48.18",
        "104.218.56.90"
      ],
      "files": {
        "Created": [
          "c:\users\[[deep_analysis_user]]\appdata\roaming\microsoft\windows\recent\customdestinations\8nsg1i8j4247xso0uzvi.temp",
          "c:\users\[[deep_analysis_user]]\appdata\roaming\microsoft\windows\recent\customdestinations\d93f411851d7c929.customdestinations-ms~rf15ec4.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cab6f10.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tar6f11.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cab6f32.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tar6f33.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cab8377.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tar8378.tmp",
          "c:\input\dfir-[[deep_analysis_pc]]-2023-09-20\userinformation\activeusers.txt",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cab8a48.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tar8a49.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cab8af6.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tar8af7.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cab8b23.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tar8b24.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cab8b92.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tar8b93.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cabae0d.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tarae0e.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\cabae2f.tmp",
          "c:\users\[[deep_analysis_user]]\appdata\local\temp\tarae30.tmp"
        ],
        "Modified": null,
        "Deleted": null
      }
    },
    "has_file": false
  },
  "scan_status": "clean"
}

Audit Live Response

All commands and scripts that are executed on any device are logged in the command log. This section could also be used to identify which commands have been executed and if data has been uploaded or exfiltrated from the device.

Incident Response Scripts

The real value of Live Response can be leveraged when custom scripts are uploaded. Those scripts are not limited to the basic or advanced syntax, thus can execute more powerful scripts. The Incident Response PowerShell repository contains several scripts that can help you to perform IR, one of them is discussed below.

Let’s first start by adding a custom PowerShell script to our Live Response library. This can be done in the right top corner (see image below), by clicking upload file to library.

Once the scripts have been uploaded the library command can be executed to list all the available IR scripts. In our case, the DFIR-script.ps1 is uploaded and ready to be used.

DFIR Script

The DFIR script collects information from multiple sources and structures the output in the current directory in a folder named ‘DFIR-hostname-year-month-date’. This folder is zipped at the end so that the folder can be remotely collected.

• Local IP Info
• Open Connections
• Aautorun Information (Startup Folder & Registry Run keys)
• Active Users
• Local Users
• Connections Made From Office Applications
• Active SMB Shares
• RDP Sessions
• Active Processes
• Active USB Connections
• Powershell History
• DNS Cache
• Installed Drivers
• Installed Software
• Running Services
• Scheduled Tasks

For the best experience run the script as admin, then the following items will also be collected:

• Windows Security Events
• Remotely Opened Files
• Shadow Copies

Execute DFIR Script

The DFIR script can be executed by running the following command:

run DFIR-script.ps1

This script outputs all the results in a .zip as mentioned above. But this .zip file is stored on the remote device. Of course, we can use live response to collect the file for further analysis. This can be done by using the getfile command. This downloads the file to your local machine.

Now the incident responder can investigate the logs for malicious content. This can be really valuable since more information can be collected this way, than by collecting the Investigation Package.

Community Scripts

Before you start asking CHAT-GPT or BingChat to create some incident response PowerShell scripts have a look at what the community already provided.

• Powershell Digital Forensics & Incident Response
• M365 MDATP Live Response sample scripts
• Remote collection of Windows Forensic Artifacts using KAPE and Microsoft Defender for Endpoint

Conclusion

This was the last part of the incident response series, covering responding using KQL, Azure Data Explorer and Live Response. I hope that you learned a thing or two ;). What all the parts of the series have in common is that preparation is key! All examples that are shown can be used very effectively, but you need to test and tune them to your environment beforehand.

Some tips from my side to prepare for incident response scenarios:

1. Prepare (or gather) KQL queries for common attack scenarios that will help you effectively investigate suspicious actions.
2. Research which common techniques are covered in the data you ingest in your SIEM solution. If possible fill the gaps with data you can collect when needed. This data can then be analyzed with KQL using Data Explorer as discussed in Part 2.
3. Prepare (or gather) live response scripts that can cover the gaps as mentioned in step 2.
4. Test, test and test. Run a scenario and see what happened, not only on the technical side but also on the people and process part.

Questions? Feel free to reach out to me on any of my socials.