Forensic Evidence: Active Exploitation Of Asset.uploadCustomIcon Endpoint (joomla_agent Binary Payload)
Peter Dowse
Hi Guys - I had two sites hacked last night.
I am sharing forensic evidence from a recent compromise on our server to help document the attack patterns related to the recent asset.uploadCustomIcon vulnerability.
Our site was running the latest version of SP Page Builder when automated bots successfully exploited the custom icon endpoint. Our hosting provider suspended the account after a binary file was caught executing under our user account.
Exploit Vector:
Endpoint Targeted: POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon
Server Response: 500 Internal Server Error (The archive extraction triggered a server crash or timeout, but successfully wrote files to the root).
Discovered Payloads:
Malicious Font Directory: Located at /media/com_sppagebuilder/assets/iconfont/icouaxlbi/
Persistent Executable Binary: A file named joomla_agent was dropped inside the folder. It is a statically linked, unstripped ELF 64-bit LSB executable for x86-64 Linux. It was found masquerading as a native core process and running constantly in the background.
Obfuscated PHP Backdoor: A conditional shell was planted that intercepts requests and throws a fake 404 Not Found unless authenticated with a specific token string (?t=zjvayjjnzqzjqckl).
We have completely removed the component directories, purged the active system processes, regenerated our database credentials, and upgraded our system environment.
Sharing this primarily so the security team is aware of the joomla_agent binary name being used in the wild for server process masquerading alongside the standard PHP web shells.
Can this please be looked at as a matter of urgency for the next update?
Paul Frankowski
Accepted AnswerHi Peter,
to be honest it was fixed on 15 June morning (11 days ago), but many webmasters ignored update, and even if they made it, didn't scan the website, and malware file(s) could stay hidden.
We have separate topic (link was shared above) with many tips, suggestions, codes, scaners and firewall names etc.
I hope that you cleaned your website or recovered clean version from backup.
Ziaul Kabir
Accepted AnswerHello Peter,
We sincerely apologize for the inconvenience caused.
This issue has been fixed in SP Page Builder v6.6.2. Once you upgrade to v6.6.2, this specific vulnerability can no longer be exploited.
However, if your site was compromised before upgrading, simply updating the extension will not remove any malicious files or backdoors that may have already been uploaded. If those files remain on the server, attackers may still be able to access your site. Therefore, it is important to perform a complete cleanup before considering the site secure.
Please follow the cleanup guide here: https://www.joomshaper.com/forum/question/45152
You can also use the following security scanner to help identify malicious files and delete them: https://github.com/zkrana/joomla-security-scanner
Please make sure to read the README.md file in the repository for instructions on how to run the tool.
After completing the cleanup and upgrading to v6.6.2, please let us know the outcome or if you need any further assistance. We'll be happy to help.
Thank you.
Peter Dowse
Accepted AnswerHi Ziaul,
That's good to know - I have a feeling they might have gotten in whilst running a previous version, then updating to the latest version essentially locked the door on them but the suspicious files were still left on the site.
Glad to know this security loophole has been plugged.