1. Provisioning and deprovisioning virtual environments within Azure.
2. Third-party API calls.
3. Security Information and Event Management - log anaylyis and visualization.

NOTE: Since we will utilize RDP you will need a Windows host machine - a Windows virtual machine will also work.

• Microsft Azure - a cloud computing service operated by Microsoft for application management via Microsoft-managed data centers
• Services within Azure: Log Analytics Workspace and Sentinel (Mircosoft's SIEM)
• Powershell
• Remote desktop protocol

Step-by-step overview of lab:

1. Create Azure subscription (FREE $200 credits)
2. Create virtual machine in Azure (honeypot-vm) > turn firewalls off (making it vulnerable to brute force attacks)
3. Use a Powershell script to extract IP of attackers > feed IP into third party API and return back to honeypot-vm specific location information.
4. Create log repository in Azure (Log Analytics Workspace) - this will ingest our logs from honeypot-vm
5. Set up Sentinel - Microsoft’s cloud native SIEM
6. Use data from SIEM to map out attacker information and magnitude

• Click on “Go to the Azure Portal” or go to portal.azure.com once you create your account.

• In the search bar of the “Quickstart Center” page > search and click virtual machine
• This will be the honey pot virtual machine made to entice attackers from all over the world

• Edit the virtual machine as follows:
• Click create new under resource group and name it honeypotlab (this resource group is a logical grouping of similar resources)
• Name the virtual machine: honeypot-vm
• Under region select: (US) East US 2
• Under Image select: Windows 10 pro, version 21H2 - Gen2
• Availability zone: Zones 2 (screenshot is incorrect; choose Zones 2)
• Under size: Standard_D2as_v4 - 2 vcpus, 8 GiB memory
• Create a username and password - don’t forget credentials
• Finally, check confirm box - leaving the rest in their default options

• Under NIC network security group select > Advance and under Configure network security group select Create new
• You should see a default rule (something like 1000: default-allow-rdp), click the three dots to the right of it and remove it.
• Select Add an inbound rule
• Match the settings of the new rule as follows:
• Set Destination port ranges: *
• Priority: 100
• Name: DANGER_ANY_INBOUND
• Leave the rest of the settings as default
• Click Add > OK > Review + create - wait a bit to load and click Create

The point of this new firewall rule is to allow any traffic from anywhere. This will make our virtual machine very discoverable.

• As we wait for our vm to deploy, go back to the search bar and search and click Log Analytics workspaces

The purpose of this workspace is to ingest logs from our vm. Additionally, we will create our own custom logs that will contain geographic information on who is attacking us. Later, our MS SIEM will feed logs into here.

• Select the blue Create log analytics workspace button
• Under the Basics tab:
• Resource source group: honeypot—lab
• Name: law-honeypot1
• Region: West US 2 (screenshot is incorrect; choose West US 2)
• Click Review + Create and click Create

• Back in the search bar search and click Microsoft Defender for Cloud
• Once on the dashboard click > Environment Settings > (through the drop down menus) > law-honeypot1

• Under Data Collection tab select All Events. Hit save.

• On the search bar select Log Analytics workspace
• Select law-honeypot1 > Virtual Machines > honeypot-vm
• Click connect, after clicking honeypot-vm
• It will take some time to successfully connect; you should get a message confirming connection.

• In search bar find Microsoft Sentinel
• Click Create Microsoft Sentinel > select law-honeypot1 > Add
• This will also take some time

• Through the search bar, find our honeypot-vm > copy the Public IP address (highlighted here on the right)

• On your Windows machine (Windows vm will also work) search and open Remote Desktop Connection
• Paste your Azure IP into Computer
• Before connecting, click Display and scale down display configuration for easier viewing
• Click connect
• In the Enter your credentials window click more choices > Use a different account
• Enter invalid credentials tin order to generate a log for later viewing.
• Then, enter your credentials we created for our Azure vm in Step 3, click OK.
• Accept the certificate warning
• You should be logged into the vm when you see “Remote Desktop Connection” at the top of the screen.

• Click NO to all privacy settings and Accept
• Set up Edge
• Search and click Event Viewer
• Click Windows Logs > Security and find the Audit Failure log (our failed login attempt; if you don’t see it at first filter current log by “Audit Failure” found to the left)

The Source Network Address will represent the attacker’s IPs and eventually where on Earth they are attacking us! But in order to do this we need to send this network address to a third party API… but more on that later.

• Open command prompt on your host machine and try to ping the Azure vm - it shouldn’t work!
• Search and open wf.msc on Azure vm - remember to keep an eye on vm IP at the very top to confirm you’re in the vm and NOT in on your host to avoid confusion.
• Click Windows Defender Firewall Properties near the middle of the page
• Under the Domain Profile > Firewall state: OFF
• Under Private Profile > Firewall state: OFF
• Under Public Profile > Firewall state: OFF
• Try to ping vm again from your host machine - this should now work!

• Open Powershell ISE
• For convenience you can copy/paste the code into a new ps1 file and save it to the desktop of the honeypot-vm (remember to see vm IP at the top)
• You will also need an API key, get here: API key
• Create an account and log in
• Copy and paste your API key in your Powershell script $API_KEY = “_your API key_”
• Save file.

Quick explanation of script: the script will parse through the security event logs (Audit Failure/failed login logs we looked at earlier) and grab IP information. The script then passes the IP thorough the API and correlates the info into longitude and latitude, giving us specific geographical information.

• Test and run the script pass pressing green play button at top of window
• You should receive purple logs indicating latitude / latitude of failed logins (some sample logs and some log when we failed to log in)

NOTE: Keep Powershell script running in the backgroup. We need to continously feed our log repository information.

• This log will use IP information to give us specific geolocation to our create map down the line.
• Search and click Log Analytics Workspace > law-honeypot1 > custom logs > + Add custom log
• We need to upload a sample log to “train” log analytics on what to look for.

• Our sample logs are in our honeypot-vm.
• In our honeypot-vm, search RUN > search C:\ProgramData\ and open the failed_rdp file.
• Our failed RDP logins are sent to this txt file, open and copy all the sample logs.
• Back on our host machine, open notes and paste our sample logs.
• Save the file in a log or txt format and upload it in the Create a custom log page. Click next and you should see the sample logs.

• Click next > Create >Review + Create
• Let’s go back to log analytics and check if Azure is connected and listening to our vm.

• Under law-honeypot1 > General > Logs > search SecurityEvent and click blue Run button.
• Give it a moment, and voila! It returns the same security logs window from our honeypot-vm’s Event Viewer.
• Give it some time and search our custom: FAILED_RDP_WITH_GEO_CL will it will return our sample logs.

• Take a look at our sample logs in our FAILED_RDP_WITH_GEO_CL.
• In the RawData columns we find information like longitude, latitude, destination host, etc.
• We need to categorize longitude, latitude, destination host, etc. values from the raw data before we can obtain geolocation data.
• It sounds a bit abstract now, but bare with me.

NOTE: If you step away and come back to this lab after a day or two make sure to change the Time range accordingly.

• Right-click the first log you see in the search results and click Extract Fields from FAILED_RDP_WITH_GEO_CL
• Under Main Example highlight the latitude VALUE - not the word ‘latitude’ itself
• A window will automatically pop-up
• Under Field value type latitude and under Filed type choose numeric, click Extract
• To the right, check that the SIEM is selecting the correct values on each sample log.
• Click save extraction.

This is an important step because we are ‘training’ our SIEM what to look out for.

• Same process, different values.
• Right-click the same log > Extract files from…
• Now this time highlight longitude value
• Field value: longitude > filed type: numeric, click Extract
• Inside our search results it looks like our SIEM needs some help because it highlighted latitude when we were asking for LONGITUDE (bad siem).
• Worry not: this is where some corrective training comes into play.
• Click the little pencil within a circle icon at the top-right of the incorrect search result.
• Click modify this highlight and highlight the longitude value once more.
• Again: Field value: longitude > filed type: numeric, click Extract
• Take a look at the search result, it should now highlight the correct longitude value.
• Continue to train our SIEM and correct a few more search results.

• The same process to when we extracted latitude and longitude values.
• Remember to highlight the vaules and to select the correct field value and field type
• Right-click the same log > Extract files from…
• Highlight destination host value > filed title: destinationhost > type: text
• Re-select vales if needed and save
• Remember to save after each selection - you can’t select more than one value at a time
• Highlight user name value > filed title: username > type: text
• Highlight source host value > filed title: sourcehost > type: text
• Highlight state value > filed title: state > type: text
• Highlight country value > filed title: country > type: text
• Highlight label value > filed title: label > type: text
• Highlight timestamp value > filed title: timestamp > type: Date/Time
• Hit save extraction for the final time and we’re done extracting!
• Under setting columns to the left click Custom Logs > Custom fields
• Your custom fields we just made should look something like this:

A couple of notes before moving on: make sure our Powershell script log_exporter.log is running. The script will continue to feed our SIEM with fresh new logs.

After extracting the data from our logs, you may or may not already see people trying to RDP into our vm (!). Give it some time.

• Next, we will map out our logs within Sentinel with the extracted data - to see where in the world is our vm is being attacked from.
• Search and click Microsoft Sentinel > choose law-honeypot1 and under Threat management choose Workbooks > click + Add workbook
• Click edit > click the “ … “ on the right side on the screen and remove the two widgets.
• Click Add > Add query and paste the following into the query:

FAILED_RDP_WITH_GEO_CL | summarize event_count=count() by sourcehost_CF, latitude_CF, longitude_CF, country_CF, label_CF, destinationhost_CF | where destinationhost_CF != "samplehost" | where sourcehost_CF != ""

This will parse through the failed RDP’s logs and return to us location information through our custom fields we created.

The last two lines will ensure we DON’T receive anything with sample host or anything blank.

• Click Run Query
• Troubleshooting: if you run into any issue with a CF (custom field) try removing the troubling CF from the query and run search again.
• From the visualization drop box select Map
• In map settings > layout setting (on the right of screen):
• Under Location Info Using Select longitude/latitude (if longitude/latitude gives you trouble select country or region, and vice versa)
• Under latitude: latitude_CF
• Under longitude: longitude_CF
• Scroll down to find Metric Settings:
• Under Metric Label select label_CF
• Metric Value: event_count
• Hit Apply …
• On the map you see where you’re being attacked from!
• You might only see the failed logins you made, but after some time refresh and look again.
• Pretty rad - if you take a look at the actual logs you can see source IP, time, country, user name and other details!
• Remember too, these logs are only reporting back failed RDP attempts… who knows what other attacks are being attempted.

• Hit > save and close
• Hit the floppy disk at the top to save the map.
• Title: Failed RDP World Map > Location: West US 2 > Resource group: honeypot-lab > click Apply
• And we’re done! - by now people should be attacking your vm, congrats!
• You can hit the refresh icon near the top of the map (make sure Powershell script is running) to load more logs into the map
• Also, you can click Auto refresh ON to refresh every so often.

• Once you are done with the lab delete the resources, otherwise they will eat away from your free credit (deprovisioning is also a good thing to keep in mind at the enterprise level)
• Search and click Resource group > honeypot-lab > Delete resource group
• Type the name honeypot-lab to confirm deletion

And there you have it, you have successfully mapped out the location of your RDP attackers using a honey pot vm.