Stealth Bomber: Atlassian Confluence Exploits Drop Web Shells In-Memory

Fresh proof-of-concept (PoC) exploits are circulating in the wild for a widely targeted Atlassian Confluence Data Center and Confluence Server flaw. The new attack vectors could enable a malicious actor to stealthily execute arbitrary code within Confluence's memory without touching the file system.

Researchers at VulnCheck have been tracking the exploits for the CVE-2023-22527 remote code execution (RCE) vulnerability, which was disclosed in January. The CVE has since become "hotbed of malicious activity" they noted, with VulnCheck currently tracking 30 unique in-the-wild exploits for the vulnerability, including the more recent options.

Most of the attacks against Confluence load the "infamous" Godzilla Web shell. Godzilla allows attackers to remotely control the compromised server, execute arbitrary commands, upload and download files, manipulate databases, and perform other malicious activities.

A new approach, though, is using an in-memory payload. After spotting the in-the-wild PoCs using that technique, VulnCheck researchers developed three PoCs of their own to probe the in-memory approach's limits.

The flurry of activity should surprise no one: VulnCheck CTO Jacob Baines says he thinks attackers love to target Confluence because of the wealth of business information available within in application, which makes it a "good pivot" into an internal network.

"By exploiting this target, you're getting an on-prem version with business specific logic in it," he says. "It's pretty attractive for ransomware attackers specifically."

In-Memory Web Shells for Atlassian Confluence Exploits

As VulnCheck's blog post details, "There's more than one way to reach Rome. More stealthy paths generate different indicators. Of particular interest is the in-memory Web shell, which had a pre-existing variant … that appears to have been deployed in the wild."

Baines explains that one of the firm's PoCs details the basic first step of loading arbitrary Java into memory, a popular exploit approach but one that is easily discovered with endpoint detection.

"This is a very obvious, easy-to-catch method to exploit Confluence," he says. "But loading arbitrary Java into memory is useful to know how to do, because the next step, the Web shell portion, builds on that."

VulnCheck's other two proofs of concept for CVE-2023-22527 in Confluence detail how malicious actors could exploit the Confluence vulnerability by loading an in-memory Web shell directly to gain unauthorized access to Web servers.

Loading into and executing code from Confluence’s memory is a much more stealthy and weaponized approach to attacking Confluence that is less likely to be detected by defenders, Baines says.

"A lot of systems only detect adversaries on the system by analyzing files that are dropped to disk," he says, adding that there's no great way to scan Java in memory for Web shells because of the way it's structured — the real solution lies in detecting it on the network.

"That has its own challenges, as everything's encrypted and you have to deploy certificates to the clients," he says. "The long-term answer is getting everything off of the Internet that you can."

Baines points out Confluence has now had multiple different CVEs on VulCheck's Known Exploited Vulnerabilities (KEV) list.

"It's definitely time to start putting that behind a VPN," he says. "Ultimately, attack surface management is the way to help mitigate these more advanced issues."

OGNL Risk Not Limited to Confluence

Baines says the risk of compromise is extremely high for organizations who have still not patched Confluence, given the mass-exploitation efforts underway.

"We see attackers have used this in-memory Web shell — it's not a theoretical attack," he says. "It's something that's happening, so defenders need to be aware of it, and that it is a high risk at the moment."

Baines adds that the risk from the in-memory approach is not just limited to Confluence, as it is related to Object-Graph Navigation Language (OGNL) expressions, which allow developers to perform various operations on Java objects using a simple, concise syntax.

"This affects a variety of different products with similar vulnerabilities — you could use this exact same technique against those other products," he says. "Organizations must evolve a step to start catching this sort of thing for example network-based detection or scanning Java memory for malicious Web shells."