Security teams rely on SIEM tools to monitor and respond to threats, but managing them can be complex. Azure Sentinel, Microsoft’s cloud-native SIEM, not only addresses these challenges but also offers additional capabilities. This article breaks down what Azure Sentinel is and its basic components, followed by a quick demonstration of SSH brute force detection and alert creation as an example.

Prerequisites

• Azure Portal account.

Azure Sentinel: The Basics

Azure Sentinel is Microsoft’s cloud-native Security Information and Event Management (SIEM) tool, with built-in Security Orchestration, Automation, and Response (SOAR) capabilities. At its core, it’s designed to collect, analyze, and respond to security threats across your organization.

It can pull logs from Azure Active Directory, Office 365, firewalls, Syslog, and many more, then analyze and act on them. For example, with Syslog, Azure Sentinel can detect repeated failed SSH login attempts, which often indicate a brute force attack. It can then automatically trigger a playbook to block the suspicious IP address or notify your security team for further action.

Azure Sentinel’s Content Hub simplifies setup by providing pre-built solutions, including data connectors, analytics rules, and playbooks, making it easy to integrate sources like Azure Active Directory, Office 365, firewalls, and Syslog. Let’s break down some of them.

Components

These are the core elements you’ll find in Azure Sentinel’s sidebar, each playing a key role:

• Content Hub: A centralized repository of out-of-the-box solutions and packages (plugins) for extending Sentinel’s capabilities. It includes pre-built content like data connectors, analytics rules, workbooks, playbooks, and hunting queries.

• Data Connectors: Ingest data from a wide range of sources, including Azure services, AWS, on-premise systems, and third-party tools.

• Workbooks: Customizable dashboards that provide interactive visualizations of your data, helping you analyze trends, investigate incidents, and respond to security threats.

• Analytics: Create and manage detection rules for real-time threat monitoring. Includes pre-built rule templates, active rules, and scheduled analytics to identify suspicious activities automatically.

• Hunting: Proactively search for threats using built-in or custom queries. Leverage advanced query languages like KQL (Kusto Query Language) to uncover hidden risks in your data.

• Notebooks: Automate and enrich investigations using Jupyter notebooks. These are ideal for advanced threat hunting, incident investigation, and building machine learning models to enhance security operations.

• Incidents: Group and manage related alerts into incidents, providing a centralized view for tracking and resolving security issues.

• Playbooks: Automate responses to threats using workflows built in Logic Apps (an Azure service). Playbooks can trigger actions like blocking IPs, sending notifications, or escalating incidents based on predefined conditions.

• Watchlist: Create custom lists of key data (e.g., high-risk IPs, privileged users) to prioritize or filter alerts during threat detection and investigation.

Log Analytics Workspace

Before we go further with Azure Sentinel, we’ll need to talk about Log Analytics first. Log Analytics is the backbone of Azure Sentinel, as it stores and organizes all the log data collected from your connected sources. Azure Sentinel cannot be created without a Log Analytics workspace because it relies on this workspace to query, analyze, and visualize the data for threat detection and response.

In short, Log Analytics provides the foundation, while Azure Sentinel builds on it to deliver advanced security operations.

Demo: SSH Brute Force Detection

We’ll do a demo to set up Azure Sentinel for detecting SSH brute force attacks. This includes installing the Syslog content hub, using the SSH rule template to create an alert, and seeing how Azure Sentinel responds to suspicious activity in real time.

Before starting, ensure you’ve setup Azure Sentinel and a Log Analytics workspace—both are straightforward to set up in the Azure portal, so just go through the creation process. You’ll also need to create an Azure Linux VM to collect the Syslog data for the demo.

Installing Syslog from the Content Hub

After setting up Azure Sentinel, go to Content Hub and search for Syslog.

Select it and click on Install. It should install the following:

• 2 data connectors (Syslog via AMA and Syslog via Legacy Agent).

• 1 workbook.

• 7 analytic rules (one of them is the SSH brute force).

• 9 hunting queries.

Collecting Logs from Azure VM

After installing the Syslog content solution, click on Data connectors in the sidebar. Select the Syslog via AMA and click on Open connector page then click on +Create data collection rule.

Name the rule anything you wish, I named mine vm-syslog. For resources, select the Azure VM you just created (or the one you want to collect Syslog data from). Set LOG_DEBUG minimum log level for both LOG_AUTH and LOG_AUTHPRIV then create. This will create a Data Collection Rule that forwards the specified Syslog data to your Log Analytics workspace, where Azure Sentinel can query and analyze it for threat detection.

Try SSHing into the Azure VM you created. Make sure to perform one successful login and one failed attempt with a non-existent user (test-user for example). You’ll soon see why as we move forward.

To confirm if the logs are collected, go to Azure Sentinel or Log Analytics Workspace and click on Logs in the sidebar. Open an empty query in KQL (Kusto Query Language) mode and run Syslog so you can see all the data in the Syslog table. If you don’t see anything yet, you may need to wait 5-15 minutes after the creation of the data collection rule.

Creating Alert

Rules are the heart of Azure Sentinel, they are used to detect security threats and generate alerts. Now that we’ve installed the Syslog content solution in Azure Sentinel, created a VM, and set up a data collection rule to gather the VM’s Syslog data, let’s proceed to create an alert. Navigate to Analytics in the Azure Sentinel sidebar.

Here, you’ll find Active rules, which are custom or built-in analytics rules currently running in Azure Sentinel, and Rule templates, which are pre-configured, out-of-the-box rule definitions provided by the content solution you’ve installed. These templates can be enabled or customized to create active rules. Click on Rule templates and you’ll find the SSH - Potential Brute Force rule template here, select it.

Each rule template comes with its own predefined rule query. You can also create your own custom query if you want to build a custom rule. Before we create the active rule, let’s test the query first. Open another empty query and copy the rule query from the SSH brute force rule template and execute it, just like we did with the Syslog query last time. We won’t see any results yet, right? That’s because we haven’t attempted 15 failed SSH logins. To test the query, let’s remove the lines let threshold = 15; and | where PerHourCount > threshold. This will give you the modified query to work with.

Syslog
| where ProcessName =~ "sshd"
| where SyslogMessage contains "Failed password for invalid user"
| parse kind=relaxed SyslogMessage with * "invalid user " user " from " ip " port" port " ssh2" *
// using distinct below as it has been seen that Syslog can duplicate entries depending on implementation
| distinct TimeGenerated, Computer, user, ip, port, SyslogMessage, _ResourceId
| summarize EventTimes = make_list(TimeGenerated), PerHourCount = count() by bin(TimeGenerated,4h), ip, Computer, user, _ResourceId
| mvexpand EventTimes
| extend EventTimes = tostring(EventTimes)
| summarize StartTime = min(EventTimes), EndTime = max(EventTimes), UserList = make_set(user), ComputerList = make_set(Computer), ResourceIdList = make_set(_ResourceId), sum(PerHourCount) by IPAddress = ip
// bringing through single computer and user if array only has 1, otherwise, referencing the column and hashing the ComputerList or UserList so we don't get accidental entity matches when reviewing alerts
| extend HostName = iff(array_length(ComputerList) == 1, tostring(ComputerList[0]), strcat("SeeComputerListField","_", tostring(hash(tostring(ComputerList)))))
| extend Account = iff(array_length(ComputerList) == 1, tostring(UserList[0]), strcat("SeeUserListField","_", tostring(hash(tostring(UserList)))))
| extend ResourceId = iff(array_length(ResourceIdList) == 1, tostring(ResourceIdList[0]), strcat("SeeResourceIdListField","_", tostring(hash(tostring(ResourceIdList)))))

Execute the query, and you should see the one failed SSH login attempt with the non-existent user that you made earlier. You did it though, right? Right?

Now, back to the rule template. Click on Create rule, and consider updating the description to avoid confusion when reviewing incidents later. In the Set rule logic section, change the threshold from 15 to 5 and set the query scheduling to run every 5 minutes. Leave everything else unchanged and create the active rule. Once created, you’ll find it under Active rules in Analytics.

Let’s test the alert now. Execute the command below (if you’re using Linux), it should do 6 failed attempts to the server. You may need to install sshpass package.

for i in {1..6}; do sshpass -p 'randomPassword' ssh -o StrictHostKeyChecking=no dummy-user@<ip-address>; done

After 5 minutes or more, go to Azure Sentinel and click on Incidents in the sidebar. You should see the incident created from the alert triggered by the brute force attempt we simulated. To confirm, you can run the query in Logs with the threshold set, and you should see matching results.

Conclusion

We covered what Azure Sentinel is, its components, and walked through a demo to detect SSH brute force attacks. By setting up Syslog, creating alerts, and simulating threats, we saw how Azure Sentinel efficiently monitors and creates incidents.

We didn’t get to cover playbooks, but they can be really handy for automated workflows. Playbooks are built on Logic Apps, a no-code/low-code Azure service, and they enable automated responses, like blocking IPs, sending alerts, and many other applications. Playbooks can even be used to forward incident data to Azure Event Hub, enabling integration between Azure Sentinel and Azure Event Hub. If you’re interested in sending Event Hub data to a log shipper like Fluentd, you can check out my article on integrating Azure Event Hub with Fluentd.

In summary, Azure Sentinel is a comprehensive solution for modern security teams, combining SIEM and SOAR functionalities to streamline threat management. It also offers advanced hunting, machine learning, and customizable workbooks for deeper insights.