Build a SOC Honeypot with Sentinel

Detect real internet attackers using Microsoft Sentinel as your SIEM.

Introduction

30 Second Summary

Every computer connected to the internet is under constant attack. Automated bots scan for open ports and hammer login pages with stolen passwords around the clock.

In this project, you will build a cloud-based Security Operations Center using Microsoft Sentinel that detects real brute-force attacks against your own honeypot virtual machines. You will write detection rules, investigate incidents, and build a dashboard visualizing where attacks originate.

What You'll Build

Within minutes of deploying your honeypot VMs, real attackers start hammering them with login attempts. You will watch those attacks arrive in real time, catch them with custom detection rules, and present the results on a live dashboard you can show in interviews.

By the end of this project, you'll have:

A working SIEM ingesting live security events from Windows and Linux VMs, so you can watch real attackers hit your machines in real time.
Custom KQL analytics rules that automatically fire alerts when brute-force login thresholds are exceeded, proving you can write detections from scratch.
A fully investigated security incident with triage notes, severity assignment, and an attack timeline review you can walk through in a SOC analyst interview.
A visual attack dashboard showing failed login counts, top attacker IPs, and event frequency over time as a portfolio artifact.
Secret Mission: Add a password spraying detection rule and a suspicious PowerShell execution alert to expand your detection coverage.

Are there any prerequisites?

You will need a credit card or debit card (non-prepaid) to sign up for a free Azure account. You also need a Microsoft account or GitHub account. No prior Azure experience is required.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters.

You are building a Security Operations Center in Azure that will detect real attacks against your own infrastructure. SOC analyst roles require hands-on SIEM experience that cannot be faked. By the end of this project, you will have tangible evidence of detecting, investigating, and visualizing real threats.

Set Up Azure and Microsoft Sentinel

To detect real attacks, you first need a platform that collects and analyzes security events. That platform is Microsoft Sentinel, a cloud-native SIEM (Security Information and Event Management) system built into Azure.

Sentinel needs two things to function: an Azure subscription to host your resources, and a Log Analytics Workspace to store the security data it analyzes. In this step, you will create all three layers: the account, the workspace, and Sentinel itself.

In this step, get ready to:

Create an Azure free account with $200 credit.
Create a Resource Group and Log Analytics Workspace.
Attach Microsoft Sentinel to your workspace.

Create an Azure free account

Azure provides a free account with $200 in credit valid for 30 days. Your card will not be charged unless you explicitly upgrade to pay-as-you-go pricing later.

Open your browser and navigate to the Azure free account signup page.
Click Try Azure for free (or Start free, depending on the page layout).
Sign in with your Microsoft account or GitHub account.
Complete the identity verification with your phone number.
Enter your credit or debit card details (non-prepaid cards only).
Accept the terms and click Sign up.
Once signup completes, click Go to the Azure portal to open the portal at portal.azure.com.

Why do I need a credit card?

Azure uses the card to verify your identity. You receive $200 in free credit and will not be charged unless you manually upgrade. Prepaid cards are not accepted because they cannot complete the verification.

You should now see the Azure portal home page with your subscription listed.

Card declined or signup not working?

Make sure you are using a non-prepaid credit or debit card. Virtual cards and prepaid cards are rejected during verification.

If your browser blocks the signup flow, try disabling ad blockers or using a different browser. Help me troubleshoot my Azure signup.

Create the resource group and Log Analytics workspace

A Resource Group is a container that holds related Azure resources together. Everything in your SOC lab will live inside one resource group so you can delete it all in a single action later.

In the Azure portal search bar at the top, type Resource groups and select Resource groups from the results.
Click Create.
In the Subscription dropdown, select your Azure subscription.
In the Resource group field, enter RG-SOC-Lab.
In the Region dropdown, select East US.
Click Review + Create, then click Create.

After a few seconds, you will see a notification that the resource group has been created.

Now create the Log Analytics Workspace inside this resource group. This workspace is the data store where Sentinel will keep all your security logs.

In the Azure portal search bar, type Log Analytics and select Log Analytics workspaces.
Click Create.
In the Subscription dropdown, select your Azure subscription.
In the Resource group dropdown, select RG-SOC-Lab.
In the Name field, enter LAW-SOC-Lab.
In the Region dropdown, select East US.
Click Review + Create, then click Create.
Wait for the deployment to complete. You will see a notification confirming success.

What is a Log Analytics workspace?

A Log Analytics workspace is a centralized data store in Azure that collects log data from many sources. Microsoft Sentinel sits on top of this workspace and runs its detection logic against the data stored there.

Think of it like a database for security events. Sentinel is the analyst who queries that database to find threats.

Workspace creation failed?

Make sure you selected RG-SOC-Lab in the Resource group dropdown, not "Create new". The resource group must already exist.

If you see a naming conflict, workspace names must be unique within a resource group. Double-check you typed LAW-SOC-Lab exactly. Help me fix my Log Analytics workspace creation error.

Attach Microsoft Sentinel to your workspace

With the workspace ready, you can now enable Sentinel on top of it. Sentinel activates a 31-day free trial with 10 GB/day of free data ingestion automatically.

In the Azure portal search bar, type Microsoft Sentinel and select Microsoft Sentinel from the results.
Click Create.
In the workspace list, select LAW-SOC-Lab.
Click Add.

What happens when you click Add?

Sentinel provisions itself onto your workspace and begins its 31-day free trial. During the trial, you get 10 GB/day of free data ingestion for both Log Analytics and Sentinel analysis charges.

After March 31, 2027, Microsoft is transitioning Sentinel to the Defender portal. For this project, the Azure portal instructions work fully today.

Before you check the result, take a moment to predict what you expect to see on the Sentinel overview page. How many incidents and alerts do you think will be listed for a brand-new workspace with no data sources connected?

After provisioning completes, the Microsoft Sentinel overview page loads automatically. You should see your connected workspace name (LAW-SOC-Lab) with 0 incidents, 0 alerts, and navigation options for Data connectors, Analytics, and Workbooks visible in the left menu.

Don't see your workspace in the list?

Make sure LAW-SOC-Lab was successfully created in the previous substep. Go back to Log Analytics workspaces and confirm it appears in the list.

If the workspace appears but is grayed out, it may still be provisioning. Wait a minute and click Refresh. Help me attach Sentinel to my workspace.

Your SIEM platform is live. Next up, you will deploy Windows and Linux honeypot VMs that will attract real attackers within minutes of going online.

Deploy Honeypot VMs

Your SIEM platform is live. Microsoft Sentinel is connected to your Log Analytics Workspace and ready to analyze security events.

There is one problem. Sentinel has nothing to watch yet. In this step, you will deploy two virtual machines directly exposed to the internet with no firewall protection. These machines are called honeypots. Real attackers will find them within minutes and start hammering them with login attempts.

In this step, get ready to:

Deploy a Windows Server VM as an RDP honeypot.
Deploy a Linux VM as an SSH honeypot.
Open all ports on both VMs to attract real internet attackers.

Create the Windows honeypot VM

Your Windows VM will expose Remote Desktop Protocol (RDP) on port 3389. This is one of the most targeted ports on the internet.

In the Azure portal search bar, type Virtual machines and select the service from the results.
Click + Create.
Select Azure virtual machine.

What to expect in the wizard

The VM creation wizard has several tabs. You will configure the Basics tab and briefly check the Networking tab. Leave all other tabs at their defaults.

On the Basics tab, under Project details, set Resource group to RG-SOC-Lab.
Under Instance details, enter VM-Windows-Honeypot as the Virtual machine name.
Set Region to (US) East US.
Set Image to Windows Server 2022 Datacenter: Azure Edition - x64 Gen2.
Set Size to Standard_B1s. If you do not see it, click See all sizes and search for it.
Under Administrator account, enter a username you will remember.
Enter a password that is at least 12 characters long with uppercase, lowercase, a number, and a special character.

Remember these credentials

Write down the username and password you set for this VM. You will need them later to RDP into the machine and trigger a detection rule.

Click Next: Disks >.
Click Next: Networking >.
On the Networking tab, look at the NIC network security group field. Note the name of the NSG that Azure auto-creates (you will modify it shortly).
Click Review + create.
Click Create.

Deployment takes 1-3 minutes. Wait until you see the notification showing your deployment is complete, then click Go to resource.

You should see your Windows VM's Overview page with Status showing Running and a Public IP address assigned.

Open all ports on the Windows VM

By default, Azure's Network Security Group blocks most inbound traffic. To turn this VM into a honeypot, you need to allow all traffic from any source on any port.

In the Azure portal search bar, type Network security groups and select the service.
Click the NSG name you noted from the Networking tab (it will be associated with your Windows VM).
In the left menu under Settings, select Inbound security rules.
Click + Add.
Set Source to Any.
Set Source port ranges to *.
Set Destination to Any.
Set Destination port ranges to *.

Set Protocol to Any.
Set Action to Allow.
Set Priority to 100.
Enter a Name such as AllowAll-Inbound.
Click Add.

You should see your new rule appear in the inbound security rules list with priority 100 and Action set to Allow.

Why open all ports?

This deliberately makes the VM a honeypot. Attackers scan for open ports like 3389 (RDP) and 22 (SSH). By allowing all traffic, you guarantee attackers find and target this machine quickly.

This is safe because the VM contains no real data and will be destroyed at the end of the project.

Don't see the NSG in the list?

Make sure you are searching in the same subscription and resource group (RG-SOC-Lab) where you created the VM. The NSG name typically includes the VM name.

Help me find my Network Security Group

Create the Linux honeypot VM

Your Linux VM will expose SSH on port 22. This is the second most targeted port by automated scanners.

In the Azure portal search bar, type Virtual machines and select the service.
Click + Create, then select Azure virtual machine.
On the Basics tab, set Resource group to RG-SOC-Lab.
Enter VM-Linux-Honeypot as the Virtual machine name.
Set Region to (US) East US.
Set Image to Ubuntu Server 24.04 LTS - x64 Gen2.
Set Size to Standard_B1s.

Under Administrator account, change Authentication type to Password.
Enter a username and strong password.
Click Next: Disks >.
Click Next: Networking >.
Note the auto-created NSG name on the Networking tab.
Click Review + create.
Click Create.

Wait for the deployment to complete. Click Go to resource and confirm the VM shows Status: Running with a public IP assigned.

Now apply the same open-all-ports rule to the Linux VM's NSG. Follow the same steps you used for the Windows VM.

Search for Network security groups in the portal.
Select the NSG associated with your Linux VM.
Go to Inbound security rules and click + Add.
Set Source to Any, Source port ranges to *, Destination to Any, Destination port ranges to *, Protocol to Any, Action to Allow, Priority to 100.
Click Add.

Confirm the rule now appears in the Linux VM's NSG inbound rules list.

Why both Windows and Linux?

Real SOC environments ingest security events from multiple operating systems. Windows covers RDP brute-force attacks (port 3389) while Linux covers SSH brute-force attacks (port 22). These are the two most common attack surfaces that automated scanners target.

Running both gives you practice configuring data connectors for each platform in the next step.

VM deployment failed?

The Standard_B1s size may not be available in every region. If deployment fails with a size availability error, try selecting East US 2 as an alternative region (keep both VMs in the same region).

Also confirm your free trial subscription is active. You can check remaining credit under Cost Management + Billing in the portal.

Help me troubleshoot my VM deployment

Confirm both VMs are running

Before you move on, what do you expect to see when you navigate to the Virtual machines list? Think about the status and networking information you configured.

In the Azure portal search bar, type Virtual machines and select the service.
Confirm both VM-Windows-Honeypot and VM-Linux-Honeypot show Status: Running.
Click each VM name to open its Overview blade and note the Public IP address. Write both IPs down for reference in later steps.

Both VMs show Status: Running. Each has a public IP address visible in its Overview blade. The NSG attached to each VM shows the permissive inbound rule allowing all traffic.

What happens next?

Within minutes of being online with open ports, both VMs will start receiving automated attack traffic from the internet. Bots and scanners continuously probe public IP ranges for exposed RDP and SSH ports. Your Sentinel workspace cannot see these events yet because you have not connected the logs. That is the next step.

Your honeypots are live and exposed. Next up, you will connect the security logs from both VMs into Microsoft Sentinel so you can actually see the attacks arriving.

Connect Logs to Sentinel

Your VMs are live and exposed to the internet. Real attackers are already generating security events on both machines. The problem is that Microsoft Sentinel cannot see any of those events yet.

To bridge this gap, you need Data Collection Rules that ship events from each VM into your Log Analytics Workspace. Once connected, your lab becomes a real SOC.

In this step, get ready to:

Install the Windows Security Events and Syslog solutions from Content Hub.
Create Data Collection Rules that ship security events from both VMs to Sentinel.
Verify real attacker data is flowing by running KQL queries.

Install the Windows Security Events solution and create a data collection rule

The Windows Security Events solution bundles the data connector you need to ingest Windows event logs via the Azure Monitor Agent. You install the solution first, then configure the connector to create a Data Collection Rule targeting your Windows VM.

In Microsoft Sentinel, select Content hub from the left navigation menu.
In the search bar, type Windows Security Events.
Select the Windows Security Events solution from the results.
Click Install and wait for the installation to complete.

You should see a notification confirming the solution installed successfully.

Under Configuration in the left menu, select Data connectors.
Search for and select Windows Security Events via AMA.
Click Open connector page.
In the Configuration area, click +Create data collection rule.

A wizard opens with multiple tabs. Fill each one in order:

On the Basics tab, enter DCR-Windows as the rule name.
Select your subscription and RG-SOC-Lab as the resource group.
Click Next: Resources >.
On the Resources tab, click +Add resources.
Expand your subscription and resource group, then select your Windows VM.
Click Apply.
Click Next: Collect >.
On the Collect tab, select All Security Events.
Click Next: Review + create >, then click Create.

What just happened?

Creating the DCR through the connector page does two things automatically. It installs the Azure Monitor Agent on your Windows VM. It also starts shipping all Windows Security events (including EventID 4625 for failed logons) to your LAW-SOC-Lab workspace.

You chose "All Security Events" because your lab needs event types like 4625 (failed logon), 4688 (process creation), and 4732 (user added to group) for the detection rules you will write later.

Check the Azure notifications (bell icon in the top-right corner). You should see a confirmation that the DCR was created and agent installation started.

Don't see the Windows Security Events connector?

Go back to Content hub and confirm the Windows Security Events solution shows Installed. The data connector only appears after the solution is installed successfully.

Help me troubleshoot the missing connector

Install the Syslog solution and create a data collection rule for Linux

Your Linux VM logs SSH authentication attempts under the LOG_AUTH Syslog facility. You need a separate solution and DCR to capture these events.

Return to Content hub in Microsoft Sentinel.
Search for Syslog and select the Syslog solution.
Click Install and wait for installation to complete.

Now configure the data connector:

Under Configuration in the left menu, select Data connectors.
Search for and select Syslog via AMA.
Click Open connector page.
In the Configuration area, click +Create data collection rule.

Fill out the wizard tabs:

On the Basics tab, enter DCR-Linux as the rule name.
Select your subscription and RG-SOC-Lab resource group.
Click Next: Resources >.
On the Resources tab, click +Add resources.
Expand your subscription and resource group, then select your Linux VM.
Click Apply.
Click Next: Collect >.
On the Collect tab, find the LOG_AUTH facility row.
Set its minimum log level to LOG_DEBUG. Leave all other facilities set to NONE.
Click Next: Review + create >, then click Create.

Why LOG_AUTH at LOG_DEBUG?

SSH authentication events (both successful and failed logins) are logged under the LOG_AUTH facility on Ubuntu. Setting the minimum level to LOG_DEBUG ensures you capture everything at that severity and above, including all SSH failed-password events your detection rules need.

Check your Azure notifications again. A confirmation that DCR-Linux was created and the Azure Monitor Agent is installing on your Linux VM should appear.

Linux VM not appearing in the Resources tab?

Make sure your Linux VM has status Running in the Azure portal. Stopped or deallocated VMs do not appear in the resource picker. Also confirm you expanded the correct subscription and RG-SOC-Lab resource group.

Help me troubleshoot my missing Linux VM

Verify data is flowing with KQL queries

Data takes 5-10 minutes to start flowing after the DCRs are created. Since your VMs have been exposed to the internet since Step 2, attackers have already been hammering them with brute-force login attempts. Those events are now being shipped to Sentinel.

Wait 5-10 minutes for the Azure Monitor Agent to finish installing and begin forwarding events.
In Microsoft Sentinel, select Logs from the left navigation menu.
Close any introductory popups or query suggestions that appear.

Before you run your first query, take a moment to predict: do you think real attackers have already tried to log into your Windows VM via RDP?

Run the following KQL query to check for failed Windows login attempts:

SecurityEvent
| where EventID == 4625
| take 10

What does this query do?

This is Kusto Query Language (KQL), the query language used in Microsoft Sentinel and Log Analytics.

The query filters the SecurityEvent table for EventID 4625, which represents failed logon attempts on Windows. The take 10 operator limits results to 10 rows so you can quickly confirm data is arriving.

You should see results showing failed RDP login attempts from real attackers. Each row includes fields like TargetAccount, Computer, and IpAddress.

Now run this query to confirm Linux SSH failures are flowing:

Syslog
| where Facility == "auth"
| where SyslogMessage contains "Failed password"
| take 10

What does this query do?

This query filters the Syslog table for entries from the auth facility (LOG_AUTH). It narrows results to entries containing "Failed password", which is how Ubuntu logs failed SSH login attempts.

The attacker IP can be extracted from the SyslogMessage field. You will use this in your detection rules in the next step.

You should see SSH failed-password events from your Linux VM, confirming that both data pipelines are active.

No results returned after waiting?

If your queries return zero results, the most likely cause is that not enough time has passed. Wait an additional 5-10 minutes and try again. Data ingestion can take up to 15 minutes on initial setup.

If results still do not appear after 15 minutes, go back to Data connectors and confirm that your DCRs show a Connected status. Also verify your VMs are still running in the Azure portal.

Help me troubleshoot missing query results

Your SOC now has eyes on both machines. Real attack data is streaming into Sentinel in near real-time. Next up, you will write detection rules that automatically fire alerts when brute-force thresholds are exceeded.

Create Analytics Rules

Your logs are flowing into Sentinel, but raw data alone does not catch attackers. Without detection logic, thousands of failed login events sit in a table and nobody gets alerted.

Analytics rules are KQL queries that run on a schedule and automatically create incidents when attack thresholds are exceeded. In this step, you will write three custom detection rules that turn your honeypot logs into actionable alerts.

In this step, get ready to:

Create an RDP brute-force detection rule that fires when a single IP fails 10+ logins in an hour.
Create an SSH brute-force detection rule using Syslog data from your Linux VM.
Create a persistence detection rule that catches new local administrator accounts.

Create the RDP brute-force detection rule

Your Windows VM is already being hammered with failed RDP login attempts (EventID 4625). This first rule watches for any single IP address that fails 10 or more RDP logins within one hour.

In Microsoft Sentinel, expand Configuration in the left navigation menu.
Select Analytics.
Click + Create in the top action bar, then select Scheduled query rule.

What is a scheduled query rule?

A scheduled query rule is a KQL query that Sentinel runs at a regular interval (e.g. every 5 minutes). When the query returns results above your threshold, Sentinel automatically creates an alert and groups it into an incident for investigation.

The Analytics rule wizard opens. You will fill in the General tab first.

In the Name field, enter Brute Force RDP - Multiple Failed Logins.
Set Severity to High.
Under MITRE ATT&CK, select the tactic Credential Access and technique T1110 - Brute Force.
Click Next: Set rule logic.

Now paste the KQL detection query into the Rule query editor:

let FailedLogonThreshold = 10;
SecurityEvent
| where EventID == 4625
| where LogonType == 10
| summarize FailedAttempts = count() by AttackerIP = IpAddress, TargetComputer = Computer, bin(TimeGenerated, 1h)
| where FailedAttempts >= FailedLogonThreshold

What does this query do?

FailedLogonThreshold = 10 sets the minimum number of failures before an alert fires.
EventID == 4625 filters for Windows failed logon events specifically.
LogonType == 10 narrows results to RemoteInteractive (RDP) connections only, ignoring local login failures.
The summarize groups failures by attacker IP and target computer in 1-hour windows.
The final where keeps only groups that exceeded the threshold.

Scroll down to Query scheduling and configure the timing:

Set Run query every to 5 Minutes.
Set Lookup data from the last to 1 Hour.
Under Alert threshold, confirm it reads: Generate alert when number of query results is greater than 0.

Scroll down to the Alert enhancement section and expand Entity mapping:

Click Add new entity.
Set Entity to IP, Identifier to Address, and Value to AttackerIP.
Click Add new entity again.
Set Entity to Host, Identifier to HostName, and Value to TargetComputer.
Click Next: Incident settings, then Next: Automated response, then Next: Review and create.
When the validation passes, click Create.

Your first analytics rule is now active. You can confirm it appears under the Active rules tab on the Analytics page.

Don't see the rule in Active rules?

Make sure Status was not set to Disabled on the General tab. If it was, select the rule and click Enable.
Check that the Rule type filter on the Active rules tab is set to Select all.

Need more help? Why isn't my analytics rule appearing in Active rules?

Create the SSH brute-force detection rule

Your Linux VM logs SSH failures to the Syslog table. This rule applies the same threshold logic but parses the attacker IP from the syslog message text.

Return to the Analytics page in Sentinel.
Click + Create > Scheduled query rule.
In the Name field, enter SSH Brute Force - Multiple Failed Logins.
Set Severity to High.
Under MITRE ATT&CK, select the tactic Credential Access.
Click Next: Set rule logic.

Paste the following KQL into the Rule query editor:

let FailedLogonThreshold = 10;
Syslog
| where Facility == "auth"
| where SyslogMessage contains "Failed password"
| extend AttackerIP = extract("from ([0-9.]+)", 1, SyslogMessage)
| summarize FailedAttempts = count() by AttackerIP, HostName, bin(TimeGenerated, 1h)
| where FailedAttempts >= FailedLogonThreshold

What does this query do?

Facility == "auth" filters Syslog to authentication events only.
The contains "Failed password" clause isolates SSH login failures.
extract("from ([0-9.]+)", 1, SyslogMessage) uses a regex to pull the source IP address out of the free-text syslog message.
The rest follows the same threshold pattern as the RDP rule.

Set Run query every to 5 Minutes.
Set Lookup data from the last to 1 Hour.
Confirm the alert threshold is set to generate alerts when results are greater than 0.
Under Entity mapping, add a new entity: Entity = IP, Identifier = Address, Value = AttackerIP.
Add a second entity: Entity = Host, Identifier = HostName, Value = HostName.
Click through Next: Incident settings, Next: Automated response, and Next: Review and create.
Click Create once validation passes.

Confirm the SSH rule now appears in Active rules alongside your RDP rule.

Rule validation failed?

Double-check that the query has no extra spaces or line breaks inside the extract() regex pattern.
Verify the table name is Syslog (capital S), not syslog.

Still stuck? Help me fix my SSH brute-force analytics rule query

Create the new local administrator detection rule

Brute-force detection catches the initial attack. But what happens after an attacker gets in? A common persistence technique is creating a new local administrator account to maintain access.

Return to the Analytics page and click + Create > Scheduled query rule.
In the Name field, enter New Local Administrator Created.
Set Severity to Medium.
Under MITRE ATT&CK, select the tactic Persistence.
Click Next: Set rule logic.

Paste this KQL into the Rule query editor:

SecurityEvent
| where EventID == 4732
| where TargetSidType == "Local Group"
| where TargetAccount contains "Administrators"
| project TimeGenerated, AccountAdded = MemberName, AddedBy = Account, Computer

What does this query do?

EventID == 4732 fires when a member is added to a security-enabled local group.
Filtering for TargetAccount contains "Administrators" catches only additions to the local Administrators group.
The project statement selects only the fields you need for investigation: when it happened, who was added, who added them, and which machine.

Set Run query every to 5 Minutes.
Set Lookup data from the last to 24 Hours.
Confirm the alert threshold is greater than 0.
Under Entity mapping, add a new entity: Entity = Account, Identifier = Name, Value = AccountAdded.
Add a second entity: Entity = Host, Identifier = HostName, Value = Computer.
Click through Next: Incident settings, Next: Automated response, and Next: Review and create.
Click Create.

Why a 24-hour lookback for this rule?

Unlike brute-force attacks which happen in bursts, an attacker might create a backdoor admin account hours after initial compromise. A 24-hour lookback ensures Sentinel catches admin additions even if they happen during off-hours when nobody is watching.

Before you check the final state, predict: how many rules do you expect to see listed under Active rules?

Navigate to Analytics > Active rules tab.

You should see all three rules listed with status Enabled: Brute Force RDP - Multiple Failed Logins, SSH Brute Force - Multiple Failed Logins, and New Local Administrator Created.

When will incidents start appearing?

Your RDP and SSH brute-force rules will start firing within 10-15 minutes. Real attackers are already hammering your VMs, so once the rules run their first 5-minute cycle against the 1-hour lookback window, they will find results and create incidents automatically.

You will trigger the New Local Administrator rule manually in the next step by creating a test account.

No incidents after 15 minutes?

Go to Logs and run SecurityEvent | where EventID == 4625 | take 5 to confirm data is still flowing.
Check that your rules are Enabled (not Disabled) on the Active rules tab.
Make sure your Windows VM is still running and its NSG still has the permissive inbound rule.

Need help? Why aren't my Sentinel analytics rules generating incidents?

Your SOC now has eyes. Within minutes, Sentinel will start creating incidents as attackers trip your detection thresholds. Next up, you will investigate those incidents like a real Tier 1 SOC analyst and build a dashboard to visualize the attack patterns.

Investigate Incidents and Build a Workbook

Your analytics rules are firing and incidents are piling up. Detection without investigation is just noise.

A real SOC analyst triages incidents, assigns severity, documents findings, and builds dashboards for management. In this step, you will work through that full workflow: investigate a live incident, simulate an attacker creating a backdoor account, and build a portfolio-ready dashboard.

In this step, get ready to:

Investigate a brute-force incident and document your findings.
Trigger the "New Local Administrator Created" rule with a simulated attack.
Build and save a SOC attack dashboard with three visualizations.

Investigate a brute-force incident

Your brute-force rules have been running for several minutes. Real attackers have already triggered incidents that are waiting for triage.

In the Microsoft Sentinel sidebar, click Threat management then Incidents.
You should see one or more incidents created by your "Brute Force RDP" or "SSH Brute Force" rules. Click any incident with a High severity to open its details pane.

What is incident triage?

Triage is the process of quickly assessing an incident's severity, assigning ownership, and deciding on next steps. In a real SOC, every incident must have an owner so nothing falls through the cracks.

In the details pane, select Owner and choose Assign to me at the top of the list.
Change the Status drop-down from New to Active.
Confirm the Severity is set to High. If it is not, select High from the severity drop-down.
Click View full details to open the full incident page.

You should now see the incident timeline showing the alerts that make up this incident, along with entity details like the attacker IP and target computer.

On the left panel, click Investigate to open the investigation graph.

The investigation graph shows a visual map of entities directly connected to the incident. You should see the attacker IP address, the target computer, and the timeline of alerts.

Review the entity graph, noting the attacker IP address shown. Then close the investigation graph by clicking the X or navigating back to the incident details.
Click Activity log at the top of the incident details page.
In the rich text editor at the bottom of the Activity log, type a comment documenting your findings. For example: "Multiple failed RDP attempts from IP X.X.X.X. Confirmed brute-force attack. No successful logons from this IP." Replace X.X.X.X with the actual attacker IP you saw in the graph.
Click Comment to submit.

Your comment now appears at the top of the Activity log. The incident shows status Active, assigned to you, with your investigation notes recorded.

Don't see any incidents?

Analytics rules run every 5 minutes. If your VMs have only been running for a short time, wait 10-15 minutes and refresh the Incidents page. Brute-force attacks against exposed RDP and SSH ports typically start within minutes of deployment.

Also confirm your rules are enabled by checking Analytics > Active rules.

Help me troubleshoot why my Sentinel analytics rules aren't generating incidents.

Trigger the New Local Administrator rule

Your third analytics rule detects when someone adds a user to the local Administrators group. You will now simulate this attacker technique by RDP-ing into your Windows VM and creating a backdoor admin account.

Press the Windows key and type Remote Desktop Connection. Press Enter to open it.
In the Computer field, paste your Windows VM's public IP address (the one you noted in Step 2).
Click Connect. When prompted, enter the username and password you set when creating the Windows VM.
You may see a certificate warning. Click Yes to proceed.

You should now see the Windows Server desktop of your VM.

Right-click the Start button and select Windows PowerShell (Admin).
Create a test user by running this command:

net user SOCTestUser P@ssw0rd123! /add

Add the user to the local Administrators group by running:

net localgroup Administrators SOCTestUser /add

What do these commands simulate?

This simulates a common attacker persistence technique. After gaining initial access, attackers create local admin accounts as backdoors. Your "New Local Administrator Created" rule monitors EventID 4732 (member added to a security-enabled local group) and will fire an incident when it detects this action.

Close the RDP session by clicking the X on the Remote Desktop bar at the top of your screen.

Before you check, do you think the new incident will appear immediately or will it take a few minutes? Think about how often your analytics rule runs.

Back in the Azure portal, return to Incidents in Microsoft Sentinel. Wait 5-10 minutes and refresh the page.

You should see a new incident from the "New Local Administrator Created" rule with Medium severity. This confirms your persistence detection is working.

New admin incident not appearing?

The rule runs every 5 minutes with a 24-hour lookback. Give it up to 10 minutes after running the PowerShell commands. Confirm the commands completed successfully by checking for no error output in the PowerShell window before you closed it.

Help me understand why my New Local Administrator rule hasn't fired after creating SOCTestUser.

Build the SOC Attack Dashboard workbook

Dashboards turn raw data into visual stories that management can understand at a glance. You will now build a workbook with three KQL visualizations showing attack patterns against your honeypot.

In Microsoft Sentinel, click Threat management then Workbooks.
Click + Add workbook.
In the new workbook, click Edit in the toolbar to enter edit mode.
Remove any default elements by clicking the ... (ellipsis) next to existing items and selecting Remove.
Add your first visualization by clicking Add then Add query.

A query editor panel appears. Paste the following KQL query to chart Windows failed logins over time:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by bin(TimeGenerated, 1h)
| render timechart

Set Visualization to Set by query (the render timechart directive handles this automatically).
Click Run Query. You should see a time chart with spikes showing when failed login attempts peaked.
Click Done Editing on this query element.

What does this query show?

This query pulls all Windows failed logon events (EventID 4625), groups them into 1-hour time buckets, and renders them as a time chart. Spikes in the chart reveal when attackers were most aggressively hammering your RDP port.

Add a second visualization by clicking Add then Add query. Paste this KQL to show the top 10 attacker IPs:

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by IpAddress
| top 10 by FailedAttempts
| render barchart

Click Run Query. A bar chart appears showing which IP addresses have sent the most failed login attempts.
Click Done Editing on this query element.

What does this query show?

This groups all failed Windows logins by source IP address, takes the top 10 by count, and renders a bar chart. The tallest bar is the IP that has attacked your VM the most.

Add a third visualization by clicking Add then Add query. Paste this KQL to chart Linux SSH failures over time:

Syslog
| where Facility == "auth"
| where SyslogMessage contains "Failed password"
| summarize FailedAttempts = count() by bin(TimeGenerated, 1h)
| render timechart

Click Run Query. A time chart appears showing SSH brute-force attempts against your Linux VM over time.
Click Done Editing on this query element.

What does this query show?

This filters the Syslog table for authentication events containing "Failed password" (SSH failures), groups them by hour, and renders a time chart. This is your visibility into Linux-side attacks.

Click Done editing at the top of the workbook to exit edit mode.
Click the Save icon (floppy disk) in the toolbar.
In the save pane, enter SOC Attack Dashboard as the title.
Select the subscription and resource group for your workspace, then click Save.

Your workbook is now saved. You should see all three visualizations displayed with real attack data from your honeypot VMs.

Query returning no results?

If a query shows no data, check the time range selector at the top of the query editor. Set it to Last 24 hours or wider. If your VMs have been running less than an hour, try Last 4 hours.

Help me troubleshoot why my workbook KQL query is returning empty results in Microsoft Sentinel.

Before you move on, review your completed dashboard. Take a screenshot of it for your portfolio, showing all three visualizations with real attack data.

What do you expect to see in the Incidents page if you navigate back there now? Think about how many incidents should exist and what their statuses are.

Navigate back to Incidents to confirm: you should see at least one incident with status Active, assigned to you, with your investigation comment visible in the Activity log.

Your SOC is fully operational. You have detected real attacks, investigated an incident with full triage documentation, triggered a persistence detection, and built a visual dashboard for reporting. Next up, the Secret Mission challenges you to expand your detection coverage even further.

Secret mission

Expand Detection Coverage

A real SOC has layered defenses. Your three rules catch brute-force attacks and new admin accounts, but attackers have more tricks. Can you write KQL that detects password spraying and suspicious PowerShell execution to bring your total coverage to five custom detections mapped to MITRE ATT&CK?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your VMs are covered by your $200 Azure free account credit, but they consume approximately $0.012/hr each while running.

Cost warning

Your two VMs (Standard_B1s) cost approximately $0.012/hr each while running. The Sentinel free trial covers 10 GB/day of ingestion for 31 days. If you leave everything running, the VMs alone will consume roughly $0.58/day from your $200 credit.

If you have captured your portfolio screenshots, deleting everything is the safest option to avoid unexpected charges after your trial ends.

Resources you used:

Windows VM (Windows Server 2022 Datacenter, Standard_B1s) in RG-SOC-Lab.
Linux VM (Ubuntu Server 24.04 LTS, Standard_B1s) in RG-SOC-Lab.
Log Analytics Workspace (LAW-SOC-Lab).
Microsoft Sentinel (attached to LAW-SOC-Lab).
Data Collection Rules (DCR-Windows and DCR-Linux).
Network Security Groups, public IP addresses, managed disks, and network interfaces.
SOC Attack Dashboard workbook.

Keep everything running

No action needed. Choose this if you are still actively collecting attack data and refining your detection rules.

Monitor your remaining credit by navigating to Cost Management + Billing in the Azure portal.
Your two VMs will continue to attract real attacks and generate Sentinel incidents.
Remember that the Sentinel 31-day free trial and your $200 credit both have expiry dates.

Pause - I'll come back to this later

Stop (deallocate) both VMs to halt compute charges while keeping your Sentinel workspace, analytics rules, and collected data intact. You can restart the VMs later.

In the Azure portal, search for Virtual machines and select the service.
Select your Windows VM.
Click Stop in the top toolbar, then confirm. Wait until the status shows Stopped (deallocated).
Repeat for your Linux VM.
Confirm both VMs show Stopped (deallocated) in the portal. Compute charges stop in this state, but disk storage charges continue at a minimal rate.

Why deallocate from the portal?

Shutting down from inside the VM OS leaves the VM in a Stopped (Allocated) state where compute charges continue. You must click Stop in the Azure portal to deallocate and halt billing.

Delete - I don't want to use this again

Remove all project resources by deleting the entire resource group. This permanently destroys the VMs, Log Analytics Workspace, Sentinel instance, analytics rules, workbooks, and all associated networking resources.

In the Azure portal, search for Resource groups and select the service.
Select RG-SOC-Lab from the list.
Click Delete resource group at the top of the page.
Type RG-SOC-Lab in the confirmation field to confirm the deletion.
Click Delete. Azure will remove all resources within the group. This may take a few minutes.
Once deletion completes, verify that RG-SOC-Lab no longer appears in your Resource groups list. No further charges will accrue.

This action is irreversible

Deleting the resource group permanently removes all VMs, the Log Analytics Workspace, Microsoft Sentinel, your analytics rules, workbook, incidents, and all ingested data. Make sure you have saved any screenshots or exported any queries you want to keep.

Nice Work!

You just built a fully operational Security Operations Center in the cloud using Microsoft Sentinel. Real attackers found your honeypot VMs within minutes, and you detected, investigated, and visualized their activity like a Tier 1 SOC analyst.

You've learned how to:

Deploy honeypot VMs with open Network Security Groups and connect their security logs to a SIEM using Data Collection Rules and the Azure Monitor Agent.
Write custom KQL analytics rules that automatically detect brute-force attacks and suspicious activity, mapped to MITRE ATT&CK tactics and techniques.
Investigate real security incidents end-to-end and build a SOC analyst workbook visualizing attack patterns, top attacker IPs, and event frequency over time.
Secret Mission: Added password spraying and suspicious PowerShell execution detection rules, bringing total coverage to 5 custom detections.

Ready to quiz yourself?