Splunk is committed to using inclusive and unbiased language. This blog post might contain terminology that we no longer use. For more information on our updated terminology and our stance on biased language, please visit our blog post. We appreciate your understanding as we work towards making our community more inclusive for everyone.

If you want just to see how to find evidence of the Atlassian vulnerability in your Confluence systems, skip down to the “detections” sections. Otherwise, read on for a quick breakdown of what happened, how to detect it, and MITRE ATT&CK mappings.

Introduction to CVE-2022-26134

On June 2, security researchers at Volexity published a blog outlining the discovery of an unauthenticated remote code execution zero day vulnerability (CVE-2022-26134) being actively exploited in Atlassian Confluence Server and Data Center instances in the wild. Atlassian released a fix within 24 hours of the blog’s release. 

If you maintain any version of Confluence Server and Data Center software, assume it is vulnerable as it's likely that all versions, supported or not, are affected. For more accurate information, visit Atlassian’s online resources. 

Due to limited information about the exploit, organizations with vulnerable Confluence Server and Data Center instances will need to search for indicators of an attack already underway, such as malicious class files and webshells. This blog outlines these indicators along with relevant threat hunting searches using Splunk.

Why should you care? Because there are many many exposed Atlassian servers on the Internet. Sometimes they are from mergers and acquisitions and sometimes they are just leftover and still under someone's desk. Using shodan.io and looking for the favicon hash “-305179312”, there are possibly 8,320 exposed systems that exist today. That figure doesn’t account for lateral movement in networks that have already been compromised. 

What You Need to Know

Atlassian describes the vulnerability as an Object-Graph Navigation Language (OGNL) injection allowing an unauthenticated user to execute arbitrary code on a Confluence Server or Data Server instance. Volexity did not release proof-of-concept (POC) exploit code, but researchers there have observed coordinated, widespread exploitation.

Volexity first discovered the vulnerability over the weekend on two Internet-facing web servers running Confluence Server software. The investigation was due to suspicious activity on the hosts, including JSP webshells that were written to disk. 

If you are unable to patch Confluence right away (which you should), Atlassian has offered a temporary workaround to mitigate the issue by manually updating specific files for each product version. These updates will need to be applied to all nodes in a cluster. 

Before we dive in, a reminder that the Atlassian patch will not remove webshells dropped by attackers. For potentially affected instances, you may need to take additional steps according to your incident response plan. And hey, if you need help finding those attackers, Splunk ES Content Update (ESCU) has your back, or check out our 20+ blog series on hunting with Splunk.

Our research into the current vulnerability leads us to believe that it may be related to a previous Confluence RCE recorded as CVE-2021-26084, which featured a very similar exploit method.

Detecting Exploitation Attempts in Splunk

Here we will provide some hot-off-the-press searches to help find some of the techniques and access attempts derived from Volexity’s and Rapid7’s research in this area. If we have coverage for these searches in Splunk security content, we call them out further below in the MITRE ATT&CK section.

As previously mentioned, please note that Volexity’s proof-of-concept for CVE-2022-26134 has not been publicly released. As such, the hunting searches below are all derived from publicly available research and Rapid7’s blog and possible POC code.

Indicators of Compromise (IOCs)

Volexity published IP-based IOCs in their blog post. We have converted these indicators into CSV format so that you may use them as lookup tables - they are posted here. But what’s a lookup table, and how does it help with security detection in Splunk? Got you covered there, too.

Also, even though Volexity wrote up some great guidance of post exploitation activity that they saw in their investigations, we chose not to include those indicators in our blog. Because this vulnerability is extremely easy to exploit and is also widely available, specific post exploitation activity will vary.

Hunting for Exploitation in Confluence Access Logs

Confluence Access Logs use Apache Tomcat’s format with the specific pattern documented. The sample provided by Rapid7 matches that format. Unfortunately, this is not a default Apache Tomcat log format, so you might not have CIM-mapped data from our Tomcat TA. 

This exploit works by including a Java expression inside the URI of an HTTP request, which is then executed on the server. In our testing, we were able to exploit the vulnerability by fetching the following URL:

https://server.host.name/%24%7B%40java.lang.Runtime%40getRuntime%28%29.exec%28%22touch%20/tmp/evil%22%29%7D/

The URI portion of this decodes to:

${@java.lang.Runtime@getRuntime().exec("touch /tmp/evil")}

The expression inside the ${} is highly variable, and will depend on the specific threat actor and their goals. Any script code found inside the ${} is highly suspicious. Since the ${} string is the piece that actually triggers the expression to be run on the server, searching for this in your Confluence server access logs is a good way to find exploit attempts. However, your access logs are likely to have it in the URL encoded format “%24%7B”, so this is the string you’d actually search for. 

Note that this screenshot shows that we were able to replicate the exploit with several common HTTP methods (GET, POST, HEAD, and OPTIONS). Other HTTP methods are also likely to be exploitable, though we only tested these.

Also, in our testing, we saw a fairly substantial number of non-malicious URIs that included the ${ string. You may need to do additional filtering to narrow results down to only the true-positive events. 

Detecting Exploitation Attempts via Web Traffic

You may not have access to Confluence Access Logs but do have access to network traffic analyzers or web traffic logs. Consider looking for the same indicators listed above in these logs too. Any data source that provides visibility into the details of HTTP transactions will work. An example of this in practice would be reviewing Corelight (Zeek) data. In this data, Zeek logs the decoded version of the exploit string, so it’s easier to see what’s going on here. An example search leveraging the destination IP address of the Confluence host follows.

sourcetype=corelight_http dest_ip=10.1.10.159 uri="/${*"

Splunk Enterprise Security and ESCU

Know Thyself

While we have spent some time explaining indicators of this attack, it is also important to note that the basics are important. Basic asset management, hopefully via your asset and identity framework, will tell you where your vulnerable systems reside. Running regular vulnerability scans that integrate into Splunk will display which systems are vulnerable and can help you prioritize your patching schedule and better focus your detection efforts.

Threat Intelligence Framework

If you are using Splunk Enterprise Security, the lookups of IOCs that are listed above can be ingested easily into the threat intelligence framework. Perhaps you aren’t sure how to do that. No worries, we published some guidance and a how-to on integrating lists of IOCs into the Enterprise Security threat intelligence framework.

Enterprise Security Content Updates (ESCU)

As always, these rapid response blogs are full of Splunkspiration and designed to get you the first 30 yards down the incident response field. For folks using ESCU, our Security Research team will release a new Splunk Analytic Story very soon containing detections for this threat. Saying that, check out the MITRE ATT&CK table below. If you have ESCU running today, you already have some great coverage!

Splunk Services

Our team of Security Professionals, that are part of our Splunk Professional Services team, can help you to implement everything we’ve mentioned here. We also have more targeted offerings which can help you increase your security posture as well. 

Splunk Services for Breach Response and Readiness

This is all about Splunk helping you to prepare for a breach and how to respond using our suite of products. Let our experts come and help you prepare for a breach:

• Rapid data source identification and onboarding
• How to incorporate and use threat intelligence
• Prebuilt content with searches and dashboards to facilitate faster investigation and remediation
• Tactical response planning
• Tabletop exercise to validate how you respond using the Splunk products you have

MITRE ATT&CK

Reviewing the blog posts from Volexity and others, we mapped the adversary’s activity to MITRE ATT&CK. Each tactic is then linked to Splunk Content to help you hunt for that information. Be aware these searches are provided as a way to accelerate your hunting. We recommend you configure them via the Splunk Security Essentials App. You may need to modify them to work in your environment! Many of these searches are optimized for use with the tstats command. As always, these may not be directly applicable and the Splunk Threat Research Team will be releasing targeted content shortly!

Finally, as more information becomes available, we will update these searches if more ATT&CK TTPs become known.

Conclusion

The Splunk searches in this blog can help provide more visibility into your environment including malicious activity and indicators of compromise. Additionally, the Splunk Threat Research Team is working to deliver higher fidelity detections in releases through Enterprise Security Content Updates. In the meantime, organizations affected by CVE-2022-26134 should patch ASAP or apply the temporary workaround if patching right away is not possible. If you are unable to mitigate the vulnerability, be sure to either isolate or disable affected servers. As a best practice, organizations should consider moving Internet-exposed Confluence servers behind a VPN and never running the Confluence software as root. IP safelisting and WAF protection can also help guard against this threat. This is a rapidly changing event, so we will be keeping a close eye. Until then, happy hunting!

Authors and Contributors: As always, security at Splunk is a family business. Credit to authors and collaborators: Audra Streemtan, David Bianco, Tamara Chacon, Drew Church, Ryan Kovar, Marcus LaFerrerra, Casey Wopat, Greg Warner, Jonathan Heckinger, Todd Miller, Tony Iacobelli