Features & Benefits of Azure Sentinel
Published: 2024-02-19 04:12:36

## Why use Azure Sentinel?
Azure Sentinel is a powerful data-driven security platform built on the Microsoft Azure cloud. Azure Sentinel empowers organizations with deep security insights curated from a vast ocean of data. Here's what makes it stand out:

* [Data-Centric Approach](#Data)
* AI-Powered Insights
* Unified Threat Management
* [Proactive Threat Hunting](#hunt)
* [Threat Intelligence Integration](#threat)
* [Automation and Orchestration](#auto)

With these features, you will be able to gain holistic visibility across your entire security landscape, detect and respond to threats quicker and more effectively, automate security workflows for increased efficiency, and optimize security posture with proactive threat hunting and intelligence.

## Analyzing User Login Activity <a id="Data">
<!-- Setup:

Goal: Investigate user login activity in your Azure environment to identify potential anomalies and suspicious behavior.

Create an Azure Sentinel workspace: If you don't have one already, sign up for a free Azure trial and create a workspace.

Connect data sources: Integrate Azure Active Directory logs with your Sentinel workspace. This will automatically collect user login data.
Install Microsoft Entra ID content
-Configure the connector:
connect provide tenant id and select log types

Data-Centric Analysis:

Create a watch rule: Based on your observations, create a rule to flag suspicious login activities. For example, you could create a rule for:

Login attempts from unusual locations or countries.
Repeated failed login attempts from a specific user or device.
Logins outside of regular working hours.
Investigate alerts: The rule will trigger alerts for potential risks. Investigate them by looking at the associated login details and other relevant data sources like Azure Security Center alerts.

Take action: If you confirm a security risk, take necessary actions like blocking the user, resetting their password, or notifying the security team. -->
Goal: Investigate user login activity in your Azure environment to identify potential anomalies and suspicious behavior.

1. Create an Azure Sentinel workspace
2. Connect data sources: Integrate Azure Active Directory logs with your Sentinel workspace. This will automatically collect user login data.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/k95lcxvwgxg8xtiuz8e9.png)

3. Explore the data: Go to the "Logs" section in Sentinel and explore the "SigninLogs" data table. Here you can see specific user login attempts, including details like:
       * Username
       * Timestamp
       * IP address
       * Location
       * Device
       * Sign-in status (success/failure)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xrbu54jkyfe4gjof47g4.png)

Now you can **create a watch rule**: Based on your observations, create a rule to flag suspicious login activities. For example, you could create a rule to check for logins to a glass account.

**Investigate alerts**: The rule will trigger alerts for potential risks. Investigate them by looking at the associated login details and other relevant data sources like Azure Security Center alerts

**Take action**: If you confirm a security risk, take necessary actions like blocking the user, resetting their password, or notifying the security team this is where you can automate.

_This is a basic example. You can expand this project by adding more data sources, creating more complex rules, and integrating with other security tools for a comprehensive security posture._

## Want to take it a step further? <a id="auto">

Now that you have a high-severity incident in Microsoft Sentinel, You should add automation to directly notify the correct people or in a more complex scenario take appropriate steps to remediate. Heres a simple automation that sends an Urgent email to the owner when the glass account is accessed using Azure Playbook with incident trigger and Logic Apps.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e8g66h7nqodi2og9dx0t.png)

Now if someone were to sign into this glass account, an incident will be triggered and an immediate automated response will be emailed to the owner:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ixk5ro5qju11vsshxfbl.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c332mo4lia4euub167sa.png)

## Another rule example

Let's take a look at Rule templates! We'll choose this one:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5ivto6oxvcsb2jeueyj2.png)

Identifies when a rare Resource and ResourceGroup deployment occurs by a previously unseen caller.

Microsoft Sentinel is a cloud-native SIEM and as such, it acts as a single pane of glass for alert and event correlation. For this purpose, and to be able to ingest and surface alerts from Microsoft Security products, we can create a Microsoft incident creation rule.

## Fusion Rule (Advanced Multistage Attack Detection)

The Fusion rule is a unique kind of detection rule: Using the Fusion rule, Microsoft Sentinel can automatically detect multistage attacks by identifying combinations of anomalous behaviors and suspicious activities/alerts that are observed at various stages across a kill-chain. 

As Fusion rules produce security incidents with high fidelity and simulation can be challenging, i've included an example of an incident that was created from fusion detection. In the below example we are seeing 2 low severity alerts from Azure Active Directory Identity Protection and Microsoft Cloud App Security that stitch together into a high severity incidence:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xmneqcj4nr3aytvaewtt.gif)

## Create a Microsoft Sentinel custom analytics rule

A security consultant notifies you about some intelligence they came across, around malicious inbox rule manipulation, based on some threads they read online
* Office activity
* Creation of new inbox rules
* Certain keywords being included in the rules being created
Based on the attack vector and your organizational risk, he recommends you create a detection rule for this malicious activity.

**Setup the detection**
**Add a customized Alert title**
The next time the rule is scheduled - as long as the training data was onboarded within its lookback period - it should find the logs from the OfficeActivity_CL custom log table and raise grouped Alerts as Incidents.
**Review resulting security incident**
**Find the Incident** - Notice that the title adapted to the user affected

In the right pane we can review the incident preview, this view will give us high-level overview on the incident and the entity related to it. Here is the full Incident Page:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/889r031kw9uic6hnsuge.png)

## Incident Management
What the security operations center analyst's experience using Sentinel incident management capabilities might look like:

### Review the Microsoft Sentinel incident tools and capabilities
The analyst might want to assign the incident to themselves and change the status to active to show that it is open being worked on.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9elo54jd67zyzml4woot.png)

By choosing the security _efficiency workbook option_, you can see overall statistics for incidents

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qza1cpcs1h92t48ckn86.png)

## Handling the incident

Here's an example of handling the incident procedure, demonstrating a few things the analyst might accomplish using Sentinel.

To get more context for this IP address, add Geographic IP Information which is a type of _incident enrichment_. (In a real environment this would be automated.)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1pno0ugfxbet134fxeyi.png)

After running the playbook, the geo-location from the IP in the incident is revealed.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hukel06fujjd0l9zuwi7.png)

### Continuing the investigation with a Workbook
As the SOC Analyst, this enrichment information increases your concern! You want to check for other traces of this IP in your network. For this investigation, you want to use the Investigation Insights workbook.

When we investigate the IP address, we can see it is associated with  _adelev@m365x816222.onmicrosoft.com_ which just so happens to be a part of "Security Red Team" and the behavior is part of an exercise they are running for 48 hours. 
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/stlrph60qqxr34odn9dc.png)

If this were a real account, you could also more thoroughly investigate it in the Investigation Account tab of this Workbook or through the account Entity page in Sentinel.

Now that we know that this is a Red Team exercise, The SOC manager asks us to allow-list this IP for this detection type, so we can use an incident _Automation Rule_ for this.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z126igg9blrd7tc35z8v.png)

We can configure the rule to change the status to Closed marked with Suspicious, but expected for 48 hours on the IP address when the incident is created.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n6qqpl6tglg6mvdagm0g.png)

### Handling the Solorigate Network Beacon
Same as the last you can assign it to yourself and change the status.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bjis23ft607nf7oi9pcf.png)

As you can see, one of the domain IOCs related to the Solorigate attack has been found. In this case, the domain avsvmcloud.com is involved.

If you view the Link to LA you can see that it was able to check and verify that the attack came specifically from Cisco Umbrella DNS:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gvl1841v12jdh2dnmaua.png)

### Hunting for more evidence
Let's see how you can identify the hosts that might have been compromised.

We will use the _Solorigate Inventory check_ query

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fs84voeukf5wsj389sve.png)

If we view the results we can see that there are two additional computers where the malicious DLL and named pipe have been found. Let's bookmark these (Information auto-fills for you as well):

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/anlv411y6oaji1985rvd.png)

Now we can add the bookmarks of affected computers to the incident (can also be automated using a Playbook):

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yqmm6juiv8uzijvpck0a.png)

### Add the IP to the Threat Intelligence IOCs <a id="threat">
Now you can add the IP address related to the incident to our list of _Indicators of Compromise_ in the Sentinel workspace Threat Intelligence store, so we can capture any new occurrences of this IOC across our logs. This threat intelligence is built in and correlates events with known indicators of compromise (IOCs) from Microsoft's threat intelligence feed, flagging suspicious activity.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ac6amrfhetb9guhgdnja.png)

### Hand over the incident
You can now prepare the incident to get handed over to another team, maybe operations or forensics

## Hunting <a id="hunt">
This provides powerful tools and knowledge of attacker tactics to empower security teams to be more proactive and effective in protecting their systems.

### Hunting on a specific MITRE technique
Your SOC team needs to be able to see a full picture of an attack campaign and spot anomalies on their data set, they need to run a threat hunt based on the MITRE tactics and techniques described in the attack campaign article they read.

The MITRE attack technique is T1098 or Account Manipulation: Adversaries may manipulate accounts to maintain and/or elevate access to victim systems

You can see on the hunting page that Sentinel provides built-in hunting queries to start your process. On the metric bar, you can see statistics about how many queries are "active" and have the required data sources to run in your environment. You can also see the number of livestream results and bookmarks created during the hunting process.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dhzspaw6ofkq24zz8lgs.png)

Let's filter to only the account manipulation queries and run them

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/93csqo6unjo5hxt22et5.png)

Looks like the _Adding credentials to legitimate OAuth Applications_ returned 5 results. This query looks for Apps or service principals where new Key Credentials were added. This has been used by attackers to gain persistent access and elevate privileges. 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/58s0pw72xzez3fgf0ycp.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lx72p2lxg7igycf8eb1h.png)

You can spot the Application name, the added key name, IP, and username of the actor, and other relevant information that helps us understand the specific action.

Let's say your SOC analysts need to know which application from all the above result set is critical and has a security risk. One way to do this is to open Entra ID for each application from the hunting results, check their permissions, and validate the risk. The SOC analyst follows the organization's knowledge base which guides him to review a list of all the Entra ID applications with their risk levels.

The organization knowledge base uses this list with the Entra ID applications and their associated risk level:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i437uuivtqb5isdv5phg.png)

Let's import the CSV list in Watchlist:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gpqn44utsdozvztr3fdk.png)

When we run the watchlist you can see it stores the application name, risk level and permissions. To correlate this information with the hunting results set, run a join query:

```
_GetWatchlist('HighRiskApps')
| join 
(
AuditLogs_CL
| where OperationName has_any ("Add service principal", "Certificates and secrets management")
| where Result_s =~ "success"
| mv-expand target = todynamic(TargetResources_s)
| where tostring(tostring(parse_json(tostring(parse_json(InitiatedBy_s).user)).userPrincipalName)) has "@" or tostring(parse_json(InitiatedBy_s).displayName) has "@"
| extend targetDisplayName = tostring(parse_json(TargetResources_s)[0].displayName)
| extend targetId = tostring(parse_json(TargetResources_s)[0].id)
| extend targetType = tostring(parse_json(TargetResources_s)[0].type)
| extend eventtemp = todynamic(TargetResources_s)
| extend keyEvents = eventtemp[0].modifiedProperties
| mv-expand keyEvents
| where keyEvents.displayName =~ "KeyDescription"
| extend set1 = parse_json(tostring(keyEvents.newValue))
| extend set2 = parse_json(tostring(keyEvents.oldValue))
| extend diff = set_difference(set1, set2)
| where isnotempty(diff)
| parse diff with * "KeyIdentifier=" keyIdentifier: string ",KeyType=" keyType: string ",KeyUsage=" keyUsage: string ",DisplayName=" keyDisplayName: string "]" *
| where keyUsage == "Verify" or keyUsage == ""
| extend AdditionalDetailsttemp = todynamic(AdditionalDetails_s)
| extend UserAgent = iff(todynamic(AdditionalDetailsttemp[0]).key == "User-Agent", tostring(AdditionalDetailsttemp[0].value), "")
| extend InitiatedByttemp = todynamic(InitiatedBy_s)
| extend InitiatingUserOrApp = iff(isnotempty(InitiatedByttemp.user.userPrincipalName), tostring(InitiatedByttemp.user.userPrincipalName), tostring(InitiatedByttemp.app.displayName))
| extend InitiatingIpAddress = iff(isnotempty(InitiatedByttemp.user.ipAddress), tostring(InitiatedByttemp.user.ipAddress), tostring(InitiatedByttemp.app.ipAddress))
| project-away diff, set1, set2, eventtemp, AdditionalDetailsttemp, InitiatedByttemp
| project-reorder
  TimeGenerated,
  OperationName,
  InitiatingUserOrApp,
  InitiatingIpAddress,
  UserAgent,
  targetDisplayName,
  targetId,
  targetType,
  keyDisplayName,
  keyType,
  keyUsage,
  keyIdentifier,
  CorrelationId
| extend
  timestamp = TimeGenerated,
  AccountCustomEntity = InitiatingUserOrApp,
  IPCustomEntity = InitiatingIpAddress
  ) on $left.AppName == $right.targetDisplayName
| where HighRisk == "Yes"
```
As you can see the above query uses a join operator to join two data streams: the high-risk watchlist and the “Adding credentials to legitimate OAuth Applications” hunting query results. We are joining these two datasets based on the application name column. We filter the results with a where operator to see only the high-risk applications.

While reviewing query results in Log Analytics, we use Microsoft Sentinel’s bookmarking feature to store and enrich these results. We can extract entity identifiers and then use entity pages and the investigation graph to investigate the entity. We can add tags and notes to the results to say why it is interesting. Bookmarks will also preserve the query and time range that generated the specific row result so that analysts can reproduce the query in the future
If as part of our investigation, we determine that the bookmarked query result contains malicious activity, we can create a new incident from the bookmark, or attach the bookmark to an existing incident.

** Watchlists

You can use watchlists in your search, detection rules, threat hunting, and response playbooks. You have received a message from the SOC manager, informing you about a penetration test exercise being performed over the next few weeks. Your manager also informs you that the SIEM is already seeing a bunch of incidents from IP addresses used by the penetration test team. These incidents all come from rule "High count of connections by client IP on many ports", which identifies when 30 or more ports are used for a given client IP in 10 minutes occurring on the IIS server. Your manager provides you this CSV file with the list of the IP addresses involved in the penetration exercise: 

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2m6ytdt9z0pewd17tn38.png)

Here are the IP addresses from the watch list:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ae404u85ifomovk5pfq7.png)

Time to whitelist the IP addresses in the analytics rule.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x3o2e7bz6a1ufrax79l4.png)

See! Now you can add:
``` let PenTestIPaddresses = _GetWatchlist('PenTestIPaddresses') | project IPAddress; ```

to the KQL statement and:
``` | where cIP !in (PenTestIPaddresses) ```

that brings the IPAddress field from the watchlist we created and filters out the IP addresses from the Watchlist!