In this lab, I designed and implemented a virtual environment leveraging Microsoft Azure to simulate a basic Security Information and Event Management (SIEM) & Security Orchestration, Automation, and Response (SOAR) system, using Microsoft Sentinel. Key components of the lab include:
- Creation of a Resource Group, Virtual Network , and Subnet
- Configuration of a Virtual Machine (Honey Pot) with public internet access
- Deployment of Log Analytics Workspace as the central log repository
- Installation of the Azure Monitoring Agent on the VM to collect logs
- Connection of Microsoft Sentinel to the Log Analytics Workspace
- Integration of a watchlist with geographic data
- Utilization of Kusto Query Language (KQL) to identify and analyze failed logons
- Mapping of attacker IPs to visualize the threat landscape
- Setup and configuration of alerts triggered by potential cyber threats
- Automate threat response in Microsoft Sentinel with created playbooks
Azure
For this lab, we will set up a basic home SOC in Azure from scratch. Using a free Azure subscription, we will walk through creating a virtual machine (VM), opening it to the internet as a honeypot, and forwarding logs to a central repository. We will then integrate Microsoft Sentinel to map, visualize and analyze real-world attack data and use playbooks and automation rules to automate incident response to the security threats. Let’s take a look at what we have in store for us:
- Part 1. Setup Azure Subscription
- Part 2. Create the Honey Pot (Azure Virtual Machine)
- Part 3. Logging into the VM and Inspecting logs
- Part 4. Log Forwarding and KQL
- Part 5. Log Enrichment and Finding Location Data
- Part 6. Attack Map Creation
- Part 7: Alert Creation
- Part 8: Incidents
- Part 9: Creation of Automation Rules & Playbooks
- Part 10: Execute Playbook
Walkthrough
Part 1. Setup Azure Subscription
First things first, we need an Azure Subscription to do anything. If you don’t already have one, we can create a free subscrition. To create a Free Azure Subscription, go here.
After your subscription is created, you can log in at: https://portal.azure.com. You’d see homepage just like the one below after you successfully log in.
The first step would be to create a Resource Group.
A resource group is a container that you use to manage related resources for an Azure solution; this is what will hold all the other resources we create. I named my resource group RG-SOC-Lab and put it in the US East region.
I also created a virtual network (what connects our rescoures and allows them to communicate with each other) called Vnet0, search up virtual network and create yours. When creating the virtual network, put in the same region as your resource group and also select your resource group.
Part 2. Create the Honey Pot (Azure Virtual Machine)
Next we will create our virtual machine aka our honey pot. Go to the search bar and search for virtual machines. If we haven’t covered it already, a honeypot in cybersecurity is a decoy computer system designed to attract and trap attackers by mimicking a legitimate target. By luring cybercriminals to this isolated system, security professionals can observe their methods, tactics, and tools to gather threat intelligence and improve defenses against real-world attacks.
Create a new Windows 10 virtual machine (choose an appropriate size and be mindful of shutting this off when you are done). Make sure to map the virtual machine to your resource group for this project. I created a virtual machine with the name DC-CORP. Remember the username and password.
Next, go back to your resource group and see what you got in there.
You will see your virtual machine and other resources that were created alongside it, like its public ip address, disk and network security group.
Next, we go to its network security group (NSG), which acts as a basic cloud firewall for our virtual machine. It will filter network traffic in and out of Azure resources, including subnets within an Azure virtual network and network interfaces. NSGs contain security rules that allow or deny traffic based on criteria such as source/destination IP addresses, ports, and protocols. For this lab, to make our machine aka honeypot alluring to attackers, we will allow remote access. We will create a rule that allows all inbound traffic.
Let’s go back to the Virtual Machine page and see what we have.
Note down the Computer Name and Public IP address. Log into your virtual machine using Remote Desktop Connection, modify the Firewall settings, and turn off the Windows firewall, the virtual machine’s firewall can aslo block traffic and that is not what we want (turn the Firewall state off on the Domain Profile, Private Profile, and Public Profiles).
Let’s check if we can reach and communicate with the virtual machine using ping. Ping the virtual machine with your local computer or any other device.
Part 3. Logging into the VM and inspecting logs
Next, we will fail our remote logins as employee (or some other username) a few times. After successfully logging in to your virtual machine, open Event Viewer, and inspect the security logs.
See the failed logins as “employee”, Event ID 4625.
Next, we are going to create a central log repository called a LAW.
Part 4. Log Forwarding and KQL
Next, we will create a Log Analytics Workspace (LAW) within Azure called LAW-SOC-01. A Log Analytics workspace is a data store into which you can collect any type of log data from all of your Azure and non-Azure resources and applications. It lets you manage all of your log data in one workspace to meet the operations, analysis, and auditing needs of your organization.
After the Log Analytics Workspace is deployed, create a Sentinel Instance and connect it to Log Analytics.
Microsoft Sentinel is a cloud-native SIEM solution that delivers scalable, cost-efficient security across multicloud and multiplatform environments. Microsoft Sentinel provides attack detection, threat visibility, proactive hunting, and threat response to help you stop threats before they cause harm.
It empowers analysts to anticipate and stop attacks across clouds and platforms faster and with greater precision. Sentinel uses the data retrieved from resources like the Log Analytics Workspace for security information and event management (SIEM) capabilities.
Next, we will configure and install the Windows Security Events via AMA connector. To collect Windows events from a Windows virtual machine we will need this data connector. You can retrieve all security events from the Windows machines connected to your Microsoft Sentinel workspace using this Windows agent. This connection enables us to view dashboards, create custom alerts, and improve investigation. This gives you more insight into your organization’s network and improves your security operation capabilities.
We will select and create a data collection rule within Sentinel, and watch for extension creation. The data collection rule was created successfully and shows up under the VM. A data collection rule (DCR) is a set of instructions within Azure Monitor that specifies what data to collect, how to transform it, and where to send it; by customizing these rules, users can filter unwanted data, add calculated columns, and direct data to different Log Analytics Workspaces.
Next step, where the real fun begins. We will query for logs within the LAW
We can now query the Log analytics workspace as well as the SIEM, Sentinel directly, which we will do soon. Note: Querying logs in here is a really important skill that you MUST have if you want to work in security operations. Microsoft and Sentinel uses KQL.
KQL, or Kusto Query Language, is a read-only query language developed by Microsoft for exploring and analyzing large datasets, especially those found in Azure services like Azure Data Explorer, Log Analytics, and Azure Sentinel. It features a simple, text-based, data-flow model that makes it easy to read, write, and automate queries
Let’s see some of our VM logs:
SecurityEvent | where EventId == 4625
We see all Windows Security Events with the event ID 4625 (failed logon)
Part 5. Log Enrichment and Finding Location Data
We will use another query to display more details about our events
SecurityEvent | where EventId == 4625
| project Account, Activity, Timegenerated, IpAddress, IpPort
Where project is a KQL operator used for selecting specific columns: You can specify the exact columns you want to include in the output.
So, by now you should have several failed log in attempts from malicious users from wherever. In regards to the query we just executed; for each event, we should see an account name that was used to attempt to log in into our honey pot machine, the activity, the time the activity took place, the ip address of the malicious user and the source port the malicious traffic is coming from. If you notice, there is no location data, only IP address, which we can use to derive the location data. Let’s try one of them, we will use the first one 41.38.219.239. We will use domaintools to gather intel about the ipaddress.
From the result, we see the Ip Address comes from Egypt. It is important to ascertain the locations of such traffic in security & incident response operations. We are going to import a csv spreadsheet (as a Sentinel Watchlist) which contains geographic information for each block of IP addresses.
A watchlist in Azure allows us to correlate data from a data source we provide with the events in our Microsoft Sentinel environment. It aids analysts in investigating threats and responding to incidents quickly by importing IP addresses, file hashes, and other data from CSV files.
Within Sentinel, create the watchlist:
- Name/Alias: geoip
- Source type: Local File
- Number of lines before row: 0
- Search Key: network
Allow the watchlist to fully import, there should be a total of roughly 54,000 rows.
In real life, this location data would come from a live source or it would be updated automatically on the back end by your service provider.
If we want to call the Geoip watchlist, we use _GetWatchlist(“geoip”); so we can see where the attacks are coming from.
We can pullup the attacker’s IpAddress, city, country and coordinates with the query below.
let GeoIPDB_FULL = _GetWatchlist("geoip");
let WindowsEvents = SecurityEvent
| where IpAddress == <attacker IP address>
| where EventID == 4625
| order by TimeGenerated desc
| evaluate ipv4_lookup(GeoIPDB_FULL, IpAddress, network);
WindowsEvents
Part 6. Attack Map Creation
Next up, we will create an attack map.
An Attack Map is a visual representation of cyber threats, showing attacks as they occur. These maps use different graphics, like lines or dots, etc. Cyber Attack Maps gather information from various sources, including sensors, honeypots and threat intelligence feeds.
We will build the attack map by creating a Workbook. In Microsoft Sentinel, users can visualize and monitor their data using workbooks. These workbooks are a way to create and show customizable and interactive reports that can display graphs, charts, and tables. We will use the workbook to display and visualize our security events in the form of an attack map.
Within Sentinel, create a new Workbook
Delete the prepopulated elements and add a Query element
Go to the advanced editor tab, paste the JSON text and click done editing
You can get access to the json text from map.json
Observe the map
Now we can see where all the attacks are coming from, from a global perspective. I can tell that most attacks on my honeypot originate from Mexico and Trinidad and Tobago.
You can change the query used or settings of the map as needed.
Part 7: Alert Creation
Now we are done with the first part of the lab which is create a honeypot to attract attackers and analyze real-world attack data. For the second part of the lab; we will setup and configure Sentinel to generate alerts and deploy playbooks to automatically respond to them.
Let’s create SIEM Alerts
A SIEM solution gives organizations better insight into vulnerabilities, helps them to quickly contain and eliminate cybersecurity threats; the SIEM solution does this is with the help of security alerts. SIEM alerts are notifications generated by the SIEM system based on predefined rules and correlation algorithms. Security analysts create and tune alerts for identifying security incidents.
We will define two detection rules that will instruct Sentinel to trigger an alert when an event matches the defined rule. We will create rules for events we would like to detect as suspicious/potential threats:
- Multiple login attempts aka brute force attempts from any IP Address
- When a known/legitimate user account fails their login over
Let’s begin. We first create another user account we will use for this part of the lab; we will fail to login into this account mutiple times. I have my first user account as LabAdmin and I will create LabUser as the account for this part
net user LabUser /add
Let’s setup our detection rules to receive alerts. In the Azure portal, find and select Microsoft Sentinel from the navigation menu, then select Analytics under the Configuration section.
Start a New Rule: Click on Create > Scheduled query rule.
General: Here we will enter a descriptive name for the alert, provide a detailed description of the alert’s purpose and the severity of the alert
Set Rule Logic:
- Rule Query: Write or select a Kusto Query Language (KQL) query that identifies the suspicious activity for which you want to be alerted
- Threshold: Configure how often the query runs, what it should return, and the threshold for triggering an alert.
- Entities: Define any entities related to the alert, such as users, hosts, or IP addresses.
We start with the rule that will detect when multiple login attempts aka brute force attempts from any IP Address
Alert Name is set as Multiple Login Attempts from Malicious IP Address or Brute Force Attempt and the severity in the image is medium, however I went back to set it as high instead.
The rule query would be
SecurityEvent
|where EventID == 4625
|summarize count() by IpAddress
|where count_ >= 20
|project
AttackerIp = IpAddress,
Count = count_;
This will detect any event where there were over 20 login attempts from an IP Address.
You can skip the other sections or leave them as default. When done, review and create.
Next we will create the rule for when a known/legitimate user account fails their login over 3 times. You can set the Alert Name as Multiple Login Attempts From Valid User Accounts and severity as low. Next, the rule query would be
SecurityEvent
| where EventID == "4625"
| where Account == ".\\LabAdmin" or Account == ".\\LabUser"
| summarize count() by Account, IpAddress
| where count_ > 3
This grabs any failed login event where the account is a legitimate account we created and it’s over 3 attempts
Alright, let’s see the two rules that were created.
Looks good. However, I later went back and made changes to a couple of things, like the names of the rules. To do this is not hard, just go to the rules and edit them
Multiple Login Attempts From Valid User Accounts to Multiple Valid User Login Attempts
Multiple Login Attemps From Malicious IP Address to Brute Force Attempts
Let’s create alerts.
For our first rule, we will fail to login into the account we just created. For me, I will create a few login attempts into my LabUser account
Okay we have failed login attempt events.
For our second rule, we don’t need to do anything, we have the particular events come in soon, as malicious attackers attempt to brute force and gain access into our honey pot. Okay let’s check Sentinel and head to Incidents to see if we got alerts.
Nice, we got alerts.
Part 8: Incidents
We will select each one to get more information about the alert.
Let’s select the first alert, Brute Force Attempt and see what we can gather.
We can see some of the IP Addresses that attempted to brute force into our honey pot.
Next
We can see the event related to the alert. The account that is involved in the event is LabUser, it also shows the IP Address involved (I used my personal computer for this lab, which is why I have the IP Address blacked out) and the number of times they attempted to login.
Now that we have our alerts. Wouldn’t it be cool if there was a way to automatically respond to these alerts, e.g. block an IP Address, send an email to the security team to address them as soon as possible or even run threat intelligence scans, etc. This is what we will do next.
Part 9: Creation of Automation Rule & Playbooks
In Azure, Automation Rules primarily refer to the feature in Microsoft Sentinel for centrally managing automated responses to security incidents, which include triggers, conditions, and actions. Security analysts/Incident Responders use this feature to launch & implement the team’s Security Orchestration, Automation and Response (SOAR) operations; these automation rules increase the SOC’s effectiveness and saves time and resources. These rules are based on a trigger (like an incident or alert being created), conditions (specific criteria the incident must meet), and actions (what the rule should do, which will be our playbooks).
Microsoft Sentinel Playbooks are automated workflows that help you respond to threats quickly and consistently. Security Professionals implement playbooks in Microsoft Sentinel to automate threat response, cut manual effort, and let the team focus on deeper investigations.
We can either run playbooks automatically in response to specific alerts and incidents that trigger a configured automation rule, or run them manually for a particular entity or alert.
For example, if an account and machine are compromised, a playbook can automatically isolate the machine from the network and block the account before the SOC team gets notified of the incident.
Let’s first create our playbooks. We will have two playbooks, one for each of our incidents.
Notification/Communication playbook: This will be triggered when our incident (Multiple Valid User Login Attempts) is created. It will send a notification to a configured destination. This can entail posting a message in a Microsoft Teams channel, Slack channel, or sending an Outlook email notification. For this lab, we will send an email.
Enrichment Playbook: This will be triggered when our incident (Brute Force Attempts) is created. It will gather additional information about the incident to provide analysts with more context and help us make smarter decisions.
Let’s begin, we will first create our playbooks then our automation rules.
Head back to Microsoft Sentinel, go to Automation and then head to Playbook Templates.
We will use playbook templates to create our playbooks. A Playbook Template is a prebuilt, tested, and ready-to-use automation workflow for Microsoft Sentinel that can be customized to meet our needs. They can also serve as a reference for best practices when developing playbooks from scratch, or as inspiration for new automation scenarios. Many playbook templates are developed by the Microsoft Sentinel community, independent software vendors (ISVs), and Microsoft’s own experts, based on popular automation scenarios used by security operations centers around the world.
Sending an Outlook Email
Search for and select Send basic email, click on Create playbook. This will be used to create our notification playbook. This will take us to the playbook creation wizard based on the selected template. The wizard has four tabs:
Basics: Locate your new playbook and give it a name; you can use the default.
Parameters: Enter customer-specific values that the playbook uses. Our playbook sends an email, we will define the recipient address.
Connections: Azure Logic Apps communicates with other systems and services using various types of connectors. Use the Microsoft Sentinel connector to create playbooks that interact with Microsoft Sentinel.
Expand each action to see the existing connections you created for previous playbooks. You can choose to use existing connections, or create a new one.
Review and Create: View a summary of the process and await validation of your input before creating the playbook.
After following the steps in the playbook creation wizard to the end, you’re taken to the new playbook’s workflow design in the Logic Apps designer.
Microsoft Sentinel playbooks are based on workflows built in Azure Logic Apps, a cloud service that helps you schedule, automate, and orchestrate tasks and workflows across systems throughout the enterprise. Microsoft Sentinel playbooks can take advantage of all the power and capabilities of the built-in templates in Azure Logic Apps.
Azure Logic Apps must connect separately and authenticate independently to each resource, of each type, that it interacts with, including to Microsoft Sentinel itself. Logic Apps uses specialized connectors for this purpose, with each resource type having its own connector. Authenticate according to the relevant instructions
Next, go to the Send an Email box/section, and fill in the parameters and provide the necessary information for the email
Provide the destination email, subject of the email and the body. Save the playbook. The playbook appears in the Active Playbooks tab.
Now, for our second playbook.
Sentinel IP Enrichment
IP address data is one of the most effective weapons that professionals and organizations have in their arsenal to identify cyber threats and shut down malicious activity. One quick and easy way to assess the severity of an incident is to see if any IP addresses in it are known to be sources of malicious activity. Having a way to do this automatically can save you a lot of time and effort.
Microsoft Sentinel provides a number of ways to perform IP enrichment and investigation. We’re going to look at using the AbuseIPDB service to automatically enrich incidents with details about the IP addresses in the incident. AbuseIPDB is a project dedicated to helping track malicious activity. It provides a central blacklist for security teams, system administrators, and other interested parties to report and find IP addresses that have been associated with malicious activity online.
Search for and select AbuseIPDB Enrich Incident By IP Info, click on Create playbook. This will be used to create our notification playbook. This will take us to the playbook creation wizard based on the selected template. So, this is similar to how we created the last playbook. Select the correct subscription, region, resource region and choose the playbook name; I had mine as AbuseIPDB-EnrichIncidentByIP. For the parameters and connections sections, choose default.
There will be a few configurations done to have our playbook ready to go. You can make use of this walkthrough to configure your playbook to use the AbuseIPDB service to automatically enrich incidents by checking and recording the reputation of IP addresses.
Part 10: Execute Playbook
Now it’s time for the fun and final part of this lab.
We have our playbooks ready.
Now to run our playbooks, we can set an automated response or run it manually. We can do both, for us to have it run automatically, we would have to set it as an automation rule. Let’s do that.
Remeber, an automation rule is used to automate responses to security incidents within Azure Sentinel. They work by defining a trigger, conditions, and actions to automate.
Navigate back to Analytics in Sentinel. We see the alert rules we created; we will select each of them one at a time and make modifications. Remeber, during their creations, we left some sections empty or as default; now we go back and make entries in the Automated Response section.
- Select Add New
- Enter name of Automation Rule
- For Trigger, select When Incident is Created – This is the event that starts the rule, i.e the incient being created
- For Condition, we can leave it as default – This is criteria that must be met for the rule to run
- For Actions, select the playbook for the rule- The tasks that are performed when triggered or conditions are met
- The first automation rule will run the Send Email playbook when a Multiple Valid User Login Attempts incident is created. It will send a notification to a configured destination which is my outlook email.
- This second automation rule will run the AbuseIPDB-EnrichincidentByIP playbook when a Brute Force Attempt Incident is created. It will gather additional information about the IP Address associated with the incident.
Let’s create incidents to run our playbooks
I have racked up a few alerts for both cases. Let’s begin
Remember, we have set an automated resonse for these incidents.
So for the failed login attempts from one of our legitmate users, the Send Email should run and send us an email. We should recieve an email notifying us of this incident. Let’s check it out.
We will see we got an email about the incident; highlighting the description of the incident and its entities. The entities include the name of the account and the IP Adress of the machine used to access the account (in this case my IP Address). It also includes a link to the actual incident in Sentinel which is cool. The analyst can go a step further to lock the account and/or reach out the user and confirm if it’s actually them attempting to log in etc.
Next up, our Brute Force Incidents. For this we will run the AbuseIPDB-EnrichincidentByIP playbook twice, automatically and manually.
Select the incident.
We can already see the malicious addresses associated with the attempted attacks. At the bottom, click on Actions and select Run playbook (this will bring up all the playbooks you have created).
Then we will se a list of our playbooks to choose from. We wil select Abuse…Let’s see what we have
We see it ran successfully, it checked the IP addresses in your incident against a threat intelligence source aka AbuseIPDB and recorded each result. The more times an IP Address has been reported, the higher its abuseConfidenceScore. We can see the IP Addresses, their city and country of origin, ISP and number of times they have been reported. An analyst can quickly review IP information and assess threats faster.
Microsoft Sentinel also uses its own threat intelligence to obtain the geolocation of an IP address, which is integrated into its analysis and investigation tools. It enriches IP addresses with geolocation data from Microsoft’s threat intelligence service and third-party vendors to provide context during investigations.
Well, that’s it. We have come to the end of the lab, I hope you enjoyed it!
Summary
In this lab, we deployed a honey pot machine in Azure to lure in malicious actors and configured Sentinel to display global attack data on a world map according to the physical location and magnitude of attacks on the honey pot. We also setup Sentinel to generate alerts of detected potential threats, such as unusual login attempts, and deployed automation playbooks to respond to the security incidents by gathering IP threat intelligence of malicious actors & informing appropriate party of malicious activity.