Threat Modelling and Detection simulation on my MS Sentinel SIEM Lab (SSH Brute Force)

I worked on this lab to build upon my already established SIEM environment. What is the point of a SIEM if it cannot be used to passively detect real time threats, triage and automaticaly respond to such threats.

The whole point of this specific lab will be to emulate:

• Brute Force (T1110) — Credential Access

on the ssh server of the Windows Victim’s computer.

The goal is to get the SIEM Lab to statefully detect and respond to an active incident based of several True Positive alerts

Subsequently, this lab will also document the hardening steps taken to mitigate such risks.

SSH BRUTE FORCE - EMULATION PROCESS

Step 1: Enabling SSH on the Windows Target

To simulate an SSH brute force attack against a Windows system, I first needed to enable SSH access on the victim machine.

By default, Windows does not expose SSH services, so I installed the OpenSSH Server feature using PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

After installation, I started the SSH service and ensured it persists across reboots:

Start-Service sshd
Set-Service -Name sshd -StartupType Automatic

To allow inbound SSH connections, I configured a firewall rule for TCP port 22:

New-NetFirewallRule -Name sshd -DisplayName "OpenSSH Server" -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Finally, I verified that the SSH service was running successfully. This step exposed the Windows machine to remote authentication attempts, making it a valid target for brute force simulation. For this method to seem practical, I left “password authentication” enabled under the sshd config file.

Step 2: Validating Log Ingestion in Microsoft Sentinel

Before launching the attack simulation, I verified that authentication logs from the Windows machine were successfully being ingested into Microsoft Sentinel.

Using the Log Analytics workspace, I queried for failed and successful logon events:

SecurityEvent
| where EventID == 4625
| take 10

SecurityEvent
| where EventID == 4624
| take 10

Event ID 4625 represents failed logon attempts, while Event ID 4624 corresponds to successful authentication events.

Confirming the presence of these logs ensured that any brute force activity generated during the attack would be visible and detectable within the SIEM environment.

Logs of failed authentication

Step 3: Identifying the Target System

To prepare for the brute force simulation, I identified the IP address of the Windows machine acting as the target.

Using the following command:

ipconfig

I located the system’s IPv4 address, which would be used by the attacker machine (Kali Linux) to initiate SSH authentication attempts.

This step ensures proper network connectivity between the attacker and the victim system within the lab environment.

IP address of my Vbox Host adapter

Step 4: Verifying SSH Connectivity

Now this step is mostly conducted post a successful user enumeration of(in most cases — a company’s domain) that gives the attacker info on users present.

Before executing the brute force attack, I validated that SSH access to the Windows machine was functioning correctly.

From the Kali Linux attacker system, I initiated a manual SSH connection:

ssh user@192.168.62.1

This step confirmed that the SSH service was accessible and properly configured. Ensuring connectivity beforehand is critical, as brute force tools rely on successful communication with the target service.

Step 5: Configuring Automated Response via Webhook Integration

After validating SSH connectivity, the next phase involved implementing an automated response mechanism to react to brute force activity in near real-time. Due to limitations in using native playbooks within Microsoft Sentinel, a webhook-based approach was adopted to simulate SOAR capabilities.

The reason for this offshore detection logic is ascribed to the lack of bugdet for using the azure provided playbook config😣.

Detection Logic Configuration

A custom alert rule was created using a log search condition. The detection logic leveraged a KQL query to monitor failed SSH login attempts (Event ID 4625) and identify repeated failures originating from the same IP address within a defined time window. The query aggregated failed attempts over 5-minute intervals and triggered an alert when the threshold was exceeded, effectively identifying brute force patterns.

Alert Rule and Condition Setup

Within the alert rule configuration, the following parameters were defined:

• Signal Type: Log search → Custom log search
• Scope: Log Analytics Workspace (log data source)
• Condition: Trigger alert when query returns results (i.e., failed attempts exceed threshold)
• Evaluation Frequency: Set to align with the query time window for consistent detection

This ensured that the system continuously evaluated incoming logs and generated alerts when suspicious authentication activity was detected.

Action Group Configuration (Webhook Integration) To enable automated response, an Action Group was created and attached to the alert rule. Instead of traditional notification methods, a webhook action was configured.

The webhook was pointed to a publicly accessible endpoint exposed by a Python Flask application. This endpoint served as a custom “playbook,” receiving alert payloads directly from Azure Monitor.

To standardize the data format and simplify parsing, the Common Alert Schema was enabled. This ensured that alert details such as source IP address and event context were consistently structured when delivered to the webhook.

Custom Response Execution via Flask API

Upon receiving an alert, the Flask application processed the incoming JSON payload, extracted the attacker’s IP address, and executed a response action. This action involved invoking a system-level command to create a firewall rule that blocks inbound SSH connections from the identified malicious IP.

By doing so, the system achieved automated containment without requiring direct integration with native automation services like Azure Logic Apps.

Outcome

This implementation effectively bridged the gap between detection and response by integrating alerting with a custom webhook endpoint. It demonstrates how real-time defensive actions can be orchestrated in constrained environments, transforming a passive monitoring setup into an active response system.

Step 6: Simulating an SSH Brute Force Attack

With the environment fully prepared, I initiated a brute force attack from the Kali Linux system using Ncrack, a popular password-cracking tool.

The command used was:

ncrack -p 22 --user user -P /usr/share/wordlists/rockyou.txt 192.168.62.1

This command attempts multiple password combinations against the specified user account over SSH.

As the attack progressed, the Windows system generated multiple failed authentication events, which were forwarded to Microsoft Sentinel for analysis.

This step effectively simulated a real-world brute force attack scenario activating the alert rule and registering it on the SIEM:

HARDENING

• Disable password authentication entirely → force key-based auth only This is the first measure that should come across every one’s mind

# In sshd_config
PasswordAuthentication no

• Enable account lockout policy (Windows Security Policy): Lock after 3–5 failed attempts Lockout duration: 15–30 minutes

• I had no idea that this policy is set by default on my system which locked me out on my first attack attempt😭

• Restrict SSH access by IP (allowlist) Only allow trusted IPs:

New-NetFirewallRule -DisplayName "Allow SSH Trusted IP" `
-Direction Inbound -Protocol TCP -LocalPort 22 `
-RemoteAddress <trusted-ip> -Action Allow

These are relevant steps to take to ensure baseline hardening for any ssh server. There are other approaches with deep seated technical context but will be beyond this lab.