Building a (mini) SOC & Honeynet in Azure (w/Live Traffic)

Overview

In this project, I built a small-scale honeynet and SOC in Azure. Log Analytics was used to ingest logs from various sources that Microsoft Sentinel would leverage to build attack maps, trigger alerts, and create incidents. Microsoft Defender for Cloud was used as a data source for LAW and to assess the VM configuration relative to regulatory frameworks/security controls. I configured log collection on the insecure environment, set security metrics then observed the environment for 24 hours. After investigating the incidents that Microsoft Sentinel generated during that period, security controls were applied to address the incidents and harden the environment based on recommendations from Microsoft Defender. After a second 24-hour observation new metrics were collected on the environment post-remediation.

Collected metrics:

• SecurityEvent (Windows Event Logs)
• Syslog (Linux Event Logs)
• SecurityAlert (Log Analytics Alerts Triggered)
• SecurityIncident (Incidents created by Sentinel)
• AzureNetworkAnalytics_CL (Malicious Flows allowed into my honeynet)

Architecture Before Hardening / Security Controls

The architecture of the mini honeynet in Azure consists of the following tools and components:

• Virtual Network (VNet)
• Network Security Group (NSG)
• Virtual Machines (2 Windows, 1 Linux)
• Azure Key Vault
• Azure Storage Account
• Microsoft SQL Server
• SQL Server Management Studio (SSMS)
• Azure Active Directory

Additionally, the SOC utilized the following tools, components and regulations:

• Microsoft Sentinel (SIEM)
• Microsoft Defender for Cloud
• NIST SP 800-53 Revision 4
• PCI DSS 3.2.1
• Log Analytics Workspace
• Windows Event Viewer
• Kusto Query Language (KQL)
• PowerShell

To collect the metrics for the insecure environment, all resources were originally deployed, exposed to the public internet. The Virtual Machines had their Network Security Groups open (allowing all traffic) and built-in firewalls disabled. All other resources were deployed with endpoints visible to the public Internet.

More details about each stage of this lab:

Stage I - Building the (mini) Honeynet

Stage II - Building the SOC

Stage III - Working Incidents and Incident Response

Stage IV - Secure Cloud Configuration

Metrics - Before Securing Environment

The MDC Security Score for the environment before hardening the environment:

The following table shows the measurements taken from the insecure environment after the initial 24 hour observation period:

Start Time: 1/18/2024 15:44
Stop Time: 1/19/2024 15:44

Attack Maps Before Hardening / Security

NSG Allowed Malicious Inbound Flows

Linux SSH Authentication Failures

Windows RDP/SMB Authentication Failures

MS SQL Server Authentication Failures

Architecture After Hardening / Security Controls

Metrics After Hardening

To collect the metrics for the secured environment, Network Security Groups were hardened by blocking ALL traffic (with the exception of my workstation), and built-in firewalls enabled. Azure Key Vault and Storage Container were protected by disabling access to public endpoints and replacing them with private endpoints.

The following table shows the measurements taken after applying the security controls the environment and observing for another 24 hours:

Start Time: 1/26/2024 19:10
Stop Time: 1/27/2024 19:10

Impact of Security Controls

Attack Maps After Hardening / Security Controls

All map queries returned no results due to no instances of malicious activity for the 24-hour period after hardening.

MDC Security Score after Hardening

Since this was a lab, I did not address every recommendation in Microsoft Defender for Cloud, but just a a few under SC-7 as a proof of concept. The MDC Security Score for the environment after hardening the environment:

Conclusion

In this project, a mini SOC honeynet was constructed in Microsoft Azure utilizing Log Analytics with Microsoft Sentinel. Sentinel used logs ingested by a Log Analytics workspace to trigger alerts and create incidents. Next, logging was enabled and data collected on the insecure environment based on established security metrics, before applying security controls. The logs and data were reassessed after implementing security measures. As a result, the number of security events and incidents were drastically reduced after the security controls were applied.

It is worth noting that if the resources within the network were heavily utilized by regular users, it is likely that more security events and alerts may have been generated within the 24-hour period following the implementation of the security controls.