Join Trustwave at the 2023 Gartner Security & Risk Management Summit in London, September 26-28. Learn More

Join Trustwave at the 2023 Gartner Security & Risk Management Summit in London, September 26-28. Learn More

Managed Detection & Response

Eradicate cyberthreats with world-class intel and expertise

Managed Security Services

Expand your team’s capabilities and strengthen your security posture

Consulting & Professional Services

Tap into our global team of tenured cybersecurity specialists

Penetration Testing

Subscription- or project-based testing, delivered by global experts

Database Security

Get ahead of database risk, protect data and exceed compliance requirements

Email Security & Management

Catch email threats others miss with layered security & maximum control

Co-Managed SOC (SIEM)

Eliminate alert fatigue, focus your SecOps team, stop threats fast, and reduce cyber risk

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
The Trustwave Approach
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Platform
SpiderLabs Fusion Center
Security Operations Centers
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats

[Honeypot Alert] JCE Joomla Extension Attacks

Our web honeypots picked up some increased exploit attempts for an old Joomla Content Editor (JCE) Extension vulnerability.


Although this vulnerability is a few years old, botnet owners are heavily scanning for sites that are vulnerable and attempting to exploit them.

Exploit Details

Here are the exploit details from the vulnerability write-up on Exploit-DB:


Web Honeypot Logs - Attack Sequence

Step 1: Attempt to Upload a PHP Webshell

The first step in this attack is to attempt to upload a webshell/backdoor file to the JCE ImageManager. Here is how the attack looked in the default Apache access_log file:


This entry shows a POST request to the ImageManager Joomla Plugin using the "com_jce" option. We can also see a tell-tale sign of a malicious program in the User-Agent string value "BOT for JCE". Unfortunately, the default Apache access_log does not actually log the critical POST payload for this request so we can not see what was sent. Fortunately, we also have our ModSecurity WAF installed so we can go to the detailed audit log file to see the complete transaction. Here is the same transaction as logged by ModSecurity:


We notice a few things here:

  • Under Section "B" - We can see the POST request is "MultiPart" meaning that it is an attempt to upload a file attachment.
  • Under Section "J" - we can see the meta-data about the file attachment. It was a file called "food.gif".
  • Under Section "H" - we see two different rules triggered on this request. One for a missing Accept request header and one from our commercial ModSecurity rules package for the suspicious User-Agent value.

File Attachment Analysis

ModSecurity has the ability to capture and store file attachments. When we inspect the "food.gif" file, we find the following:


This is an obfuscated PHP file. After decoding, we find this section of code:


This is a typical webshell/backdoor that allows the attacker to submit OS commands and upload files:


Step 2: Rename File Extension

After uploading the webshell file, the attacker next needs to rename the file and change the file extension from ".gif" to ".php" so that it will be executed as code by the application. There are known exploit tools to achieve this task. Here is an example screenshot of a PHP exploit page:


The source code of the page shows the attack details:


The highlighted section show the JSON request body content that uses the "folderRename" action to change the uploaded file extension. This is how the actual attack attempt looked in the ModSecurity audit log file:


Note under Section H that our commercial rule captured this attack attempt.

Step 3: Access the Webshell

The last step in the attack sequence was for the attacker to try and access the webshell file:

Since the exploit attempt did not work, the honeypot returned a 404.


Attackers are constantly scanning the internet for web sites that have out-dated software. It is critical that web site owners stay vigilant in updating their software and applying patches. In addition, using a Web Application Firewall (WAF) such as ModSecurity can also aid operational security personnel with incident response by providing essential transactional data.