In today's cybersecurity landscape, SIEM (Security Information and Event Management) systems play a critical role in detecting, investigating, and responding to threats. In this blog post, we will walk you through a detailed investigation using Elastic SIEM, covering everything from initial event discovery to identifying suspicious behavior. This real-world case study focuses on analyzing a potential breach and resolving the mystery behind it.
Setting Up the Elastic SIEM:
To get started, we'll first launch the Elastic SIEM in the virtual machine (VM). Follow these steps to set up the environment:
Start the Machine:
- Click the Start Machine button to initialize the Elastic SIEM instance. It will take about 5 minutes for the machine to be fully up and running.
Accessing the Elastic SIEM:
Once the machine is running, navigate to the following URL in your browser:
https://LAB_WEB_URL.p.thmlabs.comUse the following credentials to log in:
Username:
elasticPassword:
elastic
After logging in, click on the menu in the top-left corner and select the Discover tab to view the events.
The Investigation Unfolds:
On December 1st, 2024, the Mayor’s office alerted us to suspicious activity occurring between 0900 and 0930. We quickly adjusted the timeframe in Elastic SIEM to focus on that specific window and saw 21 events. To make the data more readable, we added columns for host.hostname, user.name, event.category, process.command_line, and event.outcome.
Spotting the Suspicious Pattern:
As we analyzed the events, we noticed that the same encoded PowerShell command had been executed across multiple machines. Each command was preceded by a successful login from a generic admin account—the same account (service_admin) that wasn’t used by the administrators who were supposedly away.
This raised a red flag. Could someone have gained unauthorized access?
Tracing the Source:
We added the source.ip field and filtered the data to focus on authentication events. Expanding the timeframe from November 29 to December 1 revealed over 6,800 events, with a spike in authentication attempts on December 1st. Filtering by user.name = service_admin and source.ip = 10.0.11.11 showed multiple failed login attempts, followed by a successful login and PowerShell execution. This pointed to a potential brute-force attack.
The Real Intent Behind the Activity:
Further investigation revealed that the attacker executed a command:
The command had been Base64-encoded, so we used CyberChef to decode it, confirming the update operation.
Install-WindowsUpdate -AcceptAll -AutoReboot
It was an encoded PowerShell command to run Windows updates, not an attack.
The Conclusion:
What seemed like an attack was actually Glitch, a security expert, fixing issues caused by expired credentials. Glitch had brute-forced their way in, updated the system, and secured it. However, the Mayor misunderstood the situation, thinking it was malicious.
This investigation underscores the importance of context—what initially appeared to be a true positive (TP) was actually a false positive (FP). In the end, Glitch wasn’t a villain, but a misunderstood hero.