What Is SIEM Solution?

• A Security Information and Event Management (SIEM) solution acts as the central nervous system of an organization’s security framework. It collects, analyzes, and correlates data from various sources within the IT infrastructure, including network devices, servers, and security systems.

• By integrating a SIEM solution in a SOC, organizations can significantly enhance their ability to monitor, assess, and mitigate cybersecurity risks in real-time. The core capabilities are a broad scope of log event collection and management, the ability to analyze log events and other data across disparate sources, and operational capabilities.

• SIEM systems help enterprise security teams detect user behavior anomalies and use artificial intelligence to automate many of the manual processes associated with threat detection and Incident response.

How does SIEM work?

SIEM works by gathering and integrating data from various IT and security sources, facilitating comprehensive monitoring and analysis to enhance cybersecurity.

SIEM solutions use data aggregation and data normalization to provide an integrated view of all security events in a single platform. Users can detect threats in real-time and security analysts no longer need to waste time searching for all the notifications generated by different threat-hunting and monitoring components:

• Data Collection: SIEM solutions gather data from diverse sources such as end-user devices, servers, network equipment, security systems (firewalls, antivirus), and more. This data can be collected using agents deployed on devices or through protocols like syslog, SNMP, or WMI. Modern SIEM systems also integrate with cloud services and various threat intelligence feeds.

• Data Storage: SIEM stored data in the data center, often limiting the amount of data retained due to storage constraints. Modern SIEMs leverage scalable data lake technologies such as Amazon S3 or Hadoop, enabling the retention and analysis of large volumes of log data at a low cost. This allows for the storage and analysis of extensive log data across diverse platforms and systems.

• Policies and Rules: Security teams configure SIEM with profiles that define normal system behavior. Rules and thresholds are set to identify anomalies that may indicate a security incident. Advanced SIEM solutions utilize machine learning (ML) and automated behavioral profiling to autonomously detect anomalies and adapt rules based on evolving data patterns.

• Data Consolidation and Correlation: The core function of SIEM is to consolidate and correlate data across all organizational systems.

For example, an error message on a server might be correlated with a blocked connection on a firewall and multiple failed login attempts on an enterprise portal. These correlated data points are aggregated into meaningful security events, which are then presented to analysts through notifications or dashboards.

• Event Management: SIEM solutions help prioritize and manage security events by distinguishing between genuine threats and false alarms. Modern SIEMs employ advanced analytics to improve the accuracy of threat detection, reducing the time analysts spend on false positives.

Scenario: Batch Files and Malicious Payloads

Detection mechanisms will be set up to alert on the following: downloading batch files on unusual ports, PowerShell scripts being launched from batch files, batch files downloaded by PowerShell using the Invoke-WebRequest command, and command-line/PowerShell commands matching patterns found in malicious Metasploit payloads.

The dropper file includes the following PowerShell script. Essentially, it executes the Get-MPComputerStatus command, which provides a list of properties and their values (True, False, etc.). The script then checks if the RealTimeProtectionEnabled property (indicating Windows Defender status) is false. If this property is false, it executes the designated malicious payload script.

PowerShell -Command "& {if ((Get-MPComputerStatus).RealTimeProtectionEnabled -eq $false) {<MALICIOUS PAYLOAD SCRIPT>}}"

ALERT CONTEXT

We know that logs related to HTTP traffic and activities, such as file sharing or downloads, can be captured using Zeek (zeek.http). By running a general query, we can review the results and identify relevant information. Additionally, we should toggle fields with values that may provide context for file sharing, downloading, or file extensions. Some key questions to consider include:

• What is the HTTP method being used?

• What is the HTTP response code?

• What is the URL path associated with the file download?

• What is the IP address and port hosting the file?

To help answer these questions and provide context, we can toggle the following fields: event.action, http.response.code, url.path, url.extension, destination.ip, and destination.port.

event.dataset: zeek.http

There are several critical pieces of information we can observe. We know that file downloads will have an event.action of GET and a successful http.response.code of 200. Batch files may be unusual, so we should be on the lookout for url.extensions with the value bat. In case of extension obfuscation, we should also monitor for potential txt files. Most importantly, we need to determine if we are expecting any file transfers or downloads involving the specified destination.ip and destination.port values.

Files shared internally, even batch files, might be normal, especially among the IT team. This highlights the importance of Detection Engineers understanding their internal enterprise environment. One way to approach detection contextually is to whitelist specific IP addresses that are authorized to transmit files. We could also blacklist IP addresses known for using dropper file/sharing tactics, and alert on any unexpected IP addresses transmitting files.

Logs pertaining to PowerShell execution should be captured by Sysmon windows.sysmon_operational. We can run a general query and review any interesting results. Additionally, we should toggle fields with values that may provide relevant context related to PowerShell script execution. Key questions to consider include:

• What is the parent process name?

• What commands/scripts did the parent process execute?

• What commands/scripts did the child process execute?

• On which host machine is the unusual PowerShell execution observed?

To answer these questions and provide context, we can toggle the following fields: process.parent.name, process.parent.command_line, process.command_line, and host.hostname.

event.dataset: windows.sysmon_operational

The relevant results for our Alert Scenario have been reviewed. Tracing the sequence of events, we observe that a parent process cmd.exe executed the command line ..\..\testing.bat (our dropper file).

This dropper file then ran a PowerShell script to check if Windows Defender is disabled and, upon finding it disabled, saving it as shell.bat. The shell.bat file was subsequently executed by a parent process powershell.exe, which contained the PowerShell script to execute the reverse shell payload.

Based on this information, how should we approach detection? Although the dropper file testing.bat might be a known malicious file or previously observed in an incident, relying on this specific name for detection could lead to false negatives, as future attacks could simply use a different name for the dropper file.

Instead of focusing on specific filenames, we should adopt a more generalized approach based on observed patterns in our log results, such as the detection of a .bat file launching PowerShell. This broader strategy would capture relevant events regardless of file names, making it more comprehensive.

This generalized detection approach is more robust and less likely to miss future attacks that use different filenames or slight variations in techniques.

Detection Engineers need a thorough understanding of their internal enterprise environment. Employing a broad detection strategy to alert on PowerShell scripts initiated by batch files may result in numerous false positives, particularly since IT staff may commonly utilize batch files. While this project/course will accept a generalized approach for Alert Scenario, it is essential to carefully consider the potential impact of this strategy within a fully operational enterprise environment.

Therefore, while a generalized detection method is acceptable for the purposes of this project, in a real-world setting, it is crucial to balance the need for comprehensive detection with the risk of overwhelming the system with false positives. This balance can be achieved through techniques such as refining detection rules, whitelisting known good activities, and incorporating context-aware analysis to distinguish between legitimate and suspicious actions.

We can also develop a third detection method by targeting key strings in the malicious payload script responsible for executing the reverse shell. Although the script contains variable elements like the listening IP address and port, we can create a detection rule based on more fixed strings such as $c=New-Object system.net.sockets.tcpclient.

ALERT CONFIRMATION

After conducting the attack again, we observed that all four alerts were triggered and displayed in our Security Alerts Dashboard.

A great feature of Elastic Cloud is its ability to visually analyze alerts and event timelines. In this case, we’re expanding our Potential Metasploit PowerShell Payload Observed alert, allowing us to click on each node to access more details and visually track the overall flow of events.

You can imagine what a SIEM solution can provide for you in terms of scale detection and hunting for anomalies around your environment from a centralized place, this can make your life as a security analyst much more easier.

This blog is authored by Asem Ashraf.