apache_struts_vulnerability.yml

name: Apache Struts Vulnerability
id: 2dcfd6a2-e7d2-4873-b6ba-adaf819d2a1e
version: 1
date: '2018-12-06'
author: Rico Valdez, Splunk
description: 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.
narrative: '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.'
references:
- https://github.com/SpiderLabs/owasp-modsecurity-crs/blob/v3.2/dev/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf
tags:
  category:
  - Vulnerability
  product:
  - Splunk Enterprise
  - Splunk Enterprise Security
  - Splunk Cloud
  usecase: Advanced Threat Detection