Last year Microsoft Sentinel added the ability to define and run Near Real Time (NRT) detection rules. Unlike scheduled detections, NRT detections are hard coded to run once every minute and capture events ingested in the preceding minute. In addition, NRT detections are faster to access data and run on a two-minute delay from event generation, as opposed to scheduled detections that run on a built-in five-minute delay to account for ingestion time lag. As threat actors can quickly pivot from access to an environment to destructive actions such as Ransomware being able to rapidly detect key threats is vital to ensuring a successful response.
If you want to learn more about the fundamentals of NRT rules and how to create them you can read the documentation for this feature, or review this great blog.
Whilst NRT rules have some great advantages they also have some necessary limitations. The first is that queries are constrained to simple queries that only cover one log source at a time, and secondly a Microsoft Sentinel workspace can only have 20 NRT detections deployed at any one time. This blog will look at how to navigate these restrictions and make the most effective use of NRT detections. It will look at how to effectively select use-cases suitable for NRT detections, how to write these detections, and how to use them in a SOC environment. Alongside this blog we are also releasing the first set of NRT detection templates to the Azure Sentinel GitHub for Microsoft Sentinel customers to leverage for their own NRT detection engineering efforts. Links to these can be found in the Templates section below. be found in the Templates section below.
Quicker != Faster
It’s often tempting to think that the sooner that an incident can be raised, the sooner it can be resolved, and with this mindset NRT detections can appear to be an ideal solution for many areas. However, this is not always the case; often faster detections can lead to slower response and triage times within a SOC. There are many reasons for this:
- Context Switching: NRT detections are going to be a high priority for analysts meaning the generation of many such incidents is going to be highly disruptive, leading to context switching and slower response times. When selecting an NRT detection use-case ensure it is for something that will need to be top priority for your SOC team.
- Incomplete Detections: The limitation on single dataset queries that NRT detections bring means that they are going to provide less context in an incident than a scheduled alert that can correlate and add that context. When creating NRT detections consider if it would be more efficient to have a scheduled detection that runs less often but that provides greater detail when it runs.
- Operating Model: Ensuring that your tooling fits your processes is key. When considering NRT detections consider how your SOC operates and if rapid detections fit this model. For example, if you don’t have a 24x7 SOC operation then NRT detections might not be a good fit. In addition, if you are deploying NRT detections for the first time ensure the responding team know how to respond to them through the development of playbooks or other documentation.
Speed vs Accuracy
Another key area to consider with NRT detections is the risk of False Positives. The fact that NRT detections can’t use multiple datasets means that there is an increased chance of False Positives since other datasets can’t be used to validate or contextualize activity. It can often be more efficient to wait longer for a more reliable scheduled detection than it is to generate several False Positive NRT detections.
Keep it Simple
The nature and limitations of NRT detection makes them well suited to simple, precise detections – sometimes referred to as atomic detections. NRT use cases should be very tightly scoped to a specific scenario, much more so than scheduled detections. This will help mitigate the False Positive issue and reduce analyst load when investigating. When using NRT templates it is strongly recommended that the templates be modified to include additional environment specific criteria to make them more focused. For example, with the NRT template for `MFA rejected by user` it is recommended that this be modified to filter for only for specific, high profile users that an NRT detection would be useful for, such as domain admins.
This idea of simplicity also applies to the KQL used in NRT queries. It’s important to ensure that an analyst can quickly triage an incident and so having simple and clear KQL, alongside a clear output will help with this.
Examples of Good NRT Use Cases
In his blog Ron Marsiano presents a great example of an NRT use case - monitoring break glass account access. This use case is highly specific, is likely to have a very low False Positive rate, required little to no contextualization and has a clear set of actions for an analyst if it is triggered.
Some other examples include:
- Key administrative changes to identity architecture – such as adding a new ADFS server.
- This is a high priority event, that is likely to occur only very rarely and can be identified without additional correlation. In addition, it presents an easy path to triage for an analyst.
- Sensitive operations against key Azure resources – this could be a particularly sensitive KeyVault. Such detections should be scoped to specific resources or resource groups.
- Modifications to key service accounts – this could be events such as additional credentials being added to a Service Principal, or other authentication changes. Care should be taken to ensure that such a detection doesn’t generate too many incidents and it should be scoped to only specific accounts of interest.
- Matches for high confidence, high severity threat intelligence indicators. These are events that should be prioritized for rapid detection and action, however, ensure that indicators included in NRT detections are high confidence, currently active and linked to a specific threat. Any False Positives will significantly diminish the value of the NRT detection and indicators without a specific link to a current threat will be slow to triage on their own. It’s recommended that any indicator based NRT detections are reviewed and updated on a regular basis.
NRT Templates
The MSTIC team has produced several NRT templates for you to use. Each of these is a scheduled detection that has been adapted to an NRT detection. This means that you can choose to have the use case covered by a regular scheduled detection or an NRT detection depending on your situation.
You can find these in the Analytic Template blade by filtering for type NRT:
As covered previously it is recommended that each of these templates be modified to fit your specific environment and only used if it is suitable for your operating model.
List of templates:
Template Name: NRT Login to AWS Management Console without MFA.
Description: This alert identifies logins to the AWS Management Console without MFA.
Suggested modifications: Scope this detection to high value accounts such as administrators.
Template Name: NRT Modified domain federation trust settings.
Description: This will alert when a user or application modifies the federation settings on the domain or update domain authentication from Managed to Federated.
Suggested modifications: Scope this to only successful changes to federation setting and consider excluding activity from certain accounts.
Template Name: NRT New access credential added to Application or Service Principal
Description: This will alert when an admin or app owner account adds a new credential to an Application or Service Principal where a verified KeyCredential was already present for the app.
Suggested modifications: Scope to only additions on certain apps with high privileges or by users not expected to be conducting this activity.
Template Name: NRT PIM Elevation Request Rejected
Description: Identifies when a user is rejected for a privileged role elevation via PIM.
Suggested modifications: Scope this to only certain PIM roles such as Global Admin.
Template Name: NRT User added to Azure Active Directory Privileged Groups
Description: This will alert when a user is added to any of the Privileged Groups.
Suggested modifications: Scope this to certain Privileged Groups or additions by unexpected users.
Template Name: NRT Azure Active Directory Hybrid Health AD FS New Server
Description: This detection identifies the creation or update of a server instance in an Azure AD Hybrid health AD FS service.
Suggested modifications: Scope to activity generated by unexpected users or groups.
Template Name: NRT Sensitive Azure Key Vault operation
Description: Identifies when sensitive Azure Key Vault operations are used.
Suggested modifications: Consider scoping to specific KeyVaults.
Template Name: NRT Malicious Inbox Rule
Description: Identifies the deployment of suspicious mailbox rules that may be deleting or hiding items.
Suggested modifications: Consider scoping to specific high value mailboxes.
Template Name: NRT Multiple users email forwarded to same destination
Description: Identifies the deployment of suspicious mailbox forwarding rules to multiple mailboxes.
Suggested modifications: Consider scoping to specific high value mailboxes.
Template Name: NRT Security Event log cleared
Description: Checks for Event ID 1102 which indicates the security event log was cleared.
Suggested modifications: Consider scoping to high value hosts where log clearing isn’t expected.
Template Name: NRT Base64 encoded Windows process command-lines
Description: Identifies instances of a base64 encoded PE file header seen in the process command line parameter.
Suggested modifications: Consider scoping to high value hosts and excluding any known legitimate usage. Also consider scoping to only hosts without EDR coverage.
Template Name: NRT Process executed from binary hidden in Base64 encoded file
Description: Detects decoding of a Base64 encoded file in a command line.
Suggested modifications: Consider scoping to high value hosts and excluding any known legitimate usage. Also consider scoping to only hosts without EDR coverage.
Template Name: NRT MFA Rejected by User
Description: Identifies occurrences where a user has rejected an MFA prompt.
Suggested modifications: Consider scoping to high value users.
Template Name: NRT Squid proxy events related to mining pools
Description: Checks for Squid proxy events in Syslog associated with common mining pools.
Suggested modifications: Consider scoping to high value or high-risk hosts.
NRT rules provide a highly effective and highly valuable way to rapidly detect high risk threats that require an immediate response. However, consideration and thought is required in their usage in order to gain the maximum benefit. The templates we have released, along with the guidance in this blog can help you successfully deploy effective NRT rules in your environment.
Posted at https://sl.advdat.com/3ICgXKVhttps://sl.advdat.com/3ICgXKV