Skip to content

Stage I - Building the (mini) Honeynet

This project consists of two target virtual machines and one threat VM - two Windows VMs (one used for attack) and one Linux VM.

Creating Resources

Create the Subscription

I already had an Azure account, a tenant (which I renamed + added a custom domain before this run) and a subscription from a previous run of the project. Here is an overview for the next few steps in this section:

stage 1 overview

For the sake of screenshots, I'm starting at creating the subscription. Don't forget to set a budget!

Creating Subscription

Creating Subscription Advanced

Creating Subscription Budget

Later, I actually changed the alert threshold to something more reasonable like 90%.

Create the first resource group

Next, create the first resource group (RG-Cyber-Lab). This one will house the resources that will be exposed to attack (the honeynet). Technically, this can be created at the same time that you create your VMs.

Create the First Resource Group

Create Virtual Machines

Next, create two VMs. One Windows VM and one Linux VM, using mostly default settings. Add both to the RG-Cyber-Lab resource group. Create a new Virtual Network the honeynet (Lab-VNet).

Create Windows VM

Basics tab:

Basics tab - Windows VM Wizard

Create a new Virtual Network:

Create a new VNet

Networking tab:

Network tab - Windows VM Wizard

Create Linux VM

Create the Linux VM with the same user, region, resource group and networking settings.

Basics tab:

Basics tab - Linux VM Wizard

Networking tab:

Networking tab - Linux VM Wizard

Exposing the resources

After both VMs are deployed, change both Network Security Groups (NSGs) to allow all inbound traffic. Removing rules for RDP and SSH and replacing with the custom inbound rule.

Windows NSG before:

Windows NSG before

Linux NSG before:

Linux NSG before

Custom Inbound Rule:

Add custom Inbound Rule

Windows NSG after:

Windows NSG after

At this point both NSGs are identical.

Create Vulnerabilities

Disable Windows Firewall

The goal is to expose these VMs to threat actors and to make them both discoverable and reachable so that we can monitor, log and investigate incidents later. By default Windows Firewall, blocks ICMP packets from the internet. You can see that from another network the windows-vm is unreachable.

Ping Windows VM with Firewall ON

From here, disable the firewall (wf.msc).

Before

Windows Firewall Before

After Windows Firewall After

Pinging windows-vm again to test success

Ping win-vm after firewall change

Connecting to the linux-vm via SSH using PuTTy

Connect to linux-vm using PuTTy

Connected to linux-vm

Test pinging linux-vm externally

Ping linux-vm

Install MS SQL Server + Utilities

Next, download and install SQL Server Evaluation.

Select Download Media.

Install MS SQL Server

Select ISO and download location.

Install MS SQL Server

Once the download completes, go to download location.

Install MS SQL Server

Mount the ISO.

Install MS SQL Server

Run the installer. Install MS SQL Server

Select New SQL Server

Install MS SQL Server

Include Database Engine Service

Install MS SQL Server

Select Mixed Mode, create a user and select add current user to also allow for Windows authentication using labuser.

Install MS SQL Server

Once the installation completes, download and install MS SQL Management Studio (SMSS).

Install SMSS

Install SMSS

Once the installation completes, restart the VM.

Enable Logging on SQL Server

After restarting, follow the Microsoft documentation for adjusting settings to allow SQL Server logs to be ported to Windows Event Viewer.

Provide full permission for the SQL Server service account (NETWORK SERVICE) to the registry hive.

Edit Registry Key

Grant MS SQL Server Full Control

Configure the audit object access setting in Windows using auditpol by executing the provided command line statement.

Execute auditpol statement in cmd

Launch SSMS and log in to the SQL Server. Then go to Properties > Security > Enable both

Security Settings Before

SQL Server Security Settings Before

Security Settings After SQL Server Security Settings After

Restart the SQL Server and try to generate some failed authentication logs by trying log into the SQL server with the wrong password.

Restart SQL Server

Check Event Viewer to make sure the logs are properly enabled and porting to Event Viewer successfully.

Check Event Viewer for Failed Auth Log

Create Attack (Threat) VM

Create another Windows VM in a different resource group, region, and virtual network. All other settings can be the same or similar.

Attack VM Overview

Generate Logs

To make sure everything is working as expected, log into the attack-vm to generate failed authentication logs on both vms.

generating logs overview

Generating failed RDP logs on windows-vm:

generate failed login w/rdp

Using PowerShell to generate failed login logs on linux-vm:

generate failed login with ssh on powershell

Installing SMSS on attack-vm:

install smss on attack-vm

Generating failed login logs for MS SQL Server on windows-vm:

generate failed sql server login

generate failed sql server login

Check Logs

Using PowerShell to SSH into linux-vm:

ssh into linux-vm with PS

Investigating the logs at /var/log/auth.log for failed authentication

the logs in auth.log file

Checking Event Viewer on windows-vm:

In Windows Event Viewer, there are normally a lot of logs, in the screenshots below the logs are filtered by the specific events we're looking for.

Windows Logs > Security, filtered by Event ID: 4625

failed login logs in windows event viewer

Windows Logs > Application, filtered by Event ID: 18456

failed sql login logs in windows event viewer