Exploring Security Monitoring with Microsoft Sentinel

Introduction

In this post, I’ll be sharing a recent project where I leveraged Microsoft Sentinel to enhance security monitoring for a virtual machine (VM) with an open Remote Desktop Protocol (RDP) port. This project involved setting up a VM, configuring it to send Windows event logs to Sentinel, and creating custom rules and configurations to detect and respond to potential security threats. Although this wasn’t my first time working with a Security Information and Event Management (SIEM) solution—I’ve previously implemented Splunk with Snort log ingestion in VMware—I found Microsoft Sentinel much easier to work with, especially within Microsoft's cloud infrastructure.

Project Overview

The primary objective of this project was to explore how Microsoft Sentinel, a cloud-native SIEM solution, can be used to effectively monitor and protect a machine exposed to potential security threats. To simulate a real-world scenario, I intentionally left an open RDP port on the VM.

1. Setting Up the Virtual Machine

To start, I deployed a Windows-based VM in Azure with an open RDP port. This setup mimicked a scenario where an exposed endpoint could be targeted by malicious actors, making it an ideal candidate for security monitoring using Sentinel.

2. Configuring Data Connection to Microsoft Sentinel

Once the VM was running, the next step was to establish a data connection between the VM and Microsoft Sentinel. This was achieved by:

• Installing the Azure Monitor Agent: This agent was installed on the VM to collect telemetry data, including Windows event logs.
• Creating a Log Analytics Workspace: The workspace served as a central repository where the event logs collected by the Azure Monitor Agent were stored.
• Connecting the VM to the Workspace: This involved linking the VM to the Log Analytics Workspace to ensure all event logs were forwarded to Sentinel.

3. Importing Windows Event Logs

With the data connection established, Windows event logs from the VM began streaming into Microsoft Sentinel. These logs included crucial information such as user logins, failed login attempts, and other security-related events, providing a comprehensive view of activities on the VM.
I also used RDP to gain access to the machine to ensure that Sentinel was logging this activity.

4. Creating Custom Detection Rules and Configurations

To transform the raw data into actionable insights, I created several custom rules within Sentinel. These rules were specifically tailored to detect suspicious activities that might indicate an attempt to compromise the VM via the open RDP port.

Custom Rule 1: Brute Force Attack Detection

Query:

SecurityEvent
| where EventID == 4625 // failed login attempt eventID
| summarize FailedAttempts = count() by IPAddress, Account, bin(TimeGenerated, 5m)
| where FailedAttempts > 5
| order by FailedAttempts desc  

What This Rule Does: This rule monitors for multiple failed login attempts (EventID 4625) from the same IP address within a 5-minute window. If there are more than five failed attempts, it triggers an alert.

Why This Rule: It helps in detecting brute force attacks, where an attacker tries to guess a user’s password by systematically attempting various combinations. Given the open RDP port and weak password, this rule is crucial for identifying such attack patterns.

Detections:
After running my environment for 15 minutes, I collected tens of thousands of failed login attempts. While I had setup my virtual environment with a weak password, the administrator account on the box was named scaredandalone (a non-standard name). From the logs I collected, it seems the attackers were using standardized wordlists and attacking any public ip address with open RDP ports.

As we can see from these logs, the username enumeration seems to follow pretty standard naming conventions (such as ADMIN, ADMINISTRATOR, USER and common names such as ANGELOV, NELSON, etc).

Custom Rule 2: Account Lockout Detection

Query:

SecurityEvent
| where EventID == 4740 // account lockout eventID
| project TimeGenerated, Account, IPAddress

What This Rule Does: This rule monitors for account lockout events (EventID 4740). These events occur when an account is locked due to multiple failed login attempts.

Why This Rule: Account lockouts often signal a brute force attack or a legitimate user forgetting their password. Monitoring these events can help in quickly identifying potential security threats and taking corrective actions.

Custom Rule 3: Successful Login with Specific Conditions

Query:

SecurityEvent
| where EventID == 4624 // successful login eventID
| where Account !contains "system" // exclude system accounts
| where Activity contains "success"

What This Rule Does: This rule detects successful login attempts (EventID 4624) that are not associated with system accounts. It filters logins based on specific activities that indicate potential misuse or unusual behavior.

Why This Rule: System accounts are created and used by the operating system to run certain system services and processes. By excluding system accounts and focusing on user logins, this rule helps identify unauthorized access, especially when a weak password is in place. Detecting non-system user logins from unexpected sources can signal compromised credentials or malicious activities.

Detections:

These alerts are from my own testing, connecting to the VM via RDP. If a malicious actor gains access through the "scaredandalone" account, they could execute commands, install malware, or steal sensitive data. It’s crucial to monitor such alerts closely, investigate them promptly, and implement security measures.

Key Learnings

Through this project, I gained valuable insights into the capabilities of Microsoft Sentinel as a comprehensive SIEM solution. Some of the key takeaways include:

• Ease of Integration: Connecting a VM to Microsoft Sentinel was straightforward, thanks to the seamless integration with Azure services and the flexibility of Log Analytics.
• Powerful Detection Capabilities: Custom detection rules in Sentinel can be highly effective in identifying and alerting on potential security incidents.
• Automated Response: Automating responses to specific alerts can significantly reduce the time to remediate potential threats, enhancing the overall security posture.

Conclusion

This project demonstrated the effectiveness of Microsoft Sentinel in monitoring and securing a VM with an open RDP port. By importing Windows event logs, creating custom rules, and automating responses, I was able to build a robust security monitoring solution that can proactively detect and mitigate potential threats. As organizations continue to face evolving security challenges, leveraging tools like Microsoft Sentinel can play a critical role in safeguarding their digital assets.