brianspells00/HoneyPot-Incident-Response

# 蜜罐事件响应

描述

在这个实验中，我使用 Microsoft Azure 资源创建了一个虚拟蜜罐，用于监控和分析安全事件日志，并使用 NIST 事件响应计划来检测、缓解安全漏洞并从中恢复。

使用的语言、实用程序和服务

- Microsoft Azure - Remote Desktop Protocol - Windows Defender Firewall

使用的虚拟环境

- Windows 10

项目演练：

First I created a Microsoft Azure account :

I then made a Resource Group as a place to store the resource I’ll be creating and configuring. Then confirmed it was created properly:

Then I created a Virtual Network (Vnet-SOC-HP-Lab) ensuring that the region of the Network is the same as the region of my Resource Group. Then confirmed its deployment:

Now I’ll be creating a virtual machine to act as a honeypot. I named the VM “ENT-EAST-3” selected Windows 10 as the OS, I created a username and password, selected the disk size and type for the OS. I then created the VM and confirmed the deployment:

Now when I navigate to the Resource Group I can see that a Public IP address, Network Security Group, Network Interface, and Disk were added into the group:

Since my goal is to be discovered I’ll need to modify the Network security rules. First I’ll delete the RDP rule and add a rule to allow all ports to be reached:

Now that all inbound traffic is allowed I now have to disable the firewall on the VM. I’ll be gaining access to the VM via using the public IP address and Remote Desktop Protocol. Once I was logged into the VM I navigated to Windows Defender Firewall properties and turned off the firewall state for the Domain, Private, and Public profiles:

I opened the Windows cmd and ran the prompt ping 40.76.120.54 to ensure that the machine could be reached:

I then disconnected from the VM and purposely entered the wrong login credentials. Then I login and navigate to the Event Viewer, click Windows Logs and then click Security:

I clicked on the code 4652 which is login related and viewed the event. The event was logged as a fail, indicating that the login attempt was unsuccessful:

Now that I know the logs are active and accurate I’ll create a log repository using Log Analytics workspaces in Azure:

Now I’ll add the Log Analytics workspace that I created to Microsoft Sentinel which acts as a SIEM:

Once it has finished being deployed I’ll go to configuration then select Data connectors and select Windows Security Events via AMA to install:

With that now installed we can set up data collection rules by clicking “Open connector page” Name the collector, select the resource group, ensure the VM is selected and create the collector:

To confirm the connection I verified that “AzureMonitorWindowsAgent” appeared under Extensions + applications of the VM and also went to the “Log Analytics workspaces” went to the Log tab and ran the command “SecurityEvent” to display the logged events:

Now with everything connected I’d like to set up an alert for failed log in attempts which can be done on the same KQL page by clicking the three dots on the top right of the query and selecting add rule. I set the parameters to every 5 minutes in order to collect a larger sample size. Also the severity of the alert was set to information rather than a lower number which would indicate a larger problem such as a successful login attempt from an unknown IP address:

Upon configuring the alert I noticed that my VM logs increased from 17 to 45, then to 75 but the logins were successful, however I hadn’t attempted to log into the VM since I disabled the firewall. That indicated to me that the VM was successfully infiltrated. I immediately checked the logs to see if I could obtain an IP of the attacker but the field returned no data:

I then ran the query SecurityEvent | project TimeGenerated, TargetUserName, Activity, TargetAccount, TargetDomainName, TargetSid,CallerProcessName, Process, IpAddress, EventID

To analyze the information together to make an informed decision as to what the attacker(s) are doing in the system.

I then checked to see what the attacker(s) did once they gained access which is the following; Attacker “S-1-5-32” gave themselves escalated privileges, executed “svchost.exe” in “System32” which may have contained a malware, and then created a path for themselves to regain access to the system via remote desktop via a created guest account “GuestAgent_2.7.41491.1225_2026-06-06_015419” which ran “WaAppAgent.exe”.

Attacker “S-1-5-21” also gave themselves escalated privileges, executed “WaAppAgent.exe, WmiPrvSE.exe and CompatTelRunner.exe” which led me to believe they we moving laterally in the system to retain access to it for potential future use. :

I then disabled the allow all inbound traffic rule on the Network Security group and made a deny all inbound and outbound traffic. Since there were no other VMs on the subnet to gain access to I did not have to revoke any accounts and ultimately deleted the machine after verifying that the other components of the Resource group were not compromised:

随后我重建并部署了该 VM，这次启用了适当的防火墙以及安全入站端口，以降低再次被成功入侵的可能性：

总结

2026年6月5日晚上 11:54:12.837，一个 VM 蜜罐账户被非管理员成功登录。经过网络安全团队的调查，很明显攻击者已成功获取了该蜜罐的访问权限。 识别： 经过事件管理团队的快速调查，可以看出该虚拟蜜罐至少被 2 个不同的用户访问过，他们之所以能够获取访问权限，是因为防火墙被禁用且网络安全规则配置不当。 保护： 为了保护并防范未来未经授权的登录，网络安全团队实施了一项新的防火墙规则，仅允许通过安全端口的传入流量，并配置了防火墙以保护计算机上的访问入口点。 检测： 为了检测新的和类似的未授权计算机登录行为，并提高检测这些威胁的能力，安全团队将安装网络监控软件，根据事件时间、登录时间、源 IP 地址与已知标准登录时间及源 IP 地址的对比，来检测异常的流量模式。 响应： 事件管理团队通过阻止传入和传出的网络流量做出响应，以确保没有其他人能够获得系统的访问权限，从而控制问题并开始识别根本原因。根本原因被确定为一条允许所有入站流量通过 Network Security group 的流量规则。在确认 Resource group 的其他组件未被攻破后，该虚拟机以及与该机关联的用户已被删除。 恢复： 在禁用所有入站和出站流量后，漏洞已被修复。该虚拟机已通过适当的防火墙和网络安全权限重新启动。为了确保在非蜜罐环境中不再发生类似事件，安全团队将通过监控和“安全实践”培训来确保网络的安全。

标签：Microsoft Azure, NIST标准, 安全运营, 底层分析, 扫描框架, 蜜罐, 证书利用