Azure Sentinel Lab

Azure Sentinel Lab

Title: Setting Up an Azure Sentinel Lab: Mapping Cyber Attacks with Honeypots

Project Overview: In today's digital realm, cybersecurity stands as a paramount concern. With the surge in cyber threats, it's essential to adopt proactive measures to safeguard against potential attacks. Azure Sentinel, Microsoft's cloud-native Security Information and Event Management (SIEM) service, emerges as a robust solution for effectively monitoring and responding to security threats. This project embarks on the journey of setting up an Azure Sentinel lab, focusing on creating a honeypot and visualizing live cyber attacks. This hands-on exploration offers invaluable insights into comprehending and mitigating potential security risks.

Azure Sentinel: A cloud-based SIEM solution by Microsoft, Azure Sentinel empowers organizations with comprehensive security threat monitoring and management capabilities, providing real-time insights into security alerts.

Honeypot: Serving as a decoy, a honeypot is a security mechanism designed to lure and trap potential attackers by mimicking authentic network components. In our context, we'll deploy a virtual machine (VM) as a honeypot.

Steps overview

1. Setting Up the Essential Resources:

• Begin by creating an Azure subscription (you can star a free trial at https://azure.microsoft.com/en-us/free/ )

• Log in to the Azure Dashboard to manage your resources.

• Sign up at Ip Geo location page and note down the API key to use later. (https://ipgeolocation.io/)

2. Creating a Resource Group & Virtual Machine (VM):

• A resource group serves as a container for organizing all the lab’s resources. It ensures that they share a unified lifecycle. Remember to delete the resource group after the lab to prevent ongoing charges.

• Create a Windows 10 VM within the resource group. This VM will act as your honeypot.

3. Customizing Network Security:

• Deactivate the firewalls and craft a custom Network Security Group (NSG) for the VM.

• The NSG should intentionally keep all ports open, drawing the attention of potential attackers worldwide.

4. Setting Up a Log Analytics Workspace:

• Create a Log Analytics Workspace to gather data from the honeypot.

• Configure the VM to send logs to this workspace.

5. Integrating with Azure Sentinel:

• Configure Azure Sentinel to communicate with the Log Analytics Workspace.

• This integration allows Sentinel to receive data from the honeypot.

6. Visualizing Attacks on a Map:

• Utilize the collected data to construct a dashboard within Sentinel.

• Plot global failed logon attempts and their corresponding IP geolocations on a map.

Why This Matters:

• By monitoring live attacks, you’ll gain insights into the tactics, techniques, and procedures used by potential adversaries.

• Visualizing attack origins on a map helps identify patterns and potential threat sources.

This project not only fosters educational exploration but also contributes significantly to fortifying organizational security defenses. Feel free to delve deeper and tailor the setup to suit specific requirements. Happy exploring! 🚀

Step 1: Setting Up the Essential Resources

-Lets start by navigating to the Microsoft Azure website: azure.microsoft.com. Look for the "Start for free" or "Sign up" option to create a new account. Following the on-screen prompts, we provide necessary information, including our email address, personal details, and payment information. Rest assured, we won't be charged unless we explicitly upgrade to a paid subscription. Once our account is created, we proceed to sign in to the Azure portal using our newly created credentials.

-As new users, we're eligible for a $200 credit to explore Azure services. Upon signing in to the Azure portal, we'll find a notification about the credit. We click on it to redeem our credit. Following the provided instructions, we claim our credit, which will then be applied to our Azure account. Considering the modest resource requirements of our project, the $200 credit should be more than sufficient to cover expenses.

-To gather IP geolocation data for our project, we opt for a reliable service like IPGeolocation.io. IPGeolocation.io offers accurate location data based on IP addresses, which will be crucial for mapping the origins of cyber attacks in our project. We need to sign up on here and get he API key.

Steps 2 & 3. Creating a Resource Group, Virtual Machine (VM) & Customizing Network Security: -

- Navigate to Azure Portal.

— Go to Virtual Machine > Create Virtual Machine.

— Choose a new Resource Group, set the region (e.g., West US3), and configure the VM details.

- We can use any name for the VM and the security group and also set a username and password to login to the VM. Please make sure to select a strong password.

- Click Next: Disk > keep it as is and

- Click Next: Networking >

- Select Advanced on NIC network security group

Under configure new security group click "Create new"

First, remove existing rules and add an inbound rule:

— Destination: Any

— Source: Any

— Source Port: All

— Priority: 100

It will start creating the VM, within couple of minutes the VM should be ready.

Step 4: Setting Up a Log Analytics Workspace

- Go to Log Analytics Workspace > Create.

- Then Click on Create Log Analytics Workspace

- Select the resource group "honeypotlab.group" or whatever you named your resource group

- Name this Log instance, for me its "HonepotLoG"

- Select "Region"

- Click "Review + Create" - It should start deployment.

To progress in our cybersecurity project, the next step involves configuring Microsoft Defender for Cloud, where we must provision and enroll in specific plans to collect and aggregate data for later use in Microsoft Sentinel. Additionally, we need to connect our Honeypot-VM to Microsoft Defender to enable data collection. With the VM created, we activate data connectors to establish the necessary connections between the VM and the security services. Notably, we selectively turn on plans for Foundational CSPM, Defender CSPM and Servers, excluding all others as we aren't utilizing them. This structured approach ensures effective integration of our Honeypot-VM with Microsoft Defender for Cloud and lays the groundwork for efficient monitoring and response to potential security threats.

Defender CSPM is also additional, we do not need it for this lab but it gives robust logging on network exposure detection, vulnerability scanning and many more, which would cost bit more but since I have $200 credit, I decided to use it , and I would recommend to use it

- Select Microsoft Defender for Cloud.

- Select Environment Settings at the bottom left corner

- Then select Azure subscription 1

- Click "On" Defender CSPM if you want

- Click "On" servers.

rest we don't need it so we can keep it off .

- Then click on "Settings & monitoring"

On this page I am keeping status "On" for below components, rest we can keep "Off" status

-Log Analytics Agent ( this is to collect all windows security and events)

-Vulnerability assessment for machines

-Agentless scanning for machines

- Click continue and click Save.

Now time to connect VM to Log analytics.

- Lets go to Log Analytics workspace

- Click on the Log name , for me "HonepotLoG"

- Then scroll down on left and click on "Virtual machines"

- On right we should see our VM, Click on it

- And Click "Connect"

It will take some time and after a while we should be able to see its status connected.

Step 5: Integrating with Azure Sentinel

- Search for "Microsoft Sentinel"

- Select "Microsoft Sentinel" and click on "Create"

- Select the "HonepotLog" and Click "Add"

Now its time to Remote Desktop (RDP) to the VM we created to setup honeypot.

- Let's go to "Virtual Machines" and select the VM

- and copy the "public IP address"

- Now open Remote Desktop Connection form our local PC

- Click Add and click OK

- Click Review + create

- Connect to the VM, once prompt insert username and password ( which we provided during the VM setup)

- Click yes to the Certificate and you should see the login window.

- Make sure to select No to all privacy settings and click "Accept".

Once you are logged in navigate to Event Viewer to Windows VM

- In Event Viewer, go to Windows logs and focus on the “Security” section.

- Look for event 4625, which indicates audit failure, such as a bad username or password attempt.

Next step is to turn off firewall and make it completely vulnerable to the internet.

- Search "wf.msc" and "click" on it

Windows defender firewall will open, look for "Windows Defender Firewall Properties"

Change Domain, Private & Public profile Firewall state to Off and click "Apply & Ok"

Now lets try to ping the machine form a separate machine to see if it is discoverable.

Now the fun part begins:

With our VM now exposed to the internet, we can initiate the setup of our PowerShell script, which serves as the central component of this project. This script plays a pivotal role by parsing Event Viewer, specifically targeting EventID 4625, which signifies failed logon attempts. Subsequently, it extracts the IP addresses from these failed logon attempts and sends them to IPgeolocation.io via an API. This step is crucial as the IP addresses in Event Viewer lack geographical information. Leveraging IPgeolocation.io allows us to retrieve the geographical data effortlessly. The PowerShell script then receives this geographical data and saves it as a string in a logfile named failed_rdp.log. This logfile will be instrumental in mapping live attacks in Microsoft Sentinel later on in the project, facilitating comprehensive threat monitoring and response capabilities.

Lets open Powershell ISE on VM.

Copy the script form https://github.com/rezwansidd/Sentinal-lab/blob/main/Custom_Security_Log_Exporter.ps1

This is courtesy to @Josh Madakor who created this fun lab and this script.

We need to change the API_KEY. This is a unique API key which we can get form ipgeolocation.io page once we signup and go to the dashboard page.

Change the API key and run the script. We should start seeing attack logs on our PowerShell window.

Looks like bots form Russia and Argentina already started brute force attacking the VM to get access. Just withing 10 minutes we can see how many attacks are happening.

Steps 6: Visualizing Attacks on a Map

First we need to extract logs from the custom log file we created

Search for the path file name "C:\ProgramData" in your VM (it maybe hidden so make sure to tick hidden file)

Next copy failed_rdp.txt file to the local machine. You can copy the whole file or copy the content of the file and paste it on a notepad on your local machine and save it.

After copying this file to the local machine we need to upload this file into Sentinel in our next step.

Custom Log Creation:

Navigate to your Log Analytics Workspace on our azure portal

and click on the log file "HonePotLog" and click "Tables"

Click on "Create" and select MMA-based log.

Upload the sample log file from the VM. Navigate through the setup wizard. Use the screenshots below for specifics inputs.

Click Next and Next again

On collection paths select "Windows" and set the path "C:\ProgramData\failed_rdp.log"

Click next, give it a name and click "Create".

It will take a long time to process all this logs. We will come back after an hour or two to check the logs got process or not.

Lets navigate to Lgo Analytics Workspace then Logs

"Failed_RDP_CL" Basically we are calling the log file that we name it

I kept it running overnight and next morning it was showing results that means our log analytics works and its pulling the logs form our system and we can already see there are plenty of logs to work with.

Visualization in Microsoft Sentinel:

1. Go to Microsoft Sentinel, select your HonePotLog, and add a workbook. If there is any existing workbook please delete it.

Then click on Add and Add query

Now on the query window add below KQL query to pull up the log and visualize the map.

on the right side we can run below Kusto Query Language (KQL) KQL is a powerful query language designed for working with large datasets, particularly those in Azure Monitor, Azure Log Analytics, and Microsoft Sentinel.

" FAILED_RDP_CL

|extend username = extract(@"username:([^,]+)", 1, RawData),

timestamp = extract(@"timestamp:([^,]+)", 1, RawData),

latitude = extract(@"latitude:([^,]+)", 1, RawData),

longitude = extract(@"longitude:([^,]+)", 1, RawData),

sourcehost = extract(@"sourcehost:([^,]+)", 1, RawData),

state = extract(@"state:([^,]+)", 1, RawData),

label = extract(@"label:([^,]+)", 1, RawData),

destination = extract(@"destinationhost:([^,]+)", 1, RawData),

country = extract(@"country:([^,]+)", 1, RawData)

|where destination != "samplehost"

|where sourcehost != ""

|summarize event_count=count() by timestamp, label, country, state, sourcehost, username, destination, longitude, latitude"

Query Breakdown

1. Failed_RDP_CL

- The query operates on the custom log `Failed_RDP_CL`, where we've aggregated data related to failed Remote Desktop Protocol (RDP) attempts.

2. RawData Conversion

- The `extend` statement ensures that `RawData` is treated as a string, facilitating subsequent processing.

4. Geospatial Visualization:

— The `Latitude` and `Longitude` fields enable geospatial visualization, plotting the geographical locations of attacks. Rest are self explanatory.

Summarize: Basically logs will be summarized by event count then the ipgeolocation. If there is no geolocation data it will not simply display it "where sourcehost != "

Make sure change the Visualization to "Map" and Size select "Full" now run the query. We should be able to see below map with the map settings

On right at Map Settings make sure Latitude and Longitude select properly, you can change the color and on the Metric Settings select Metric label as "Label" and value as "event_count"

Now it shows the country name and the IP address on the map.

So after 24 hours of log gathering we see that there were more then 8000 attempts to brute force to the VM form Ethiopia alone. More than thousand form Netherlands and some form Russia, Argentina and Germany.

In conclusion, delving into the logs reveals a rather eye-opening revelation: "administrator" as a username is the top choice for attackers attempting brute force attacks. This finding underscores the critical need for robust security measures. It's paramount to fortify our defenses by implementing strong, unique passwords, steering clear of predictable usernames like "Administrator," and embracing Multi-Factor Authentication (MFA) wherever feasible. These proactive steps can significantly bolster our resilience against unauthorized access attempts and safeguard our digital assets from potential threats.

****Please remember to delete all VMs, resource groups, and log analytics after completing and exploring this lab to avoid being overcharged on your Azure account.****