Build a Security Monitoring System

Monitor a Windows VM on Azure with KQL queries and automated alerts.

Introduction

30 Second Summary

Every day, cloud servers face thousands of unauthorized login attempts from automated bots around the world. Without a monitoring system in place, these attacks go completely unnoticed until real damage is done.

In this project, you will build a security monitoring system on Azure that detects suspicious activity on a Windows Server virtual machine and automatically alerts you when threats are detected.

What You'll Build

A complete security monitoring pipeline using Azure Monitor, Log Analytics, and Microsoft Defender for Cloud that collects logs from a VM, queries them for threats, and fires alerts on suspicious activity.

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

  • A Windows Server VM deployed on Azure with security log collection configured via Data Collection Rules.
  • A Log Analytics workspace ingesting security events, with KQL queries that hunt for failed login attempts.
  • An automated alert rule that emails you when suspicious activity is detected on your VM.
  • Secret Mission: Leave RDP open to the internet and observe real-world attack traffic flooding in from bots and scanners.

Are there any prerequisites?

You need an Azure account to complete this project. A free account comes with $200 credit for 30 days, which is more than enough to cover all resources in this project.

Set Up Your Azure Environment

Every security monitoring system needs a foundation. Before you can detect threats or analyze suspicious activity, you need infrastructure to collect and store your log data.

In this step, you'll set up the Azure environment that powers your monitoring system. You'll create a resource group to organize your resources and a Log Analytics workspace to store your security logs.

In this step, get ready to:
  • Sign in to the Azure Portal.
  • Create a resource group to contain all project resources.
  • Create a Log Analytics workspace for collecting security logs.
Sign in to the Azure Portal
  • Open your browser and navigate to portal.azure.com.
  • Sign in with your Azure account credentials.

Don't have an Azure account yet?

You can create a free Azure account at azure.microsoft.com/free. This gives you $200 in credit to use within the first 30 days.

Create a resource group

A resource group is a container that holds all the related Azure resources for your project. It makes it easy to manage, monitor, and delete everything together when you're done.

  • In the search bar at the top of the Azure Portal, type Resource groups and select it from the results.
  • Click Create.
  • In the Subscription dropdown, select your Azure subscription.
  • In the Resource group field, enter security-monitoring-rg.
  • In the Region dropdown, select East US.
  • Click Review + Create.
  • Click Create.

What is a resource group?

Think of a resource group like a folder on your computer. It groups related resources together so you can manage them as a single unit. When this project is done, you can delete the entire resource group to remove everything at once.

Your resource group is created in a few seconds. You should see security-monitoring-rg listed on the Resource groups page.

Don't see your resource group?

Click Refresh at the top of the Resource groups list. It can take a few seconds for newly created groups to appear.

help me find my resource group in the Azure Portal

Create a Log Analytics workspace

A Log Analytics workspace is where Azure stores and organizes all the log data collected from your resources. You'll query this workspace later to hunt for suspicious activity.

  • In the search bar at the top of the Azure Portal, type Log Analytics workspaces and select it from the results.
  • Click Create.
  • In the Subscription dropdown, select your Azure subscription.
  • In the Resource group dropdown, select security-monitoring-rg.
  • In the Name field, enter security-monitoring-law.
  • In the Region dropdown, select East US.
  • Click Review + Create.
  • Click Create.

What is a Log Analytics workspace?

A Log Analytics workspace is a centralized data store for log data from your Azure resources. It collects events, performance metrics, and security logs into one place where you can search and analyze them.

There's no direct cost for creating the workspace itself. You're only charged for the data you send into it, and the first 5 GB per month is free.

Wait for the deployment to complete. You should see a notification confirming your workspace was created successfully.

  • Click Go to resource in the deployment notification to verify your new workspace.

You should see the security-monitoring-law workspace overview page with its region set to East US.

Deployment failed?

Make sure you selected security-monitoring-rg as the resource group. The workspace name must be unique within the resource group. If you see a naming conflict, double-check that you don't already have a workspace with the same name.

help me troubleshoot my Log Analytics workspace deployment

Your Azure environment is ready. Next up, you'll deploy a Windows Server virtual machine and give your monitoring system something to watch.

Deploy a Windows Server VM

Your resource group and Log Analytics workspace are ready. Now you need something to actually monitor.

In this step, you will deploy a Windows Server virtual machine. Windows Server generates detailed Security Event Logs that record every login attempt, permission change, and security-related action. These logs are exactly what your monitoring system will analyze to detect threats.

In this step, get ready to:
  • Create a Windows Server 2022 virtual machine in your resource group.
  • Configure the network to allow RDP access.
  • Verify the VM is running and note its public IP address.
Create a new virtual machine

A virtual machine is a computer running in the cloud. You will deploy one running Windows Server, which produces the security logs your monitoring system needs.

  • In the Azure Portal search bar at the top, type virtual machines.
  • Under **Services**, select Virtual machines.
  • Click Create at the top of the page, then select Azure virtual machine from the dropdown.

The Create a virtual machine page opens with several tabs of configuration options.

  • Under Resource group, select security-monitoring-rg from the dropdown.
  • Under Virtual machine name, enter monitoring-vm.
  • Under Region, select (US) East US.
  • Under Image, select Windows Server 2022 Datacenter: Azure Edition - x64 Gen2.
  • Under Size, click See all sizes and search for Standard_B1s. Select it and click Select.

Why Standard_B1s?

The Standard_B1s is a burstable VM with 1 vCPU and 1 GB of memory. It is eligible for the Azure free tier (750 hours per month for 12 months on new accounts). For this project, it provides enough resources to generate security logs without significant cost.

  • Under Administrator account, enter a username (for example, azureuser).
  • Enter a password. The password must be at least 12 characters long and include uppercase, lowercase, a number, and a special character.
  • Confirm the password by entering it again.

Remember your credentials

Write down your username and password somewhere safe. You will need them if you connect to the VM later via Remote Desktop.

Configure networking and deploy the VM

Your VM needs a network rule that allows Remote Desktop Protocol (RDP) connections. This lets you connect to the VM and also generates the security log events your monitoring system will track.

  • Click the Networking tab at the top of the page.
  • Under Select inbound ports, confirm that RDP (3389) is selected. If it is not, click the dropdown and select it.
  • Leave all other settings at their defaults.
  • Click Review + create at the bottom of the page.
  • After validation passes, click Create.

What is RDP?

RDP (Remote Desktop Protocol) allows you to connect to a Windows machine over the network as if you were sitting in front of it. Opening port 3389 allows this connection from the internet.

For this project, the open RDP port also serves as a honeypot. Internet bots constantly scan for open RDP ports and attempt to break in. Your monitoring system will detect those login attempts.

Azure will now deploy your virtual machine. This typically takes 1-3 minutes.

Deployment failed?

If you see a quota error, your subscription may not have capacity for Standard_B1s in East US. Try selecting a different region like West US 2 or Central US.

If the Standard_B1s size does not appear in the size list, make sure you selected an x64 image (not ARM-based) and that your subscription has available quota.

Help me troubleshoot my VM deployment error.

Verify the VM is running
  • Once deployment completes, click Go to resource.
  • On the VM's Overview page, confirm the Status shows Running.
  • Find the Public IP address field on the Overview page. Write this IP address down. You will need it later.

What is the public IP address?

The public IP address is how your VM is reachable from the internet. Anyone (including automated bots) can attempt to connect to this IP on open ports. This is what makes your VM discoverable for the Secret Mission later.

Your virtual machine is live and generating security events. Next up, you will configure Azure Monitor to collect those security logs and send them to your Log Analytics workspace for analysis.

Configure Security Log Collection

Your VM is running, but right now you have zero visibility into what's happening on it. If someone tries to log in with the wrong password, you'd never know.

In this step, you'll create a Data Collection Rule that streams Windows Security Event Logs from your VM into your Log Analytics workspace. This gives you a live feed of every login attempt, permission change, and security-relevant event happening on your machine.

In this step, get ready to:
  • Create a Data Collection Rule to define what logs to collect and where to send them.
  • Connect your VM and configure the Windows Security event log category.
  • Verify the rule is saved and the Azure Monitor Agent is automatically installed.
Create a Data Collection Rule

A Data Collection Rule (DCR) defines three things: what data to collect, which machines to collect it from, and where to send it. You'll create one now that targets your VM's security logs.

  • In the Azure Portal, type Monitor in the top search bar and select Monitor from the results.
  • In the left menu under Settings, click Data Collection Rules.
  • Click + Create to open the DCR creation pane.

You'll land on the Basics tab. Fill in the following settings:

  • For Rule Name, enter windows-security-dcr.
  • For Resource Group, select security-monitoring-rg.
  • For Region, confirm it is set to East US (must match your Log Analytics workspace region).
  • For Platform Type, select Windows.
  • Click Next : Resources > to continue.

What is a Data Collection Rule?

A DCR is the bridge between your VM and your Log Analytics workspace. It tells Azure Monitor exactly which events to collect from the guest operating system and where to store them for analysis.

Setting the Platform Type to Windows makes Windows-specific data sources (like Windows Event Logs) available in the next step.

Add your VM and configure security event logs

Now you'll point the DCR at your VM and tell it to collect security events specifically.

  • On the Resources tab, click + Add resources.
  • Expand your subscription, then expand security-monitoring-rg.
  • Check the box next to monitoring-vm and click Apply.
  • Click Next : Collect and deliver > to move to the data source configuration.

Now configure what data to collect and where to send it:

  • Click + Add data source.
  • In the Data source type dropdown, select Windows Event Logs.
  • Under the Security category, check both Audit success and Audit failure.
  • Switch to the Destination tab within the data source pane.
  • Confirm the destination type is set to Azure Monitor Logs.
  • Select your security-monitoring-law workspace as the destination.
  • Click Add data source to save this configuration.

Why Audit success and Audit failure?

Windows Security Event Logs categorize events by outcome. Audit success captures every successful login (Event ID 4624). Audit failure captures every failed login attempt (Event ID 4625).

Collecting both gives you a complete picture. You can see who got in and who tried but failed.

Save the rule and verify the agent installation
  • Click Review + create.
  • Review the summary to confirm your settings match: resource monitoring-vm, data source Windows Event Logs (Security), destination security-monitoring-law.
  • Click Create.

Azure will deploy the Data Collection Rule. This also automatically installs the Azure Monitor Agent on your VM and begins collecting Windows Security Event Logs.

What happens behind the scenes?

When you associate a VM with a DCR, Azure automatically installs the Azure Monitor Agent (AMA) on that VM. The agent downloads the DCR configuration and begins streaming the specified events to your Log Analytics workspace.

You don't need to install anything manually. The DCR handles everything.

  • Wait for the deployment notification to show success. This typically takes under a minute.
  • Navigate back to Data Collection Rules in the Monitor menu. You should see windows-security-dcr listed.

Don't see your DCR listed?

Make sure you're looking at the correct subscription in the portal filter bar. The DCR only appears under the subscription where you created it.

If the deployment failed, check that your region is set to East US (it must match your Log Analytics workspace region).

Help me troubleshoot my Data Collection Rule deployment.

Data takes a few minutes to arrive

Security events won't appear in your Log Analytics workspace immediately. Allow 15-20 minutes for the initial data to flow through. You'll query these logs in an upcoming step.

Your VM is now streaming security event logs into your workspace. Next up, you'll enable Microsoft Defender for Cloud to get a comprehensive security posture assessment of your entire environment.

Enable Microsoft Defender for Cloud

Collecting logs tells you what happened. But how do you know which of those events actually matter, or what security gaps your setup has right now?

Microsoft Defender for Cloud continuously evaluates your resources against security benchmarks and gives you a Secure Score that shows your overall security posture. In this step, you will enable Defender for Cloud on your subscription and explore the security recommendations it generates for your VM.

In this step, get ready to:
  • Review your security posture on the Microsoft Defender for Cloud Overview page.
  • Enable the Defender for Servers Plan 1 trial for advanced security alerts.
  • Explore your Secure Score and security recommendations for your VM.
Navigate to Microsoft Defender for Cloud

The Defender for Cloud Overview page shows your overall security posture at a glance. The Foundational CSPM plan is automatically enabled at no cost on all Azure subscriptions.

  • In the Azure Portal search bar at the top, type Microsoft Defender for Cloud and select it from the results.
  • On the Overview page, review the security posture tile. This shows your current Secure Score as a percentage.
  • Note the summary cards showing active recommendations and security alerts for your subscription.

What is Foundational CSPM?

Foundational Cloud Security Posture Management (CSPM) is enabled by default on all Azure subscriptions at no cost. It includes asset inventory, security recommendations, Secure Score, and the Microsoft Cloud Security Benchmark.

It continuously assesses your resources and generates recommendations when it finds security gaps. The higher your Secure Score, the lower your identified risk level.

Enable Defender for Servers Plan 1

The Foundational CSPM gives you posture management, but it does not generate security alerts for threats on your VM. Defender for Servers Plan 1 adds threat detection and security alerts.

  • In the Defender for Cloud left menu, under Management, select Environment settings.
  • Expand your management group if needed, then select your Azure subscription from the list.
  • On the Defender plans page, find the Servers row.
  • Toggle the Servers plan status to On. Select Plan 1 if prompted to choose between Plan 1 and Plan 2.
  • Click Save at the top of the page.

What does Defender for Servers Plan 1 cost?

Defender for Servers Plan 1 costs $4.906/server/month after the trial period. The first 30 days are free. You can disable it before the trial ends to avoid charges.

Don't see your subscription listed?

Check your directory and subscription filters in the Azure Portal top bar. Make sure the subscription you created security-monitoring-rg in is selected.

Help me find my subscription in Defender for Cloud Environment settings.

Review your Secure Score and recommendations

Now that Defender for Servers is active, Defender for Cloud will assess your VM against security benchmarks. The Recommendations page shows specific issues and how to fix them.

  • In the Defender for Cloud left menu, select Overview to return to the main dashboard.
  • Click the Secure Score tile to see a breakdown by subscription.
  • Note your current score. A score below 100% means Defender for Cloud has found security gaps to address.
  • In the left menu, select Recommendations.
  • Review the list of recommendations. Look for items related to your monitoring-vm or security-monitoring-rg resource group.

What kind of recommendations will I see?

You will likely see recommendations about restricting network access (your VM has RDP open to the internet), enabling disk encryption, or applying system updates. Each recommendation includes a severity level and remediation steps.

These recommendations are generated by the Microsoft Cloud Security Benchmark, which defines expected security configurations for Azure resources.

Recommendations may take a few minutes

If you do not see recommendations for your VM yet, wait a few minutes. Defender for Cloud needs time to assess newly discovered resources after you enable a plan.

Your VM is now protected by Microsoft Defender for Cloud. You have a Secure Score tracking your security posture, and actionable recommendations showing you what to fix. Next up, you will query the security logs your VM has been generating to hunt for suspicious activity.

Query Security Logs with KQL

Your monitoring pipeline is live. Microsoft Defender for Cloud is assessing your posture, and Windows Security Event Logs are streaming into your workspace.

Collecting logs is only half the story. You need to actively search through them to find suspicious activity. In this step, you will use Kusto Query Language (KQL) to query your security logs and hunt for failed login attempts on your VM.

In this step, get ready to:
  • Confirm security events are flowing into your Log Analytics workspace.
  • Write a KQL query to find failed login attempts.
  • Build an advanced query that summarizes login patterns over time.
Confirm security events are flowing

Before writing complex queries, you need to verify that your workspace is actually receiving data from the VM. A quick test query confirms the pipeline is working end to end.

  • In the Azure Portal, search for Log Analytics workspaces in the top search bar and select it.
  • Click on security-monitoring-law to open your workspace.
  • In the left menu under General, click Logs.
  • If a Queries dialog appears, close it by clicking the X in the top-right corner of the dialog. You want the blank query editor.
  • Make sure the query editor is set to KQL mode (check the dropdown in the top-right corner of the editor).
  • Paste the following query into the query editor and click Run (or press Shift+Enter):
SecurityEvent
| take 10

What does this query do?

This is the simplest possible KQL query. It grabs 10 rows from the SecurityEvent table so you can confirm data exists.

The pipe character (|) chains operators together. take 10 limits the output to 10 records so the query returns almost instantly.

You should see a table of 10 rows with columns like TimeGenerated, Computer, EventID, and Activity. This confirms your VM is sending security events to the workspace.

No results returned?

  • Make sure your VM (monitoring-vm) is still running. A stopped VM does not generate logs.
  • Check that at least 15-20 minutes have passed since you created the Data Collection Rule. It takes time for the Azure Monitor Agent to begin forwarding data.
  • Verify the time range picker at the top of the Logs blade is set to Last 24 hours or wider.

Help me troubleshoot why my Log Analytics query returns no SecurityEvent data.

Query for failed login attempts

Every time someone (or something) tries to log into your VM and fails, Windows records it as Event ID 4625. This is one of the most important signals in security monitoring because a burst of failed logins usually means someone is trying to break in.

  • Clear the query editor and paste the following query, then click Run:
SecurityEvent
| where EventID == 4625
| project TimeGenerated, Computer, Account, Activity
| order by TimeGenerated desc

What does this query do?

  • where EventID == 4625 filters to only failed login events.
  • project TimeGenerated, Computer, Account, Activity selects just the four columns you care about, keeping results clean and readable.
  • order by TimeGenerated desc puts the most recent failures at the top so you see the latest activity first.

Event ID 4625 is the Windows Security Event for a failed logon attempt. Event ID 4624 is its counterpart for a successful logon.

You may see results immediately if bots have already attempted to log into your VM via RDP. If you see zero results, that simply means no failed logins have occurred yet.

Query runs but returns zero rows?

This is normal if your VM has not yet been targeted by external login attempts. Your VM has RDP open to the internet, so failed attempts typically start appearing within 20-30 minutes of deployment.

Why does my SecurityEvent query for EventID 4625 return no results?

Summarize login activity over time

Individual events are useful, but security analysts need to spot patterns. A summary query groups login successes and failures into time buckets so you can see spikes at a glance.

  • Clear the query editor and paste the following query, then click Run:
SecurityEvent
| where EventID in (4624, 4625)
| summarize SuccessCount = countif(EventID == 4624), FailCount = countif(EventID == 4625) by bin(TimeGenerated, 5m)
| order by TimeGenerated desc

What does this query do?

  • where EventID in (4624, 4625) grabs both successful (4624) and failed (4625) login events.
  • summarize ... by bin(TimeGenerated, 5m) groups events into 5-minute buckets and counts successes and failures in each bucket.
  • countif(EventID == 4624) counts only the successes. countif(EventID == 4625) counts only the failures.

This pattern is how security teams detect brute-force attacks. A sudden spike in FailCount with zero SuccessCount means someone is hammering your VM with bad passwords.

You should see a results table with columns for TimeGenerated, SuccessCount, and FailCount. Each row represents a 5-minute window of login activity on your VM.

Only seeing zeros in the FailCount column?

If your VM is relatively new, bots may not have discovered it yet. You will have a chance to observe real attack traffic in the Secret Mission later. For now, confirm that SuccessCount shows values (your own login or system services generate successful auth events).

Help me understand my KQL login summary results.

You now have the core skill of a security analyst. You can query raw logs to hunt for threats and summarize patterns over time. Next up, you will create an automated alert rule so Azure notifies you the moment suspicious activity happens.

Create a Security Alert Rule

You've written KQL queries that detect failed login attempts in your security logs. That's powerful for manual investigation, but it requires you to be actively watching.

In this step, you'll turn your manual query into an automated alert. Azure Monitor will continuously run your failed login query and send you an email the moment suspicious activity is detected.

In this step, get ready to:
  • Create an alert rule from your failed login KQL query.
  • Set up an Action Group that sends email notifications.
  • Configure the alert threshold and severity level.
Run your failed login query and create an alert rule

Alert rules in Azure Monitor evaluate a query on a schedule and fire when results cross a threshold you define. You'll start by running the same failed login query from the previous step, then convert it directly into an alert rule.

  • Return to your security-monitoring-law Log Analytics workspace in the Azure Portal.
  • Select Logs from the left menu.
  • If the Queries dialog appears, close it.
  • Enter the following query in the query editor:
SecurityEvent
| where EventID == 4625
| project TimeGenerated, Computer, Account, Activity
| order by TimeGenerated desc
  • Click Run to confirm results appear.
  • Click New alert rule in the toolbar above the query results.

What does New alert rule do?

This pre-populates a new alert rule with your query and automatically sets the scope to your Log Analytics workspace. You do not need to configure the scope manually.

You are now in the alert rule creation wizard. Configure the threshold on the Condition tab.

  • Under Measurement, confirm the measure is set to Table rows.
  • Set the Aggregation granularity (Period) to 5 minutes.
  • Under Alert logic, set the Operator to Greater than.
  • Set the Threshold value to 3.
  • Set the Frequency of evaluation to 5 minutes.

What do these threshold settings mean?

Every 5 minutes, Azure Monitor runs your KQL query against the last 5 minutes of data. If the query returns more than 3 rows (meaning more than 3 failed logins), the alert fires.

This combination avoids false positives from a single mistyped password while still catching suspicious bursts of failed attempts.

Create an Action Group with email notification

An Action Group defines who gets notified and how when an alert fires. You'll create one that sends an email to your address.

  • Select the Actions tab at the top of the alert rule wizard.
  • Click Select action groups, then click Create action group.
  • In the Basics tab, select security-monitoring-rg as the Resource group.
  • Set the Action group name to security-alerts-ag.
  • Set the Display name to security-alerts-ag.
  • Select the Notifications tab.
  • Under Notification type, select Email/SMS message/Push/Voice.
  • In the pane that opens, check the Email checkbox and enter your email address.
  • Click OK to close the notification pane.
  • Give the notification a name, such as Email notification.
  • Click Review + create, then click Create.

What is an Action Group?

An Action Group is a reusable collection of notification preferences. Once created, you can attach it to multiple alert rules across your subscription.

Besides email, Action Groups support SMS, push notifications, webhooks, and Azure Functions. For this project, email is all you need.

Not seeing the email notification type?

Make sure you are on the Notifications tab inside the action group wizard, not the Actions tab. Notifications handle people-facing alerts (email, SMS). Actions handle automated responses (webhooks, functions).

help me find the Notifications tab in the Action Group wizard

Name the alert rule and set severity

With the Action Group created, you're back in the alert rule wizard. Now you'll give the rule a name and severity level so your team can prioritize it when it fires.

  • Select the Details tab at the top of the alert rule wizard.
  • Set the Alert rule name to Failed Login Alert.
  • Set the Severity to 2 - Warning.
  • Leave all other settings at their defaults.
  • Click Review + create at the bottom.
  • Review the summary, then click Create.

What are severity levels?

Azure Monitor uses severity levels from 0 (Critical) to 4 (Verbose). Sev 2 (Warning) means the alert needs attention but is not an emergency.

Failed login attempts are suspicious and worth investigating, but a handful of them does not mean your system is breached. Warning is the right level here.

After creating the rule, you should see a confirmation that your alert rule was successfully created.

Alert rule creation failed?

Make sure your Log Analytics workspace has data in the SecurityEvent table. Alert rules validate that the query can return results. If your VM was recently created or stopped, data may not have arrived yet.

Also confirm you selected security-monitoring-rg as the resource group for the action group. Mismatched permissions between resource groups can block creation.

help me troubleshoot why my alert rule creation failed in Azure Monitor

Your security monitoring system is now fully automated. Azure Monitor will run your failed login query every 5 minutes and email you whenever more than 3 failed attempts are detected. Next up, you'll put this system to the test with real-world attack traffic in the Secret Mission.

Secret mission

Observe Real-World Attack Traffic

Your VM has RDP (port 3389) open to the entire internet. Internet-facing machines with open RDP get hammered by automated bots and scanners within minutes. Your mission is to leave it open, wait 20-30 minutes, then use your monitoring system to observe the flood of malicious login attempts.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Your VM and Log Analytics workspace are consuming Azure credits while active. The B1s VM is covered by the free tier for the first 12 months (new accounts), but the Defender for Servers Plan 1 trial expires after 30 days and charges $4.906/server/month afterward.

Cost warning

If you leave the VM running and forget to disable Defender for Servers after the 30-day trial, you will be charged $4.906/server/month for Defender for Servers Plan 1. The VM itself costs approximately $0.01/hr if you are no longer covered by the free tier.

If you are not planning to continue this project, choose Pause or Delete below to stop charges.

Resources you used:

  • Windows Server VM (monitoring-vm, Standard_B1s) in security-monitoring-rg.
  • Log Analytics workspace (security-monitoring-law) in security-monitoring-rg.
  • Data Collection Rule (windows-security-dcr) in security-monitoring-rg.
  • Alert rule (Failed Login Alert) and action group (security-alerts-ag) in security-monitoring-rg.
  • Microsoft Defender for Servers Plan 1 trial (subscription-level setting, not in the resource group).

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with KQL queries and alert rules.

  • The B1s VM is covered by the Azure free tier (750 hours/month) for 12 months on new accounts.
  • Log Analytics ingestion is free for the first 5 GB/month per billing account.
  • Defender for Servers Plan 1 trial is free for 30 days from when you enabled it.
  • Make sure your NSG restricts RDP access to your IP only. Never leave port 3389 open to the internet on a running system.
  • Monitor your spending in Azure Cost Management to avoid surprises.

Pause - I'll come back to this later

Stop the VM to free up compute charges while keeping your workspace, rules, and configuration intact.

  • In the Azure Portal, navigate to Virtual machines and select monitoring-vm.
  • On the VM's Overview page, click Stop in the command bar.
  • Confirm the stop action when prompted.
  • Wait for the status to show Stopped (deallocated). This means compute charges have stopped.
  • Your disk and Log Analytics workspace will remain but cost very little.
  • To disable Defender for Servers (and avoid charges after the 30-day trial): navigate to Microsoft Defender for Cloud, select Environment settings, select your subscription, toggle Servers to Off, then click Save.

What does Stopped (deallocated) mean?

A VM that is merely "Stopped" (shut down from inside the OS) still reserves compute resources and incurs charges. You must use the Stop button in the Azure Portal to deallocate. Look for the status Stopped (deallocated) to confirm billing has stopped.

Delete - I don't want to use this again

Remove all project resources and start fresh. Deleting the resource group removes the VM, workspace, DCR, alert rule, action group, and NSG in one action.

  • First, disable Defender for Servers at the subscription level so it does not continue charging after the trial expires.
  • Navigate to Microsoft Defender for Cloud in the Azure Portal.
  • Select Environment settings.
  • Select your subscription.
  • Toggle Servers to Off.
  • Click Save.
  • Next, delete the resource group. Navigate to Resource groups in the Azure Portal.
  • Select security-monitoring-rg.
  • Click Delete resource group.
  • Type security-monitoring-rg to confirm, then click Delete.
  • This permanently deletes the VM, its disk, the Log Analytics workspace, the DCR, the alert rule, and the action group.

Deletion is irreversible

Once you delete the resource group, all data in the Log Analytics workspace (including your security event logs and KQL query history) is permanently removed. Make sure you have captured any screenshots or notes you need before confirming.

Nice Work!

Nice Work!

You just built a real security monitoring system on Azure. From a single Windows Server VM, you stood up the same monitoring pipeline that security teams use to protect production cloud infrastructure.

You learned how to:

  • Deployed a Windows Server VM and configured Data Collection Rules to ingest security logs into a Log Analytics workspace.
  • Wrote KQL queries to hunt for failed login attempts and summarize suspicious security activity across time windows.
  • Created an automated alert rule with an Action Group that emails you when multiple failed logins are detected on your VM.
  • Secret Mission: Observed real-world attack traffic from internet bots and saw your monitoring system catch it live.

Ready to quiz yourself?