Building and Hardening an Azure Honeypot: A Journey with Microsoft Sentinel and Live Internet Threats (Part 2)

Deploying the Honeypot Infrastructure in Azure

Introduction

Welcome back to the blog series, ‘Building and Hardening an Azure Honeypot: A Journey with Microsoft Sentinel and Live Internet Threats’. Click the link to part one of the lab where we introduced the lab and its components.

The first step of this lab exercise is to deploy our vulnerable Azure resources ensuring that they have unrestricted public access and their logs can be collected by our Azure SOC resources. The resources we will deploy here are: Windows Server VM, Linux Server VM, Network Security Groups for the two virtual machines, Blob Storage, Azure Key Vault, the Log Analytics Workspace and Azure Sentinel.

NB: As we proceed, this lab assumes that you have an Azure subscription and it has global administrator permissions. The default region where we will deploy our resources is the UK South region.

Here is a reminder of the lab architecture:

Create the resource group to hold all our lab resources

1. In the Azure Portal Search Bar, enter Resource Groups and select Resource groups from the list of results.
2. On the Resource Groups page, select Create.
3. On the Create a Resource Group page, select your subscription and enter the name Honeypot-RG. Set the region to UK South, choose Review + Create.

4. Then choose Create. Your resource group should appear in your list of Resource Groups.

Create a virtual network that will connect the VMs

Since, we are simulating and organization’s infrastructure, our virtual machines need to be connected in a network. By default, machines in the same virtual network or subnet can communicate with each other without the need for routing. You can refer to my lab Building Azure Virtual Network Infrastructure for Small Businesses: Filtering Web Traffic with NSG Rules by Network Segments for more information on Azure Virtual Networks.

1. In the search box at the top of the portal, type Virtual networks. Select Virtual networks in the search results.
2. On the Virtual networks page, select + Create.
3. On the Basics tab of Create virtual network, enter or select the following information:

4. Click on the IP Addresses tab.

5. In the address space box in Subnets, select the default subnet

6. In Edit subnet, enter or select the following information:

7. Select Save.

8. Select Review + create at the bottom of the screen, and when validation passes, select Create.

9. Once created, you can click on Go to Resource where you will see the virtual network deployed as follows:

Deploy and Configure the Windows Server virtual machine

1. In the Azure Portal Search Bar, enter Virtual Machines and select Virtual Machines from the list of results.
2. On the Virtual Machines page, choose Create and select Azure Virtual Machine.
3. On the Basics page of the Create a Virtual Machine wizard, select the following settings and then choose Review + Create.

4. Click on the Networking tab. Ensure the virtual network selected is the created vnet-1.

5. Select Review + create then select Create.

Deploy the Linux Server virtual machine

1. In the Azure Portal Search Bar, enter Virtual Machines and select Virtual Machines from the list of results.
2. On the Virtual Machines page, choose Create and select Azure Virtual Machine.
3. On the Basics page of the Create A Virtual Machine wizard, select the following settings and then choose Review + Create.

4. Click on the Networking tab. Ensure the virtual network selected is the created vnet-1.

5. Click Review + create, review the information and then choose Create.

6. Your two servers should be available as follows:

Configure the Network Security Groups for the Virtual Machines

The next step is to configure the Network Security Groups (Layer 4 Firewalls) to allow all traffic inbound to both our servers. We want all kinds of malicious traffic from the internet into our machines.

Windows Server NGS

1. In the Azure Portal Search Bar, enter Resource Groups and select Honeypot-RG from the list of results.
2. On the list of resources, select the WindowsServer-VM-nsg.

3. Delete the default RDP rule under Inbound Security Rules.

4. Select Inbound security rules from the Settings section.

5. In Inbound security rules page, select + Add:

6. In Add inbound security rule page, enter or select this information:

The rule would typically look like this:

7. Select Add.

Linux Server NSG

1. In the Azure Portal Search Bar, enter Resource Groups and select Honeypot-RG from the list of results.
2. On the list of resources, select the LinuxServer-VM-nsg.
3. Delete the default SSH rule under Inbound Security Rules.
4. Select Inbound security rules from the Settings section.
5. In Inbound security rules page, select + Add:
6. In Add inbound security rule page, enter or select this information:

The rule would typically look like this:

Take note of the warnings from Azure as we proceed:

7. Select Add.

Turn off the internal windows firewall

There’s an important consideration for our Windows Server VM. Even if threat actors are allowed to flow through our Windows VM’s NSG, they’ll still get blocked by the firewall on the local machine. We’ll need to turn off the local Windows firewall to make it more accessible.

1. In the Azure Portal Search Bar, enter WindowsServer-VM and select WindowsServer-VM from the list of results.
2. In the overview page, take note of the public IP address of our server.

3. Open the Remote Desktop Connection app on your local Windows machine (Assuming you’re building this app using a Windows hosted machine).

4. Enter the public IP address of the WindowsServer-VM and click on Connect.

5. Sign in using the Administrator credentials that we created i.e. User name: Robert, Password: P@ssword1234.

6. Once connected to the VM, we can navigate to the Windows firewall by typing “wf.msc” in the start menu.

7. In the Windows Defender Firewall, click on Windows Defender Firewall Properties.

8. Make sure the Firewall state for Domain Profile, Private Profile, and Public Profile are OFF.

9. Select Apply, then OK.

Install the SQL server in the Windows Virtual Machine

While still in our Windows Server, let’s proceed to install the Microsoft SQL Server in it. We do this to provide the hackers with an extra endpoint to attack and more logs of a different kind for us to analyze.

1. Open Microsoft Edge in the Windows VM and search “download sql server evaluation 2022.” The top results should lead to a Microsoft page with download instructions.

2. Once downloaded, open the file and select Download Media.

3. Select the ISO file, choose download location, and click Download.

4. Once we have downloaded the ISO file, navigate to it and Mount it.

5. The following window should open. Click the Setup button to open SQL Server Installation Center.

6. Click on Installation, then click on New SQL Server standalone installation or add features to an existing installation.

7. Select Evaluation, then hit Next.

8. Continue clicking next until you get to the Feature Selection screen. Here, mark the Database Engine Services checkbox then click Next.

9. Click next until you reach the Database Engine Configuration screen. Select Mixed Mode, then enter P@ssword1234 as password. Note down the username “sa” as well as the password. We will need it for later. Click on Add Current User. Then click on Next until you get to the installation page.

10. Close the installation window once completed.

11. Go back to the SQL Server Installation Center, click on Install SQL Server Management Tools.

12. You will be taken to a website to download SSMS (SQL Server Management Studio). Download the file and install it. Close the window once it has completed setting up.

13. After successfully installing SSMS, search SQL server management, then open the SQL Server Management Studio app.

14. The SSMS app will prompt us for a username and password. Select SQL Server Authentication then enter sa and P@ssword1234 respectively. Then click on Connect.

Configure SQL Server to send logs to Windows Security Log

By default, SQL Server doesn’t automatically send failed or successful logon attempts to the Windows Security log. We want to make sure that any logon attempts to access the SQL database are transferred to the Windows Security log so that we can observe the entries in the Windows Event Viewer.

1. Once logged into your SQL server account, right-click on WindowsServer-V and select Properties.

2. In the Server properties window, click on Security, the check off the Both failed and successful logins. Then click OK.

3. Open the web browser in your VM and go to the link: Write SQL Server Audit events to the Security log to continue with the next steps and learn more about what we are trying to achieve.

4. Open the Command prompt as an Administrator and paste the following command. Execute the command.

5. The execution should be successfully complete. Search for Registry Editor, then open the App.

6. Enter this into the directory path: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security. Then right click on Security and click on Permissions.

7. Click on Add. Then enter NETWORK SERVICE, click Check Names, then click OK.

8. The NETWORK SERVICE has been added to the group. Next, check off the boxes below and hit OK.

9. Navigate back to our SQL Server Management Studio, we need to restart our SQL Server. Right click on WindowsServer-VM and click on Restart.

10. We have successfully enabled logging for SQL Server to be ported into Windows Event Viewer.

Testing the VMs accessibility with Ping Commands

We now need to confirm that we’ve setup our virtual machines correctly to allow all inbound traffic to reach our honeypot. We can use the ping command to check whether our VMs’ IP addresses are assigned and verify that our NSGs are configured to let inbound traffic reach our VMs.

The ping command uses the ICMP Protocol: A Network Layer protocol used by network devices to diagnose network communication issues i.e. determine whether or not data is reaching its intended destination in a timely manner.

Open the command prompt on your local machine and run the ping commands as follows with our servers’ IP addresses as follows:

No timeout means the VMs are running and can be accessed by any device on the internet.

Attack Simulation to Generate and Verify Logs for SOC

We need to endure that our deployments so far generate the following logs:

• Windows Authorization attempts.
• Microsoft SQL server Authorization Attempts.
• Linux Authorization Attempts.

Here, we will use our local Windows machine to carry out the test. Alternatively, you can deploy a Windows Attack VM in the cloud in a different region and resource group to act as your attack virtual machine. In both instances, the machine will simulate a threat actor.

RDP into Windows Server VM

Attempt to login our Windows Server VM IP address via RDP with some random username and password. This will fail. Then proceed to enter the correct username and password and log in to your Windows Server VM.

SQL Server failed authentication

Once logged in to the server, Open SQL Server Management Studio. Again here, attempt to access the SQL Server account by typing random username and password before finally logging in with the correct credentials.

Log Inspection with Event Viewer

Now we’re going to inspect the failed authentication security and application logs. Since we are already logged into our Windows Server VM, search for Event Viewer in the Windows search menu.

1. Click on Windows Logs then Application. Here, we will see the failed login attempts into the SQL server.

2. Next, click on Security. Here you should see the failed RDP login attempts as well.

Linux VM SSH login attempts

SSH, or Secure Shell, is a protocol used to securely log into a remote Linux virtual machine via a terminal. It typically operates over TCP/IP port 22. SSH has the following format:

Ssh <username>@<IP_ADDRESS>

Here, <username> is replaced with your login name and <IP_ADDRESS> with the Linux Server VM Ip address. You will then be prompted to enter a password. We will use PowerShell terminal in our Attack machine.

Now I’ll unsuccessfully SSH into our Linux honeypot VM to generate logs.

e4

Next, we need to view the failed SSH login attempts by following the steps below:

1. Ensure you successfully SSH into the Linux machine using the correct credentials. You should be logged into the Linux Server terminal as follows:

2. Navigate to the /var/log directory using the cd command. Then proceed to see the list of files and subdirectories within it using the ls command.

3. The auth.log file contains authentication events on the system. We use the cat auth.log command to view its contents. To get the targeted response we need, we pipe the grep command to filter for my name, which I used as the username in the failed logon attempt.

Configure Microsoft Entra ID, add users

We need to create an active directory and add users to make the lab a little bit more realistic. Microsoft Entra ID, Azure’s Active Directory, is responsible for user creation, deletion, and permission changes.

1. In the Azure Portal Search Bar, enter Microsoft Entra ID and select Microsoft Entra ID from the list of results.
2. Under Manage, click on Users.

3. Click on New User and select Create new user.

4. On the Create new user page, fill in the information below. Take note of the password your use.

5. Select Review + Create. Then select Create.

6. Once the user has been created, click on it then click on Assigned Roles.

7. Click on Assignments. A new Directory roles window will popup. Type reader in the input field, then select Global Reader. Then click on the Add button at the bottom of screen.

8. We have successfully created our user with global read permissions.

Deploy Azure Key Vault

Azure Key Vault helps safeguard security keys, certificates and other secrets that cloud applications and services use. Key Vault streamlines the key management process and enables you to maintain control of keys that access and encrypt your data. Vaults are the secure containers that hold the secrets and keys allow access to the secrets in the vault.

1. In the Azure Portal Search Bar, enter Key Vault and select Key Vault from the list of results.
2. Click on Create Key Vault.

3. Enter the configurations below then click on Next.

4. Select the Permission Model as Vault access policy. A Key Vault access policy determines whether a given security principal, namely a user, application or user group, can perform different operations on keys, secrets and certificates as opposed to the Azure RBAC authorization.

5. Click Review + Create. Then Create.

6. Now, let’s create a secret i.e. a password, API key, connection string etc. Click on the honeypot-kv. Under objects, select secrets. Click on Generate/Import.

7. Proceed to create a random secret.

Now, our honeypot is done. We need to allow detection and monitoring.

With that our honeypot is complete and deployed on the internet. Next, let’s proceed to setup our SOC so that can have detection and monitoring enable in part three of our blog series.

Happy Learning!