--- title: Detecting Atlassian confluence remote code execution vulnerability (CVE-2022-26134) in guardsix description: 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 h --- [Guardsix Blog | Cybersecurity Research & Threat Intelligence ](https://guardsix.com/blog) # [Detecting Atlassian confluence remote code execution vulnerability (CVE-2022-26134) in guardsix](https://guardsix.com/blog/detecting-atlassian-confluence-remote-code-execution-vulnerability-cve-2022-26134-in-guardsix) Written by [Guardsix](https://guardsix.com/blog/author/guardsix) | Jun 7, 2022 10:00:00 PM *by Bhabesh Raj Rai, Security Research* On June 2, 2022, Atlassian released a [security advisory](https://confluence.atlassian.com/doc/confluence-security-advisory-2022-06-02-1130377146.html) for a critical zero-day vulnerability ([CVE-2022-26134](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-26134)) that [hackers are exploiting](https://www.bleepingcomputer.com/news/security/critical-atlassian-confluence-zero-day-actively-used-in-attacks/) 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](https://ognl.orphan.software/language-guide.html) 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](https://www.volexity.com/blog/2022/06/02/zero-day-exploitation-of-atlassian-confluence/) 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](https://github.com/Freakboy/Behinder) implant and backup web shells on the Confluence server. [Cloudflare has identified requests](https://blog.cloudflare.com/cloudflare-observations-of-confluence-zero-day-cve-2022-26134/) 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](https://nvd.nist.gov/vuln/detail/cve-2022-26134) and [PoCs](https://github.com/jbaines-r7/through_the_wire) 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 guardsix’s [Use Case v5.1.2](https://servicedesk.guardsix.com/hc/en-us/articles/115004631405) 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 guardsix The first thing analysts can do is to perform an IoC sweep using indicators provided by [Volexity](https://github.com/volexity/threat-intel/blob/main/2022/2022-06-02%20Active%20Exploitation%20Of%20Confluence%200-day/indicators/indicators.csv), [GreyNoise](https://viz.greynoise.io/tag/atlassian-confluence-server-cve-2022-26134-ognl-injection-attempt?days=10), 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](https://confluence.atlassian.com/doc/configure-access-logs-1044780567.html) 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](https://github.com/Sysinternals/SysmonForLinux) 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](https://docs.oracle.com/javase/10/nashorn/introduction.htm#JSNUG136) 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](https://twitter.com/httpvoid0x2f/status/1532924261035384832) 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 guardsix SOAR playbooks Upon detecting traces of exploitation, analysts should isolate the Confluence instance and initiate their incident response procedure. *Block IP template in guardsix SOAR* *Isolate Host playbook in guardsix 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. [View full post](https://guardsix.com/blog/detecting-atlassian-confluence-remote-code-execution-vulnerability-cve-2022-26134-in-guardsix) ```json { "@context" : "http://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Guardsix" }, "dateModified" : "2026-05-06T09:59:05.875Z", "datePublished" : "2022-06-07T22:00:00Z", "headline" : "Detecting Atlassian confluence remote code execution vulnerability (CVE-2022-26134) in guardsix", "image" : { "@type" : "ImageObject", "height" : 1365, "url" : "https://logpoint.com/hubfs/Imported_Blog_Media/detecting-atlassian-confluence-remote-code-execution-vulnerability-blog-visual-4-1-2.jpg", "width" : 2048 }, "mainEntityOfPage" : "https://guardsix.com/blog/detecting-atlassian-confluence-remote-code-execution-vulnerability-cve-2022-26134-in-guardsix", "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "height" : 60, "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png", "width" : 60 }, "name" : "Guardsix blog" } } ```