Azure Sentinel — Honeypot Threat Analysis

In this project, we will be utilizing the Azure Sentinel SIEM to analyze the security events, particularly the failed RDP login attempts, that occur on a vulnerable Windows virtual machine which is exposed over the internet. These security events will be pulled from the Windows Event Manager of the vulnerable VM and sent over to Azure Sentinel via the Azure Log Analytics Workplace. The public IP of the attacker(s) will be pulled from the logs and sent to a third-party API (ipgeolocation.io) to obtain the respective latitude and longitude details of the attacker. This data will be plotted on a world map within an Azure Sentinel workbook to obtain a birds-eye view of the origin and frequency of these attacks.

[Note: This project can be comfortably re-created using the credits that are bundled with the Azure free-trial subscription].

Process Flow Diagram:

Note: The above diagram was created using lucid.app

Step 1: Log into the Azure portal and create a Windows VM

Configure the basic settings of the virtual machine as per the screenshot below. Create a new resource group and set it’s name as well as the VM’s name as per your preference.

Keep the default option for the disk size and set up the username and password details for the VM’s admin account.

Note: If you receive a "storage not available" error, try changing the 
region of your VM. This often occurs due to availability issues that arise 
from very high demand in that particular region.

Additionally, select all available options in the “select inbound ports” drop down menu. These include: HTTP (80), HTTPS (443), SSH (22) and RDP (3389).

Note: We have chosen to allow all these ports as our intention is to make
this VM as vulnerable as possible. In an ideal scenario, we must restrict
this selection to only include the required ports such as RDP(3389).

Moving on, click on “Next : Disks >”, leave the options as is, and then click on “Next : Networking >”. A new virtual network will be created for your VM by default.

Leave all settings in their default state, excluding the “NIC network security group”, which is to be set to “Advanced”. Upon doing so, a new “Configure network security group” drop down menu will appear with the pre-configured name of your network security group.

Click the “create new” link that is present beneath the network security group name and delete the existing inbound rule by clicking the trash bin icon in the far right, as highlighted in the below screenshot.

Then, click on “+ Add an inbound rule”, configure the rule as per the below screenshot and then click on “Add” and then “OK”

After doing so, click on “Review + create” -> “Create” and then wait for a few minutes for the windows VM to provision itself.

Step 2: Create the Azure Log Analytics Workspace Instance

In the home page of the Azure portal, click on “Create a resource” and then search for “log analytics workspace”

After clicking on “Create”, select the resource group that you’d created while configuring your VM from the dropdown menu, set a name for the log analytics workspace, and then click on “Review + create”.

Step 3: Configure Microsoft Defender for Cloud

After this has been created, go back to the home page -> click on the search bar at the top -> Search for “Microsoft Defender for Cloud” -> Click on the “Environment settings” tab.

Within “Environment settings”, click on the Azure subscription dropdown menu and select the log analytics workspace that we had created.

Within “Defender plans”, set the configuration as per the below screenshot and click on “Save”.

Within the “Data collection” tab, configure it to log all events. Then click on “Save” again.

Step 4: Link the Log Analytics Workspace instance with our vulnerable VM

Navigate back to the home page. From there, click on the log analytics workspace instance -> Click on the “Classic” drop down menu on the left -> Click on “Virtual machines (deprecated)”.

From the list, click on the VM that we had previously created and then click on “Connect”

This is done so that the log analytics workspace can pull event logs from the vulnerable VM for our analysis.

Step 5: Configure Microsoft Sentinel to retrieve logs from the log analytics workspace.

In the search bar at the top, Search “Microsoft Sentinel” and click on the first result

Click on “Create” (Kindly ignore the existing entry, yours will probably be blank)

Click on the Log Analytics Workspace instance that we had created and then click on “Add”.

Step 6: Connect to the VM and Configure it to be Vulnerable

Navigate to your VM instance, copy the public IP address, and enter the same in an RDP window and click on “Connect” to connect into the VM remotely.

In the credentials screen, click on “more choices” -> “use a different account” -> enter the credentials that we had set up while creating the VM -> Click on “Ok”

[Click “Yes” when prompted whether to connect to the machine]

Once connected, set up the machine as per the below screenshot.

Once the VM is set up, open the Windows Event Viewer

Within the Event Viewer, navigate to Windows logs -> Security

Identify the logs with the Event ID: 4625. These logs pertain to the Failed RDP logins, which we are aiming to extract to our Azure Log Analytics Workspace.

[Note: you may not see as many events on your Windows Event Viewer instance, and that’s okay. If you leave the VM running for a few hours, it will ultimately accumulate multiple failed logins from external entities owing to our insecure Network Security Group setup. You can also contribute to this data by deliberately causing failed RDP attempts].

Once the required event ID has been noted, access the windows firewall settings by searching “wf.msc”

Click on “Windows Defender Firewall Properties”

Set the Firewall state to “Off” for the Domain, Private and Public profiles

[Note: I know that this has been repetitively mentioned in this article, but to re-iterate, these changes are being made with the sole purpose of making the VM as vulnerable as possible. DO NOT replicate these settings on your own systems]

Step 7: Setup the Third-Party API to Retrieve the Location Details

As mentioned in the introduction of this project, our aim is to determine the attackers’ country of origin so as to plot and view this data on a map. For this purpose, we will be using the “ipgeolocation” API, which accepts a public IP as input, and returns the respective location details pertaining to that IP.

Navigate to the API website (https://ipgeolocation.io/)

Upon visiting, the website showcases the types of data that it can return upon receiving a public IP address.

To gain access to the API key, create an account using the “Sign Up” menu.

Once you’ve logged in with your credentials, your API key will be visible.

Step 8: Exfiltrate and Collate the Failed RDP Logs from Event Viewer

To achieve this, we will be utilizing the below PowerShell script

Script Link: https://github.com/sidsmenon/sentinel-honeypot/blob/main/log_export_script.ps1

To run the script, open “PowerShell ISE” in the Windows Machine

Once opened, click on the highlighted icon, paste the script, and change the existing API ID to include the one that you had created.

Next, click on the highlighted icon to execute the script, and keep it running so that failed login attempts started to appear in the output.

Soon, you will start to see multiple entries popping up, highlighting the multiple attempts that are being made by attackers from all over the world to take over your machine. When you dive deeper into the output, you will notice some interesting parameters such as the username that was entered while attempting to login, and the origin country of such attacks.

Once you have received a significant amount of attack data, stop the execution of the script and visit the path that is highlighted in the above screenshot to access our log file.

Note: In an ideal scenario, the script must be kept running, so that the
latest attacks keep getting appended onto the failed RDP log file. For the
purpose of this demonstration, we are minimizing the dataset.

As shown below, the attacker data which was outputted by the PowerShell script has been appended to the log file.

Step 9: Ingest the Log File to the Azure Log Analytics Workspace for Further Analysis

Moving back to the Azure portal, navigate to our Log Analytics Workspace instance and click on “Tables”, which is present in the “Settings” dropdown.

Then, click on the dropdown button that is next to “Create” and choose “New custom log (MMA Based)”.

In the next page, copy over our log file from the Windows VM to our local machine, select it, and then click on “Next”. This log file will be used as a reference by the log analytics workspace to extract further such logs with the same structure.

Keep the delimiter as “New line” and click on “Next” again

Then, select the path type as “Windows” and copy the path to the “failed_rdp.log” file in the “Path” field. Here, we are defining where the log analytics workspace must look for within our Windows VM to automatically capture all future logs.

Provide a custom, easily identifiable name for the log file and then click on “Next”.

Review the details on the next screen, and click on “Create”

Then, click on the “Logs” section of the analytics workspace, add the name of your table in the text area, and click on the highlighted run button to check if the log analytics workspace is able to retrieve the logs from the VM.

Note 1: While creating the table, Azure will automatically add an '_CL'
to the end of the table name. Please enter the table name accordingly.

Note 2: If you initially receive the "No results found from the last 24 hours"
error, DO NOT PANIC. It takes time for the log analytics workspace to reach
the specified collection path and to retrieve the logs. You can keep retrying
for a few minutes until the logs finally appear in the output.

After a while, when we click on ‘Run’, the logs will finally start to appear in the output, as shown below.

Now, our goal is to extract and represent the data that is associated with each parameter in such a way that the Azure Sentinel instance will be able to comprehend, analyze and ultimately plot them onto the world map. To achieve this, we will be running the below log query:

FAILED_RDP_LOGS_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

After running the query, we’ll get the below output wherein the data associated with each parameter has been neatly segregated. This query can now be used to create our Azure Sentinel Workbook

Step 10: Configure the Azure Sentinel Workbook to Plot the Data as Required:

From the home page, navigate to Azure Sentinel, choose our Log Analytics Instance, and then click on “Workbooks” within the “Threat management” dropdown.

In the next page, click on “Add Workbook”

Then, click on “Edit”, and remove the pre-populated data.

Once the items have been removed, click on the “Add” button and choose “Add query”.

Paste the query which we had previously utilized in the Log Analytics Workspace, choose “Map” from the visualization drop down menu, and click on “Run Query”

Upon running the query, we receive the below output:

Set the metric label option to ‘label’, click on apply, and then click on “Done Editing” at the top left.

After doing so, we receive the below final output which clearly highlights the origin, frequency and the IP details of the attackers.

Bonus Step: Cleanup (Important):

Once you are done recreating this project, remember to de-provision the different services that we have utilized, especially the vulnerable Windows VM, so as to avoid any additional unintended costs.

Project Limitations:

1. This project focuses solely on tracking just a single log type, namely the failed RDP logs.
2. In this project, we have just implemented a simple, small scale setup for our analysis, including a standalone Windows VM.
3. We are solely reliant on external threats to generate the respective security logs. No attack simulation was performed.
4. To obtain the attacker coordinate details, we have a dependency on the ‘ipgeolocation’ third-party API. In its free tier, the API only allows for up to 1000 calls, resulting in a lapse in the tracking of further attack attempts.
5. No mitigation steps were covered in this demonstration.

I will be working on addressing these limitations in the next iteration of this project. Stay tuned!

Until then, I hope you found this walkthrough to be useful and were able to follow along with it. Please let me know your thoughts in the comments.

Thank You!