Detect and investigate activities–such as unusually long
Content-Type length, suspicious java classes and web servers executing suspicious processes–consistent with attempts to exploit Apache Struts vulnerabilities.
- Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud
- Datamodel: Endpoint
- Last Updated: 2018-12-06
- Author: Rico Valdez, Splunk
- ID: 2dcfd6a2-e7d2-4873-b6ba-adaf819d2a1e
In March of 2017, a remote code-execution vulnerability in the Jakarta Multipart parser in Apache Struts, a widely used open-source framework for creating Java web applications, was disclosed and assigned to CVE-2017-5638. About two months later, hackers exploited the flaw to carry out the world’s <a href=https://www.usatoday.com/story/tech/2017/09/07/nations-biggest-hacks-and-data-breaches-millions/644311001/> 5th largest data breach</a>. The target, credit giant Equifax, <a href=https://money.cnn.com/2017/09/16/technology/equifax-breach-security-hole/index.html>told investigators</a> that it had become aware of the vulnerability two months before the attack.
The exploit involved manipulating the
Content-Type HTTP header to execute commands embedded in the header.
This Analytic Story contains two different searches that help to identify activity that may be related to this issue. The first search looks for characteristics of the
Content-Type header consistent with attempts to exploit the vulnerability. This should be a relatively pertinent indicator, as the
Content-Type header is generally consistent and does not have a large degree of variation.
The second search looks for the execution of various commands typically entered on the command shell when an attacker first lands on a system. These commands are not generally executed on web servers during the course of day-to-day operation, but they may be used when the system is undergoing maintenance or troubleshooting.
First, it is helpful is to understand how often the notable event is generated, as well as the commonalities in some of these events. This may help determine whether this is a common occurrence that is of a lesser concern or a rare event that may require more extensive investigation. It can also help to understand whether the issue is restricted to a single user or system or is broader in scope.
When looking at the target of the behavior illustrated by the event, you should note the sensitivity of the user and or/system to help determine the potential impact. It is also helpful to see what other events involving the target have occurred in the recent past. This can help tie different events together and give further situational awareness regarding the target.
Various types of information for external systems should be reviewed and (potentially) collected if the incident is, indeed, judged to be malicious. Information like this can be useful in generating your own threat intelligence to create alerts in the future.
Looking at the country, responsible party, and fully qualified domain names associated with the external IP address–as well as the registration information associated with those domain names, if they are frequently visited by others–can help you answer the question of “who,” in regard to the external system. Answering that can help qualify the event and may serve useful for tracking. In addition, there are various sources that can provide some reputation information on the IP address or domain name, which can assist in determining if the event is malicious in nature. Finally, determining whether or not there are other events associated with the IP address may help connect some dots or show other events that should be brought into scope.
Gathering various data elements on the system of interest can sometimes help quickly determine that something suspicious may be happening. Some of these items include determining who else may have recently logged into the system, whether any unusual scheduled tasks exist, whether the system is communicating on suspicious ports, whether there are modifications to sensitive registry keys, and whether there are any known vulnerabilities on the system. This information can often highlight other activity commonly seen in attack scenarios or give more information about how the system may have been targeted.
hen a specific service or application is targeted, it is often helpful to know the associated version to help determine whether or not it is vulnerable to a specific exploit.
hen it is suspected there is an attack targeting a web server, it is helpful to look at some of the behavior of the web service to see if there is evidence that the service has been compromised. Some indications of this might be network connections to external resources, the web service spawning child processes that are not associated with typical behavior, and whether the service wrote any files that might be malicious in nature.
In the event that a suspicious file is found, we can review more information about it to help determine if it is, in fact, malicious. Identifying the file type, any processes that have the file open, what processes created and/or modified the file, and the number of systems that may have this file can help to determine if the file is malicious. Also, determining the file hash and checking it against reputation sources, such as VirusTotal, can sometimes quickly help determine whether it is malicious in nature.
Often, a simple inspection of a suspect process name and path can tell you if the system has been compromised. For example, if
svchost.exe is found running from a location other than
C:\Windows\System32, it is likely something malicious designed to hide in plain sight when simply reviewing process names. Similarly, if the process itself seems legitimate, but the parent process is running from the temporary browser cache, there may be activity initiated via a compromised website the user visited.
It can also be very helpful to examine various behaviors of the process of interest or the parent of the process that is of interest. For example, if it turns out that the process of interest is malicious, it would be good to see if the parent to that process spawned other processes that might also be worth further scrutiny. If a process is suspect, reviewing the network connections made around the time of the event and/or if the process spawned any child processes could be helpful in determining whether it is malicious or executing a malicious script.
|Suspicious Java Classes||Anomaly|
|Unusually Long Content-Type Length||Anomaly|
|Web Servers Executing Suspicious Processes||System Information Discovery||TTP|
source | version: 1