Malware
Silent Intrusions: Godzilla Fileless Backdoors Targeting Atlassian Confluence
Trend Micro discovered that old Atlassian Confluence versions that were affected by CVE-2023-22527 are being exploited using a new in-memory fileless backdoor.
Save to Folio
Summary
- Trend Micro researchers identified a new attack vector that exploits the CVE-2023-22527 through the deployment of an in-memory fileless backdoor known as the Godzilla webshell. CVE-2023-22527 is a vulnerability affecting older versions of the Atlassian Confluence Data Center and Server that allows attackers to perform remote code execution.
- In such an attack, a loader is introduced into a compromised Atlassian server, subsequently activating the Godzilla webshell.
- Godzilla is a sophisticated Chinese-language backdoor that uses AES encryption for communication and remains in-memory to avoid disk-based detection mechanisms.
- Legacy anti-virus solutions struggle to detect fileless malware, so the discovery of this new kind of attack underscores the importance of regularly patching servers and using more advanced security solutions.
We observed a new attack vector of weaponization for the vulnerability CVE-2023-22527 using the Godzilla backdoor. Following initial exploitation, a loader was loaded into the Atlassian victim server which loads a Godzilla webshell. On January 16, 2024, Atlassian released a security advisory for CVE-2023-22527, a vulnerability that affects Confluence Data Center and Confluence Server products. In response to this, Trend Micro released its own technical analysis and coverage of the vulnerability, which has also been associated with crypto-mining activities.
The vulnerability is marked critical with a Common Vulnerability Scoring System (CVSS) score of 10. By exploiting this flaw, an unauthenticated attacker has the potential to exploit a template injection vulnerability found in older versions of Confluence Data Center and Server, enabling remote code execution (RCE) on the affected instance.
Godzilla Webshell
Upon analysing the backdoor, it was identified as the Chinese-language Godzilla in-memory backdoor. This backdoor was developed by a user named “BeichenDream”, who created it in response to existing webshells frequently being detected by security products during red team operations. The author claims that Godzilla avoids detection by using Advanced Encryption Standard (AES) encryption for its network traffic and boasts a very low static detection rate across various security vendor products. The project idea of a servlet-based, in-memory shell for Tomcat and other middleware was first proposed by the user “feihong-cs”.
The main issue with malware fileless techniques is that they are extremely challenging to detect if customers are relying on legacy anti-virus, which use signature-based methods, sandboxing, whitelisting, or sometimes even machine learning protection methods.
Initial Access
The attack begins with the exploitation of CVE-2023-22527 using velocity.struts2.context to execute OGNL object (Figures 1 and 2).
Diving deep into the malicious payload (Figure 3), we discovered:
- The attacker using OGNL object to read a parameter called x. In the parameter’s value, through the help of ScriptEngineManager, the attack evaluates a JavaScript code. The reason the attacker is using objects linking chains could be because of a OGNL template issue in that if its length is longer than ~200 characters, it will be blocked based on the struts.ognl.expressionMaxLength setting.
- As per the JavaScript code, attacker adds the header x_evc_ecneulfnoc to make sure the object has been loaded successfully, which will be shown in the response (Figure 4).
As shown in Figure 5, the MemGodValueShell class has four attributes: uri, serverName, standardContext, and valveString. These are used to store various pieces of information during the execution of the class methods.
MemGodValueShell has three methods: getField is a method that uses reflection to retrieve the value of a private field from an object (Figure 6). It traverses the class hierarchy to find the field.
The second method in the class is getStandardContext (Figure 7). This method attempts to retrieve the StandardContext object by iterating over all threads in the current thread group. It checks for threads that are part of the StandardEngine or Acceptor components of Tomcat. It retrieves various internal fields using reflection to navigate through the server's internal structure.
The last and the main method is the class constructor MemGodValueShell (Figure 8). This constructor method performs several actions:
- Loads the Valve class from the current thread's context class loader.
- Retrieves the StandardContext object using the getStandardContext method.
- Iterates over all threads in the current thread group.
- For each thread, if it is not named "exec", the method:
- Retrieves the target object of the thread
- Checks if the target object is an instance of Runnable
- Retrieves the global field from the target object
- Iterates over the processors and retrieves the request (req) object
- Retrieves the serverPort, serverNameMB, and decodedUriMB fields from the request object
- Decodes the valveString from Base64 to a byte array
- Defines a new class using the defineClass method of the ClassLoader
- Instantiates the new class and adds it as a valve to the pipeline of the StandardContext
For easy troubleshooting, we printed some data, as shown in Figures 9 and 10:
In summary, MemGodValueShell does the following:
- Reflection Usage – The code heavily uses Java Reflection to access private fields and methods of classes
- Thread Inspection – It inspects threads to find specific ones related to Tomcat's StandardEngine and Acceptor
- Dynamic Class Loading – It dynamically loads and defines a class from a Base64-encoded string
- Valve Injection – It injects a custom valve into the Tomcat pipeline, which is intended to provide a backdoor or some form of unauthorized access
In dynamic class loading, the MemGodValueShell constructor contains a long Base64 encoded string in a string variable valveString, which is also the compiled Java class GodzillaValue (Figure 11). After decompiling it, we the obtained Java code which is explained below.
The class GodzillaValue extends ValveBase, indicating that it is a custom Tomcat valve. It has four fields: xc, pass, md5, and payload. The xc and pass fields are used for cryptographic operations as xc is a key which has been used in AES128, while md5 stores an MD5 hash, and payload is used to store a dynamically loaded class. GodzillaValue class stores the hardcoded xc string "3c6e0b8a9c15224a" and the pass string "pass" is likely used for authentication or encryption purposes.
For the methods, we have the following:
- md5 – calculates MD5 hash
- base64Encode – Base64 encode
- base64Decode – Base64 decode
- x – AES encryption/decryption method
- Invoke – the overwritten valve class method which handles HTTP requests and responses (Figure 12)
It seems that the Invoke method is waiting for the next part of the attack payload, which will complete the cycle of the attack. But we never received this part in our honeypots, which will make this kind of shell idle until it receives the payload class. Based on this, the threat actor may be building their own botnet network.
Based on the Godzilla source code analysis in Figure 12, we can easily guess that class payload should be as the following (Figure 13):
Based on our assumption, if we send a POST request with Accept-Language header “zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2” and the pass parameter value has the Java-compiled data of payload class encrypted with parameter xc, it should initialized the payload class. We tried this, as shown in Figure 14, and Figure 15 shows how we successfully loaded the payload object.
Now, we can try to determine if our shell works: To prepare our command, the encrypted command should be “AES128(Base64encoded(command))” and the AES key should be the xc parameter in GodzillaValue class (Figure 16).
This worked, but going back to the GodzillaValue class, we noticed that the first and last 16 characters of the result is “md5(pass+xc)”. Also, the command execution result is “AES128(base64encode(result))” encrypted with the xc key (Figure 17). Let’s revert these cryptographic operations to get our result (Figure 18).
Vision One Hunting Queries
Hunting query if Atlassian Java executed commands:
(eventSubId:2 AND processCmd:atlassian AND parentCmd:atlassian AND parentCmd:java AND (objectName:*\\Windows\\System32\\* OR objectName:*bin/*))
Conclusion
The CVE-2023-22527 vulnerability continues to be widely exploited by a wide range of threat actors who abuse this vulnerability to perform malicious activities, making it a significant security risk to organizations worldwide. The users of Atlassian Confluence are advised to immediately patch their servers and mitigate the risks associated with this attack. Leveraging security solutions such as Trend Vision One™️ can assist organizations in safeguarding their environment from threat actors and attacks like the one described in initial stages of the attack.
Trend Vision One™ – Endpoint Security provides protection from any threats that may target this vulnerability via the following Deep Packet Inspection (DPI) rule:
- 1011954 - Atlassian Confluence Data Center and Server Template Injection Vulnerability (CVE-2023-22527)
TippingPoint has posted a Customer Shield Writer (CSW) file for this vulnerability that is available for customers to download on Threat Management Center (TMC). The applicable rule is as follows:
- 43721 - HTTP: Atlassian Confluence Data Center and Server Template Injection Vulnerability
Trend Micro Cloud One – Workload Security helps defend a variety of environments such as virtual, physical, cloud, and containers against this threat via this rule:
- 1011954 - Atlassian Confluence Data Center and Server Template Injection Vulnerability (CVE-2023-22527)
Trend Micro Deep Discovery Inspector customers are protected with the following rule:
- DDI RULE 4990 - CVE-2023-22527 - Atlassian OGNL Injection Exploit - HTTP (Request)
Indicators of Compromise (IOC)
| Hash | Detection |
| dfeccdc0c1d28f1afd64a7bb328754d07eead10c | TROJ_FRS.VSNTH724 |
| 2cb94ce0b147303b7beb91f034d0dc7fa734dbcb | Backdoor.JS.WEBSHELL.VSNW08H24 |