One challenge with configuring Windows firewall (besides default of block inbound and allow outbound) is that we need the data. Before Defender for Endpoint we had to rely on event forward and similar techniques to get the data of the environment.
Microsoft has recently released a Defender Firewall (Windows Firewall) report where we can see the events. This has some prerequisites in terms of audit settings (Windows audit settings, not the firewall log)
Configure firewall auditing
Enable auditing for Filtering platform
Always verify eventual impact in your environment before enabling new settings on all endpoints
To get the data, it requires the device to be onboarded to MDE
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:
During Ignite, Microsoft has announced a new set of features in the Advanced Hunting in Microsoft 365 Defender.
These features will definitely help you in the Threat Hunting process and also reduce the gap between analysts, responders and threat hunters and simplify the life of a threat hunter.
When having hunting training classes, I usually recommend to use multiple browser tabs. One for the query development, and one used to go back to previous queries to see how some things were done earlier.
for example, if you are developing a hunting query and need an if statement, external data, regex or other more advanced features it is easier to just open a previous query to see how it was solved last time. At least until you get more fluent in KQL. This is to avoid having to save your new query, go back to the old one, and then back to the new again
With the multi-tab support we can open the query in a new tab
The new Hunting Page will now provide the resource usage for the query both timing and an indicator of the resource usage
If you would like to learn more about how to optimize queries, please visit:
Schema, Functions, Queries and Detection Rules have been separated into tabs for, according to my opinion, easier access and pivoting which will give a better overview in each tab.
The schema reference will open as a side pane
When looking at one of the *events tables, the ActionType column is very useful to see which events are being logged. Earlier, I usually selected distinct ActionType in the query to have a look at the events being logged. Now, it’s possible to use the quick access from the portal to expand all action types for a specific table.
Above image shows the action types for DeviceFileEvents. In the DeviceEvents there are around 180 different action types to query.
For the hunting query development and hunting use-cases, the action types is a great go-to resource.
The columns in the schema reference is clickable and can in a simple way be added to the query
Simple query management
The inspect record pane is an easy way to see the data for one single row. When developing new queries I usually take a subset of data (take/limit 20) to see an overview of the results, and also select an event to see all data instead of side scrolling through all columns when needed.
New features in inspect record is that we can do quick filters which will be added to the query.
In this example we would like to know more about process executions from the C:\AttackTools folder
Last but definitely not least… Link the query results to an incident
This is my favorite, this will reduce the gap and simplify the process between threat hunters, responders, and analysts.
By selecting the relevant events in the result, they can be added to an existing incident, or create a new incidents.
This feature will help organizations to define the threat hunting both in a proactive hunting scenario, and in a reactive, post breach scenario when the hunters will assist analysts and responder with a simplified process.
How to link the data to an incident
To be able to link the data you need to have the following columns in the output
DeviceId/AccountObjectID/AccountSid/RecipientEmailAddress (Depending on query table)
Develop and run the query
Please note, you cannot have multiple queries in the query window when linking to incident
Choose to create a new incident or link to an existing
Run a quick check in your environment to see if you have remote internet-based logon attempts on your devices by looking for RemoteIPType == “Public”. There are other where RemoteIPType is useful, like processes communicating with Internet.
Since it’s a ETL file we can actually open it with any ETL viewer, however, the result is not presented to us in the same way
We can see that Windows Performance Recorder is used under the hood
IMPORTANT, If you plan to use this troubleshooting to find paths for exclusions, be very careful. You might accidently open up your device to threats. If you are not 100% certain of your exclusions, please ask for help!
Devices have Windows 10 version 1703 or later, or Windows server 2016 or 2019
The file download is available from multiple pages in defender
It’s also visible on the file page, and the reason why we want to have the option to download in multiple pages is to avoid having to switch view and to be able to take the actions where we are in the portal
The possibility to set password for the file download makes it more safe and also avoid file to be detected during download
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.