Live response is designed to enhance investigations by enabling your security operations team to collect forensic data, run scripts, send suspicious entities for analysis, remediate threats, and proactively hunt for emerging threats.
Capabilities
Run basic and advanced commands to do investigative work on a device.
Download files such as malware samples and outcomes of PowerShell scripts.
Download files in the background (new!).
Upload a PowerShell script or executable to the library and run it on a device from a tenant level.
Take or undo remediation actions.
Requirements
macOS – Minimum required version: 101.43.84. Supported for Intel-based and ARM-based macOS devices.
One thing that threat actors commonly do when getting a foothold on a device, is to try to disable Defender services and adding exclusions for their tools which they plan to execute.
For the Defender services, we have had Tamper Protection for some time, but that did not cover exclusions.
Tamper Protection configuration via Intune
Requirements
For Tamper Protection to cover exclusions, the following requirements must be met:
Devices are running Windows Defender platform 4.18.2211.5 or later
The registry value TPExclusions which is in the HKLM\SOFTWARE\Microsoft\Windows Defender\Features key shows a value of 1 if protected and 0 if not protected. Please note that you cannot change the registry value to protect the exclusions, it’s for information and not configuration
While we talk about Antivirus policies…
We would like to share this as well since it’s something we see when we do Defender assessments, it’s unfortunately very common that these settings are wrong
Cloud block level (high is recommended minimum) and Cloud Extended Timeout check must be set to 50 (seconds)
Sample submission is required for Cloud protection
The response action of blocking a compromised account is important to have available. Regardless of solution one must be able to quick and easy be able to block an account. In MDI (part of Microsoft 365 Defender) it is possible since some time ago to configure an MDI Action Account, lately the option to run with the system account of the Domain Controller has been added to this feature and therefor you don’t have to configure the gMSA account.
Using system or a custom gMSA account
The choice is made based on organizational structure, Tiering/RBAC, MSSP partner. Basically, if you are required to delegate the permissions to only allow actions on accounts in certain OU’s, then you must use a custom gMSA accounts.
For example, if you have a MSSP partner monitoring your security and take actions to discovered threats, a so called MDR (Managed Detection and Response), you have an option to control to which accounts the MSSP can take actions.
The available actions are:
Disable user in Active Directory: This will temporarily prevent a user from logging in to the on-premises network. This can help prevent compromised users from moving laterally and attempting to exfiltrate data or further compromise the network.
Suspend user in Azure Active Directory: This will temporarily prevent a user from logging in to Azure Active Directory. This can help prevent compromised users from attempting to exfiltrate data and minimizes the time between Disable user in Active Directory and the sync of this status to the cloud.
Reset user password – This will prompt the user to change their password on the next logon, ensuring that this account can’t be used for further impersonation attempts.
From an MSSP perspective, this feature is very useful since there wouldn’t require customer access (VPN or other kind of access) to respond to threats. Even though this feature is very popular for MSSPs, you will still want to have this option if you have your internal security operations to be able to respond from the portal you are currently working in.
Even though this feature is very popular for MSSPs
This can also be checked on the logon event (this will trigger 4625, logon failed)
Verify that the AccountType is “Machine”
Successful sign-in:
Account is not allowed to logon as a service
If the gMSA Account is setup and configured correctly and there is still event 4625 being logged.
Check the Status property of the login event
0xc000015b indicates that the account is not allowed to login0xC000015B
STATUS_LOGON_TYPE_NOT_GRANTED, A user has requested a type of logon (for example, interactive or network) that has not been granted. An administrator has control over who can logon interactively and through the network.
More information about the Status property can be found here:
Successful events effecting the user you try to take action on
The following query will find events of enabling and disabling a user
SecurityEvent
| where EventID in(4738,4725,4722)
| where Account contains "gMSA-mdi-action$"
| where TargetAccount contains "test" //the user you want to take action on
You see 4738 “A user account was changed” at the same timestamp as the 4725 and 4722 and the 4738 event show the UAC 0x10: Account Enabled and 0x11: Account Disabled
New options with more granular control are available when configuring suppressions
With logical operators like grouping, OR, AND it’s possible to be very granular with the suppressions, which is really critical to avoid suppressing to much.
Always be cautious when adding suppressions
When using the auto-fill rule it will automatically apply all entities from the alert
Resolve or hide an alert
Click Save
Resolving an alert will be handled as a regular resolved alert, meaning ending up in timeline, alerts queue, and APIs
Hiding the alert will cause the alert to be suppressed from the entire system, both on the device’s alerts and from the dashboard and will not be streamed across Defender for Endpoint APIs.
Depending on your scenario it could be important to make the choice to match the scenario you need. Could be related to reporting of total incidents/alerts to customers etc.
Troubleshooting mode will make it possible for local admins on the endpoint to override Antivirus policy on the device, including tamper protection. When enabled it give the admin a 3 hour window to do what was intended. After the 3 hour window, the settings will be re-applied again.
Enabling Troubleshooting mode
Go to the Device page in Microsoft 365 Defender and click on the 3 dots menu item and select troubleshooting mode
In the Device action center we can see the following entry
Prerequisites
Windows 10 (version 19044.1618 and above) Windows 11 Windows Server 2019 Windows Server 2022
Microsoft Defender for Endpoint must be tenant-enrolled and active on the device.
The device must be actively running Microsoft Defender Antivirus, version 4.18.2203 and above.
Hunting for events
//Use the following ActionType and the DeviceEvents table
DeviceEvents
| where ActionType == "AntivirusTroubleshootModeEvent"
What’s described in this post is no longer applicable due to TID parameter are added to links in the portal
We developed an extension that does exactly the same thing but this is not needed anymore hence why we won’t release it. Microsoft has updated links in the portal to include the TID-parameter which is awesome and for people working with many customers this is really great news and you don’t need multiple profiles either!
[Old post]
If you work with multiple customers with Microsoft 365 Defender or working in a multi-tenant setup, you have probably noticed that your end up in the first tenant even if changing the tid-parameter in the url.
The reason why this happens is that when for instance, clicking on links in Defender, it will take you to the tenant stored in a cookie, especially if you don’t have the tenant id parameter in the link.
It can be addressed by working with multiple profiles, but if you don’t want that you can just do the following
Open dev tools and go to Application and expand Cookies Select the security.microsoft.com and right-click on sccauth and select delete
Fine-tuning the analytic rules to minimizing the number of false-positives can be time-consuming and you still want to keep the high visibility so you don’t want to risk false-negatives. At the same time, the risk of managing a high number of incidents, especially if they are false-positives, would also be time-consuming.
To be able to fine-tune the analytic rules, we need historical data. Same as what was needed when developing the detection in the first place and for fine-tuning we also need decisions made when classifying the incident and if those decisions was related to any specific entities.
Machine Learning to the help
Microsoft Sentinel uses machine learning to analyze signals from the data sources and the responses made to an incident over time to assist and providing data for fine-tuning decisions.
The rules with recommendations for a fine-tune is noted with a light bulb next to the rule name as in below picture.
Fine-tuning recommendations available (preview feature)
When editing the analytic rule, in the Rule Logic tab, the Tuning insights is available
There are several panes which can be scrolled through which contains actionable items like exclude accounts, IPs etc. from the analytic rule
The third pane shows the importance of correct mapped entities since this is the only way to get results and shows the four most frequent entities in the alerts generated by the analytic rule.
Hopefully this can share some light on make your work more effective by working with your analytic rules to make your detection better.
Don’t forget to be careful and thing through your exclusions to avoid losing visibility.
Another feature in hunting, which will speed up responses from a threat hunting scenario is TakeAction
When selecting a record in the result, the Take Action button will be visible as seen in below picture
So instead of just creating a new incident or adding events to an existing incident we can take actions from the hunting experience.
In the Take actions experience we have actions grouped by Devices, Files and Users.
The action options available is dependent on the data in the result. For instance, file information like checksum is required to being able to quarantine a file.
When clicking Next we can see the target selected and click Next
We can add a Remediation name and Description for our action
This feature enables a rapid response at the fingertips of the threat hunters for immediate actions
NRT Rules are hard-coded to run once every minute and capture events ingested in the preceding minute.
This is for faster detection and response opportunity.
Considerations
No more than 20 rules can be defined per customer at this time
As this type of rule is new, its syntax is currently limited but will gradually evolve. Therefore, at this time the following restrictions are in effect:
The query defined in an NRT rule can reference only one table. Queries can, however, refer to multiple watchlists and to threat intelligence feeds.
You cannot use unions or joins.
Because this rule type is in near real time, we have reduced the built-in delay to a minimum (two minutes).
Since NRT rules use the ingestion time rather than the event generation time (represented by the TimeGenerated field), you can safely ignore the data source delay and the ingestion time latency (see above).
Queries can run only within a single workspace. There is no cross-workspace capability.
There is no event grouping. NRT rules produce a single alert that groups all the applicable events.
There is a technical limit which blocks union, join etc.
For further information about Near-Real-Time, NRT, analytic rules, please visit:
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
