Skip to main content

Project: Honeypot and Monitoring with Azure Sentinel SIEM

·1561 words·8 mins· loading · loading ·
Aditya Hebballe
Author
Aditya Hebballe
OSCP Certified Penetration Tester
Table of Contents
Project - This article is part of a series.
Part 1: This Article

Introduction
#

Honeypots are deceptive tools used in cybersecurity to attract and trap malicious actors. By simulating vulnerabilities, they divert attackers from real assets while gathering valuable intelligence on their tactics and methods. This strategy helps organizations enhance their security posture, understand emerging threats, and develop effective defensive measures against cybercrime. In this particular project we can see the bad actors trying to access our Windows VM through RDP.

Setting Up the VM
#

I chose to use Azure for this project due to my familiarity with the platform and the added benefit of a $200 credit. While this project can also be executed on AWS, the steps would differ significantly. In AWS Amazon GuardDuty can be used for the SIEM.

Create an Azure account and head to https://portal.azure.com/. You will get 200$ credits for free and it will be more than enough to complete this project for free.

SIEM.png
Search for virtual machines and click on that:

SIEM-1.png
You should see a web page similar to this

SIEM-2.png
Now create a virtual machine

Now I will select the following settings:

SIEM-3.png
Create a new Resource group. A resource group in Azure is a container that holds related Azure resources for a project. This means we can easily delete the resources associated with this project later on. You can also select Higher Tiers for the Size but note that it will burn through your free credits faster. The Standard_B2S tier should be sufficient for this project.

When creating the Administrator account take note of the Username & Password you input as we will use it later for logging in with RDP.

SIEM-4.png
Click next
SIEM-5.png
Leave the settings at Disks at default.

Set the NIC network security group to advanced and click on Create new.

SIEM-6.png

Delete the default inbound rule and add the following:

SIEM-7.png
We set the priority lower to signify that this rule has more priority
This inbound rule will let all inbound traffic through. Note that normally this is not advised but as this is a honeypot we need it to be open to the public.

Click on the review+ create button and then create the VM. It might take a while to deploy, you can proceed with the next steps meanwhile.

SIEM-8.png
We can see that we have it deployed:

Log Analytics workspaces
#

Next, search for Log Analytics workspaces in the Azure search: This is so that you can effectively track and analyze where attackers come from. Log Analytics Workspaces in Azure provides a centralized platform for collecting and analyzing log data from various sources, which is essential for security monitoring and threat detection. In this case from our VM’s logs.

SIEM-9.png
Click on Create Log Analytics workspaces

Select the previously created Resource group and a Region of your choosing. For the name I will be going with “law-honeypot” where law is Log Analytics workspaces.

SIEM-10.png
Review and create the workspace.

Defender For Cloud
#

Search for “Defender for Cloud” in Azure and go to it.

Go to environment settings and click on the 3 dots and edit settings as shown:

SIEM-11.png

Enable Foundational CSPM and Servers option

SIEM-12.png

Now head to Fata collection in the same page and enable All Events:

SIEM-13.png

Connect VM to Log Analytics Workspaces
#

Now head back to Log Analytics Workspaces

Virtual Machines in Log Analytics Workspaces was deprecated because Microsoft introduced Azure Monitor for VMs as a more comprehensive and scalable solution. For this project we will use the Virtual Machines in Log Analytics Workspaces as it is sufficient here.

Go to Virtual Machines in Log Analytics Workspaces:

SIEM-14.png

Virtual Machines in Log Analytics Workspaces was deprecated in favor of Azure Monitor for VMs, which offers a more comprehensive and scalable solution. However, for this project, we will continue using Virtual Machines in Log Analytics Workspaces as it meets our current needs and is sufficient for the scope of this project.

SIEM-15.png
Select our VM and connect it.

Azure Sentinel
#

Search for Microsoft Sentinel and go to the page for it.

SIEM-16.png

SIEM-17.png
Add our created Log Analytics Workspace to Sentinel

Now our setup should look something like this:

SIEM-19.png
The attackers will see our exposed VM and try to connect to it. This will be logged in the Log Analytics Workspace and we can access this info from Workspaces in Sentinel as you will see later.

Disabling Firewall in VM
#

Head to the Virtual Machine page in Azure, the VM would have deployed by this time. Take note of the public IP of our VM.

SIEM-18.png
We can see the public IP.

Now we need to connect to it using RDP, as I am using Linux I will use Remmina to RDP into the machine. If you are on Windows you can search for Remote Desktop Connection in the start menu.

SIEM-20.png
We can use the Public IP we noted and the credentials set up during the first section of this blog
Now we are logged in:
SIEM-21.png
We can disable all and continue as we do not need those.

Open the Start Menu and open Event Viewer on the VM, Event Viewer is a built-in tool in Windows that allows you to view detailed logs of system, application, and security events.

SIEM-22.png
Go to Windows Logs->Security

SIEM-23.png
When someone fails to login we get ‘Audit Failure’
We can see the username they used and also the IP address from which they logged in. This was me in a previous attempt to login.

Later we will check the location of each IP using a script, this script will use ipgeolocation

We will now try to ping the VM from our machine. Use the Public IP you noted.

ping 104.211.67.67

We can see that it does not work due to firewall:

SIEM-24.png
No reply

We will now disable the Firewall. Search for “wf.msc”:

SIEM-25.png

Disable the firewall, set it off for Domain, Private and Public profile as well:

SIEM-26.png

Now we can see that the ICMP inbound connections are accepted:

SIEM-27.png

We could have also made the firewall accept only certain connection type like ICMP,etc but as this is a Honeypot we can just disable the firewall completely

Logging the Logins
#

Copy the contents of this powershell script: https://github.com/AdityaHebballe/Pentest-Scripts/blob/main/Log_exporter.ps1

Open Powershell ISE on the Windows VM and paste the contents.

SIEM-28.png
Get the API key from https://ipgeolocation.io/ after creating an account. Paste it in the “$API_KEY” field of the script

SIEM-29.png
Run the script
These purple outputs are all failed logins being detected live.

The logs are stored at C:\ProgramData\failed_rdp.log

SIEM-30.png
Copy these and go to Log Analytics Workspace on Azure.

Now we will create Custom Logs: Open Tables And create new Custom Log (MMA-Based):

SIEM-31.png

Now make a .log file with the contents from failed_rdp.log on your local machine and upload:

SIEM-32.png
Click next

SIEM-33.png
Set the Record delimiter to ‘New Line’

Set the path for the failed_rdp.log located at C:\ProgramData. Check if the file is created first, the location and filename is defined in the powershell script from eariler.

SIEM-34.png

SIEM-35.png
Next name the custom log

Review and create it:

SIEM-36.png

Now in logs section in Azure. To manually find the failed rdp logins use Event ID=4625 as it indicates a failed login attempt:

SIEM-37.png
We can see the list of failed login attempts

Now we can try with our custom log, run the query with name of the custom log:

SIEM-38.png
We can see the failed logins with various fields.

Now use this query, it extracts and summarises the raw data:

FAILED_RDP_WITH_LOC_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

SIEM-39.png
We can see it is more organised now

Final Steps
#

Go to Sentinel and then Workbooks:

SIEM-40.png
Click on Add Workbook

Delete the pre-existing chart and add a new query:

SIEM-41.png

Use the same query from eariler:

FAILED_RDP_WITH_LOC_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

Now we can change visualisation to map and see the results:

SIEM-42.png

And also set the Metric Label to country after clicking on Map Settings:

Now you can save this workbook and check on it after a few days to collect data from it:

Note that the free API key from ipgeolocation will only work on 1000 IP addresses a day, you can purchase a subscription for more.

Conclusion
#

The Azure SIEM and Honeypot project successfully demonstrated the practical application of cloud-based security monitoring and threat detection. By deploying a honeypot within an Azure environment, we were able to attract and monitor potential malicious activity, simulating real-world attack scenarios. Integrating the honeypot with Azure Sentinel allowed for real-time data analysis and the creation of customized detection rules, such as those tracking failed RDP attempts, to identify suspicious behavior and potential threats. This project can be further expanded upon using the new Azure Monitor for VMs as well. Thank you for reading the blog and see you on the next one!

Project - This article is part of a series.
Part 1: This Article

Related

How I Passed the OSCP in Just 6 Months
·2549 words·12 mins· loading · loading
I am a student pursuing a Bachelor’s degree in Computer Science and Engineering and I passed the OSCP just six months into my cybersecurity journey, despite having limited prior experience.
Deep Dive into Network Monitoring
·1489 words·7 mins· loading · loading
Network monitoring is essential for ensuring the reliability, security, and performance of computer networks. It involves continuously observing network traffic to detect and respond to anomalies, optimize resource allocation, and maintain uptime.
Which Linux Distro is the best for you?
·1113 words·6 mins· loading · loading
This is a quick little blog about my Linux journey and how you could start yours. I started my Linux journey when I realized how much easier it was to install packages, but the real game-changer came from the significant performance boost.