#AdventOfCyber Day 2: Log analysis | TryHackMe
Log analysis Day 2: One man's false positive is another man's potpourri.
Welcome to Day 2 of the #AdventOfCyber2024! Today's task, "One Man's False Positive is Another Man's Potpourri," focuses on analyzing alerts within a Security Information and Event Management (SIEM) system to distinguish between True Positives (TPs) and False Positives (FPs). You’ll step into the shoes of a SOC analyst to investigate unusual activity, decode suspicious commands, and determine whether an incident is malicious or benign.
True Positives or False Positives?
In a SOC, events from different devices are sent to the SIEM, which is the single source of truth where all the information and events are aggregated. Certain rules (Detection Engineering rules) are defined to identify malicious or suspicious activity from these events. If an event or set of events fulfils the conditions of a rule, it triggers an alert. A SOC analyst then analyses the alert to identify if the alert is a True Positive (TP) or a False Positive (FP). An alert is considered a TP if it contains actual malicious activity. On the flip side, if the alert triggers because of an activity that is not actually malicious, it is considered an FP. This might seem very simple in theory, but practically, separating TPs from FPs can be a tedious job. It can sometimes become very confusing to differentiate between an attacker and a system administrator.
Making a Decision
While it is confusing to differentiate between TPs and FPs, it is very crucial to get it right. If a TP is falsely classified as an FP, it can lead to a significant impact from a missed cyber attack. If an FP is falsely classified as a TP, precious time will be spent focusing on the FP, which might lead to less focus on an actual attack. So, how exactly do we ensure that we perform this crucial job effectively? We can use the below pointers to guide us.
Using the SOC Superpower
The SOC has a superpower. When they are unsure whether an activity is performed by a malicious actor or a legitimate user, they can just confirm with the user. This privilege is not available to the attacker. A SOC analyst, on the other hand, can just send an email or call the relevant person to get confirmation of a certain activity. In mature organisations, any changes that might trigger an alert in the SOC often require Change Requests to be created and approved through the IT change management process. Depending on the process, the SOC team can ask the users to share Change Request details for confirmation. Surely, if it is a legitimate and approved activity, it must have an approved Change Request.
Context
While it might seem like using the SOC superpower makes things super easy, that is not always the case. There are cases which can act as Kryptonite to the SOC superpower:
If an organisation doesn't have a change request process in place.
The performed activity was outside the scope of the change request or was different from that of the approved change request.
The activity triggered an alert, such as copying files to a certain location, uploading a file to some website, or a failed login to a system.
An insider threat performed an activity they are not authorised to perform, whether intentionally or unintentionally.
A user performed a malicious activity via social engineering from a threat actor.
In such scenarios, it is very important for the SOC analyst to understand the context of the activity and make a judgement call based on their analysis skills and security knowledge. While doing so, the analyst can look at the past behaviour of the user or the prevalence of a certain event or artefact throughout the organisation or a certain department. For example, if a certain user from the network team is using Wireshark, there is a chance that other users from the same team also use Wireshark. However, Wireshark seen on a machine belonging to someone from HR or finance should rightfully raise some eyebrows.
Correlation
When building the context, the analyst must correlate different events to make a story or a timeline. Correlation entails using the past and future events to recreate a timeline of events. When performing correlation, it is essential to note down certain important artefacts that can then be used to connect the dots. These essential artefacts can include IP addresses, machine names, usernames, hashes, file paths, etc.
Correlation requires a lot of hypothesis creation and ensuring that the evidence supports that hypothesis. A hypothesis can be something like the user downloaded malware from a spoofed domain. The evidence to support this can be proxy logs that support the hypothesis that a website was visited, the website used a spoofed domain name, and a certain file was downloaded from that website. Now, let's say, we want to identify whether the malware executed through some vulnerability in an application or a user intentionally executed the malware. To see that, we might look at the parent process of the malware and the command line parameters used to execute the said malware. If the parent process is Windows Explorer, we can assume the user executed the malware intentionally (or they might have been tricked into executing it via social engineering), but if the parent process is a web browser or a word processor, we can assume that the malware was not intentionally executed, but it was executed because of a vulnerability in the said application.
Is this a TP or an FP?
Similar to every SOC, the analysts in the Wareville SOC also need to differentiate TPs from FPs. This becomes especially difficult for them near Christmas when the analysts face alert fatigue. High chances of misclassification of TPs into FPs and vice versa are present in such times. The analysts, therefore, appreciate any help they could get from us in this crucial time. To make matters worse, the office of the Mayor has sent the analysts an alert informing them of multiple encoded powershell commands run on their systems. Perhaps we can help with that.
Task Overview
The Wareville SOC team has flagged multiple encoded PowerShell commands triggered by an admin account. Your mission is to:
Investigate the alerts and identify patterns.
Decode and analyze PowerShell commands.
Determine whether the incident represents malicious activity or something else.
Access Details
To begin, start the Elastic SIEM on the provided virtual machine. Use the following credentials to log in:
Username: elastic
Password: elastic
Navigate to the Discover tab to review the logs and follow the instructions outlined in the task.
Walkthrough
Set the Time Frame
Open the Elastic SIEM and click on the timeframe settings in the top-right corner.
Set the time window to December 1, 2024, between 09:00 and 09:30 using the "Absolute" tab.
Click Update to view events from this specific timeframe.
You should see 21 events in the logs. These logs need to be refined for better readability.
Add Relevant Fields
To analyze the logs effectively, add the following fields as columns:
host.hostname: Identifies the machine where commands were run.
user.name: Shows the account performing the activity.
event.category: Ensures the correct event type is examined.
process.command_line: Displays the executed PowerShell commands.
event.outcome: Indicates whether the action succeeded.
This reveals that the same encoded PowerShell command was executed on multiple machines, and successful authentication events preceded each execution.
Investigate Authentication Events
To trace the origin of these events:
Add the source.ip field as a column to identify the IP address associated with the authentication.
Filter for event.category: authentication to isolate authentication events.
Expand the timeframe to include logs from November 29 to December 1, 2024, to establish a timeline.
Identify Patterns
Investigate logs for the user service_admin and IP address 10.0.11.11.
Notice repeated failed login attempts and eventual successful logins.
Filter out irrelevant IPs to focus on unusual spikes in failed authentication events.
The failed logins stopped after a successful authentication event from IP 10.0.11.255.1, suggesting a brute-force attack.
Decode the PowerShell Command
Filter for event.category: process to isolate PowerShell execution events.
Locate the encoded command:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -EncodedCommand SQBuAHMAdABhAGwAbAAtAFcAaQBuAGQAbwB3AHMAVQBwAGQAYQB0AGUAIAAtAEEAYwBjAGUAcAB0AEEAbABsACAALQBBAHUAdABvAFIAZQBiAG8AbwB0AA==Decode the Base64-encoded command using CyberChef with the "FromBase64" and "Decode Text" recipes configured to UTF-16LE.
The decoded command is:
Install-WindowsUpdate -AcceptAll -AutoReboot
Interpret Findings
Analysis shows that Glitch, a benign actor, accessed the system to fix outdated credentials and execute the PowerShell command to install Windows updates. This was confirmed by correlating successful logins and PowerShell executions with Glitch's IP address.
Task Solutions
Question 1: What is the name of the account causing all the failed login attempts?
Answer: service_admin
Question 2: How many failed logon attempts were observed?
Answer: 6800
Question 3: What is the IP address of Glitch?
Answer: 10.0.11.11
Question 4: When did Glitch successfully logon to ADM-01?
Answer: Dec 1, 2024 09:27:15.123
Question 5: What is the decoded command executed by Glitch to fix the systems of Wareville?
Answer: Install-WindowsUpdate -AcceptAll -AutoReboot
This challenge highlights the importance of distinguishing between True Positives and False Positives in SOC operations. Glitch’s actions, initially flagged as suspicious, were ultimately revealed to be beneficial, showcasing the need for thorough analysis and contextual understanding in cybersecurity.
Want to improve your skills further? Explore the Investigating with ELK 101 room!