by Bhabesh Raj Rai, Security Research
On June 2, 2022, Atlassian released a security advisory for a critical zero-day vulnerability (CVE-2022-26134) that hackers are exploiting in Confluence Server and Data Center. The flaw allows an unauthenticated attacker to execute arbitrary code on a vulnerable Confluence Server or Data Center instance.
The advisory stated that all supported versions of Confluence Server and Data Center are affected. Atlassian provided patches a day after the advisory was released and advised all customers to upgrade their instances to any of the fixed versions — 7.4.17, 7.13.7, 7.14.3, 7.15.2, 7.16.4, 7.17.4, and 7.18.1.
Essentially, the zero-day is an OGNL injection flaw that allows an unauthenticated user to execute arbitrary code in the context of the Confluence application. OGNL payloads can be injected into the URI or payload of HTTP requests. To get back the command outputs, attackers use dummy headers (X-Cmd-Response being the most common one) to house the outputs that will be returned in the HTTP response.
Volexity, a Washington-based cybersecurity firm, discovered the flaw during an IR investigation they had conducted over the Memorial Day weekend. Volexity observed attackers using the zero-day to deploy an in-memory copy of the BEHINDER implant and backup web shells on the Confluence server.
Cloudflare has identified requests matching potentially malicious payloads as early as May 26, indicating that attackers had knowledge of the zero-day prior to the Atlassian security advisory. They observed a large spike in activity starting from June 3 likely due to the release of details and PoCs of the vulnerability.
If you are unable to upgrade Confluence immediately, then Atlassian has included temporary workarounds in their advisory. Atlassian also stated that Confluence end-of-life versions are not fully tested with the workaround, so they strongly recommend upgrading to a fixed version of Confluence as there are several other security fixes included.
Customers can use Logpoint’s Use Case v5.1.2 application that includes alerts related to detecting CVE-2022-26134 exploitation.
CVE-2022-26134 fast facts
- Exploited in the wild since May 2022
- Affects all supported versions of Confluence Server and Data Center
- Mass scanning and exploitation have already commenced
- Several PoCs are public
Log sources needed
- Confluence access logs
- DNS
- Firewall
- Confluences running in Linux
- Sysmon for Linux
- Auditd
- Confluences running in Windows
- Native event logs
- Sysmon
Detection of exploitation in Logpoint
The first thing analysts can do is to perform an IoC sweep using indicators provided by Volexity, GreyNoise, etc.
(source_address IN CVE_2022_26134_IPS OR destination_address IN CVE_2022_26134_IPS)
Geolocation distribution of source IP hit
Confluence access logging records the OGNL payloads, but it is not enabled by default. Administrators should ensure that they have enabled it because when enabled, confluence logs every request made to the site. The log file is located in /logs/conf_access_log.log.
(url=* OR resource=*) request_method=*
| process eval("decoded_resource=urldecode(resource)")
| process eval("decoded_url=urldecode(url)")
| rename decoded_resource as resource, decoded_url as url
| search ( resource IN [ "*${*", "*getRuntime().exec(*", "*X-Cmd-Response*"]
OR url IN [ "*${*", "*getRuntime().exec(*", "*X-Cmd-Response*"] )
Confluence access logging shows OGNL payloads
If your Confluence instance is running on Windows, look for the tomcat process spawning suspicious processes.
label="Process" label=Create
parent_process IN ["*\tomcat8.exe", "*\tomcat9.exe"]
"process" IN ["*\whoami.exe", "*\systeminfo.exe", "*\ipconfig.exe", "*\cmd.exe", "*\powershell.exe", "*\wget.exe", "*\curl.exe", "*\nslookup.exe"]
-command="cmd.exe /c set"
| chart count() by host, parent_process, "process", command
Searching for tomcat process spawning suspicious child processes
If your Confluence instance is running on Linux and has Sysmon for Linux installed, look for the confluence user spawning suspicious processes. In our test, Sysmon for Linux didn’t capture the parent process name (java), so we have to rely either on the user or path field.
norm_id=UnixSysmon label="Process" label=Create
(user="confluence" OR path="*/Atlassian/Confluence/bin")
image IN ["/usr/bin/uname", "/usr/bin/whoami", "/usr/bin/hostname", "/usr/bin/ip", "/usr/bin/id", "/usr/bin/wget", "/usr/bin/curl", "/usr/bin/ss", "/usr/sbin/iptables", "/usr/bin/bash", "/usr/bin/sh"]
| chart count() by user, host, path, image, command
Searching for the confluence user spawning suspicious processes in Sysmon for Linux events
Alternatively, attackers can use the Nashorn Java class to create reverse shells for direct interactions.
(url="*%24%7B*" OR resource="*%24%7B*")
| process eval("decoded_resource=urldecode(resource)")
| process eval("decoded_url=urldecode(url)")
| rename decoded_resource as resource, decoded_url as url
| search ( resource IN [ "*${*ScriptEngineManager()*", "*${*javax.*nashorn*", "*${*.eval(*ProcessBuilder()*" ]
OR url IN [ "*${*ScriptEngineManager()*", "*${*javax.*nashorn*", "*${*.eval(*ProcessBuilder()*" ] )
Searching for use of the Nashorn java class
Analysts can hunt for reverse shell artifacts using process creation events.
label="Process" label=Create
command IN ["*/dev/tcp/*", "*bash -i >&*"]
| chart count() by log_ts, user, image, command
Searching for reverse shell creations in Sysmon for Linux events
If you do not have Sysmon for Linux monitoring, analysts can use rely on auditd events.
norm_id=Unix "process"=audit event_type=SYSCALL
command IN ["hostname", "id", "whoami", "curl", "wget", "uname", "ss", "ip", "sh", "bash"]
| chart count() by host, command
Searching for suspicious process executions in auditd events
Proctitle events capture the full command lines of process executions. Monitor your Confluence instances for suspicious command lines that it normally does not execute.
norm_id=Unix "process"=audit event_type=PROCTITLE host IN CONFLUENCE_HOSTS
| chart count() by host, command
Search for suspicious command lines in auditd’s proctitle events
Attackers commonly use external sites like Interactsh for identifying vulnerable systems through out-of-band interactions. Investigate systems that are behind these DNS queries.
label=DNS label=Query (query IN ['*.interact.sh', '*.oast.pro', '*.oast.live', '*.oast.site', '*.oast.online', '*.oast.fun', '*.oast.me', '*.burpcollaborator.net', '*.oastify.com', '*.canarytokens.com', '*.requestbin.net', '*.dnslog.cn']
OR domain IN ['*interact.sh', '*oast.pro', '*oast.live', '*oast.site', '*oast.online', '*oast.fun', '*oast.me', '*burpcollaborator.net', '*oastify.com', '*canarytokens.com', '*requestbin.net', '*dnslog.cn'] )
Searching for DNS queries to Interactsh-type sites in Sysmon DNS events
This vulnerability also allows attackers to easily add a new administrator user to the confluence site by using getUserAccessor().addUser() method in the OGNL payload.
(url=* OR resource=*) request_method=*
| process eval("decoded_resource=urldecode(resource)")
| process eval("decoded_url=urldecode(url)")
| rename decoded_resource as resource, decoded_url as url
| search ( resource IN [ "*${*addUser(*"] OR url IN [ "*${*addUser(*"] )
| chart count() by log_ts, user, source_address, resource, user_agent
Searching for new user creations artifacts
Administrators can verify this by looking for new user creations (especially admins) by the ‘Anonymous’ user in Confluence’s audit logs.
New admin user ‘newadmin’ created by the ‘Anonymous’ user
As mentioned earlier, Volexity observed attackers—after exploiting the zero-day—using the open-source BEHINDER web shell which replaced the legitimate noop.jsp file located at /confluence path. They also dropped another JSP version of the open-source Chopper webshell as a backup.
We advise analysts to monitor for HTTP requests to noop.jsp resource. We do not need any special queries to detect command executions through these web shells.
(resource="/noop.jsp" OR url="*/noop.jsp")
Search for requests to noop.jsp resource
Remediation with Logpoint SOAR playbooks
Upon detecting traces of exploitation, analysts should isolate the Confluence instance and initiate their incident response procedure.
Block IP template in Logpoint SOAR
Isolate Host playbook in Logpoint SOAR
Customers can run their SOAR playbooks to block IPs attempting to exploit or have been successful in exploiting the flaw.
Detecting post-compromise activity is key to detecting zero-day exploitations
We advise analysts to prioritize detecting post-compromise activity since it is trivial to bypass signature checks on URLs. Attackers can also exploit this vulnerability via payloads in POST data rendering detections based on URLs useless.
The current threat landscape has forced enterprise defenders to adopt the “assume breach” scenario and to proactively hunt for threats. Detecting zero-day exploitation is difficult, but there is an easy and feasible way. Defenders should look for common post-compromise activities and investigate them to find the root cause. They need to create a baseline so that any suspicious activity readily stands out among the noise.
