Implementing a SOC and Honeynet in Azure
- Evan Strumpis
- Nov 17, 2024
- 4 min read
Updated: Nov 18, 2024
Overview
In this project, I set up a mini honeynet in Azure to analyze security events and improve defenses. Log sources from various resources are ingested into a Log Analytics workspace, which integrates with Microsoft Sentinel to generate attack maps, trigger alerts, and create incidents.
To evaluate the impact of security controls, I first measured key security metrics in an intentionally insecure environment over a 24-hour period. After applying security controls to harden the environment, I repeated the measurements for another 24 hours to compare results.
The metrics analyzed include:
SecurityEvent: Windows Event Logs
Syslog: Linux Event Logs
SecurityAlert: Alerts triggered in Log Analytics
SecurityIncident: Incidents created in Microsoft Sentinel
AzureNetworkAnalytics_CL: Malicious network flows allowed into the honeynet
Within the Azure environment, I began by creating three virtual machines: one running Linux and two others running Windows 10. Two of the three machines were intentionally configured as honeypots to attract potential attacks. The remaining Windows 10 machine will be my attack virtual machine, we will get to this later.
To make them more susceptible to threats, I applied specific configurations:
Windows 10 Virtual Machine: I locally disabled the Windows Defender Firewall on all profiles. Additionally, I removed the default RDP firewall rule and created a new rule that allows unrestricted traffic to the machine.
Linux VM: I removed the SSH firewall rule and replaced it with a new rule permitting all incoming traffic to the device.
These configurations ensure the machines are exposed and can effectively serve their purpose as vulnerable targets for attackers. I also installed SQL Server to the Windows 10 virtual machine to provide another target for potential threats. SSMS (SQL Server Management Studio) was downloaded to log into the server and enable logging to the Windows Event Viewer.
After enabling logging for SQL Server on the Windows 10 machine, I moved on to the Linux machine to verify it was functioning correctly. I started by pinging the machine then used SSH to log in.
Next, I moved to the attack machine to verify that logging was functioning correctly for each target VM.
Windows VM: I attempted to RDP into the Windows machine, deliberately entering incorrect credentials multiple times. These actions were intended to trigger failed login events that could be captured in the logs.
Linux VM: Using PowerShell on the attack machine, I initiated SSH sessions with invalid credentials. In the screenshot below, you can see failed password attempts logged on the Linux machine. The invalid login attempts I generated from the attack machine are for the users 'evan' and 'labuser'. Meanwhile, someone already found the machine and the logs within the brackets represent the unauthorized access attempts from them brute-forcing.
SQL Server: I installed SSMS (SQL Server Management Studio) on the attack machine and generated additional failed login attempts against the SQL Server.
These actions provided a controlled way to ensure that each machine and service was logging unauthorized access attempts as expected. I set up a Log Analytics Workspace, which will serve as the central hub for collecting and analyzing logs from all endpoints in the lab. Microsoft Sentinel will pull from the Log Analytics Workspace, enabling advanced threat detection, alerting, and incident management. I activated Microsoft Defender for Cloud and enabled NSG flow logs for both virtual machines. Additionally, I configured data collection rules for each machine. Alerts were configured in Microsoft Sentinel to detect and identify any malicious activity within the environment. With everything set up, I’m now letting the environment run for 24 hours to monitor and capture activity.
After 24 hours, I analyzed the recorded data, and the world maps revealed the origin of various threats targeting the honeynet. These maps provided valuable insights into global attack patterns and emphasized the importance of real-time monitoring and analysis in securing exposed systems.
As you can see, there is a significant amount of activity in the environment. My next step is to reduce this activity drastically. I’ll be reviewing the alerts in Microsoft Sentinel, addressing each ticket individually, performing incident response, and hardening the systems. I’ll also integrate the NIST 800-53 framework into Microsoft Defender for Cloud and implement some of its standards across my environment. Once the environment is secured, I’ll let it run for another 24 hours to observe and compare the results in the secure setup. This process will highlight the impact of the implemented security measures.
The following table shows the metrics we measured in our insecure environment for 24 hours: Start Time 2024-11-16 11:35 - Stop Time 2024-11-17 11:35
SecurityEvents (Windows VM) | 10,148 |
Syslog (Linux VM) | 8,713 |
SecurityAlert (MS Defender for Cloud) | 2 |
SecurityIncident (Sentinel Incidents) | 242 |
NSG Inbound Malicious Flows Allowed | 3535 |
The following table shows the metrics we measured in our environment for another 24 hours, but after we have applied security controls: Start Time 2024-11-17 20:29 - Stop Time 2024-11-18 20:29
SecurityEvents (Windows VM) | 910 |
Syslog (Linux VM) | 0 |
SecurityAlert (MS Defender for Cloud) | 0 |
SecurityIncident (Sentinel Incidents) | 0 |
NSG Inbound Malicious Flows Allowed | 0 |
In this project, a mini honeynet was built in Microsoft Azure, with log sources integrated into a Log Analytics Workspace to centralize monitoring and analysis. Microsoft Sentinel was configured to trigger alerts and create incidents based on the collected logs. To assess the effectiveness of security measures, metrics were first captured in the insecure environment, then re-evaluated after implementing security controls. The results showed a significant reduction in security events and incidents, highlighting the impact of the applied controls.
It’s important to note that if the network resources had been actively utilized by regular users, the number of security events and alerts during the 24-hour period following the implementation of controls might have been higher, as user activity often introduces additional logging and potential anomalies.
Comments