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.
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.
macOS – Minimum required version: 101.43.84. Supported for Intel-based and ARM-based macOS devices.
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
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”
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:
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
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
| 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!
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.
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.
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.
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.
For further information about Near-Real-Time, NRT, analytic rules, please visit:
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.