× Presentation and instructions about security tools used to prevent server hacking. Feel free to use them or ask us to protect your site hosting it to a safe, daily monitored vps senter. Freespirits will ensure great quality of services.

Joomla site showing “Hacked by Antonkill” — template params database injection a

Περισσότερα
2 Ημέρες 18 Ώρες πριν - 2 Ημέρες 18 Ώρες πριν #348 από infogate
Title: Joomla site showing “Hacked by Antonkill” — database template params injection and full cleanup solution

Hello everyone,

I want to share a real Joomla security case we handled, because it may help other administrators who suddenly see their Joomla website replaced by a full-screen hacked message.

The visible symptom was that the frontend of the website was replaced with a dark full-screen page saying:
Hacked by Antonkill

The browser title was also changed to the same hacked message, and the normal website content was hidden/replaced by injected JavaScript and CSS.

After checking the files, logs, Nginx configuration, Joomla database, recent modified files, and template settings, the issue was not in the main Joomla
index.php
file.

The malicious payload was stored inside the Joomla database, specifically in the template style parameters.

In this case, the infected table was:
#__template_styles

The infected template row contained malicious strings such as:
Hacked by Antonkill
document.body.innerHTML
z-index:2147483647
overflow:hidden

This means the attacker injected code into the active template style settings, so the page was being modified dynamically from the database.

1. Set site variables

First I set the site path and extracted the Joomla database credentials from
configuration.php
.

Replace
ACCOUNT
with your hosting account username.
SITE="/home/ACCOUNT/public_html"

DB=$(grep "public \$db =" "$SITE/configuration.php" | cut -d"'" -f2)
DBUSER=$(grep "public \$user =" "$SITE/configuration.php" | cut -d"'" -f2)
PASS=$(grep "public \$password =" "$SITE/configuration.php" | cut -d"'" -f2)
PFX=$(grep "public \$dbprefix =" "$SITE/configuration.php" | cut -d"'" -f2)

echo "DB=$DB"
echo "DBUSER=$DBUSER"
echo "PFX=$PFX"

2. Check if the frontend still contains the hacked payload
curl -skL https://example.com/ | grep -niE "Antonkill|Hacked by|document.body.innerHTML|z-index:2147483647|overflow:hidden" | head -20

If this returns output, the payload is still present on the live page.

3. Check the Joomla template styles table
mysql -u"$DBUSER" -p"$PASS" "$DB" -e "
SELECT id, template, home, title, LENGTH(params) AS params_length
FROM ${PFX}template_styles
WHERE params LIKE '%Antonkill%'
   OR params LIKE '%Hacked by%'
   OR params LIKE '%document.body.innerHTML%'
   OR params LIKE '%z-index:2147483647%'
   OR params LIKE '%overflow:hidden%';
"

In my case, this returned the infected active template style row.

Example:
+----+-------------+------+-----------------------+---------------+
| id | template    | home | title                 | params_length |
+----+-------------+------+-----------------------+---------------+
|  9 | vina_eclipo | 1    | Vina_Eclipo - Default |          2799 |
+----+-------------+------+-----------------------+---------------+

So the infection was in:
Table: #__template_styles
Row: id 9
Template: vina_eclipo
Home style: yes

4. Backup before touching anything

Do not edit the database before taking a backup.
DOMAIN="example.com"
IR="/root/${DOMAIN}-incident-$(date +%F_%H%M)"
mkdir -p "$IR"

mysqldump -u"$DBUSER" -p"$PASS" "$DB" > "$IR/current_db_before_clean.sql"

mysql -u"$DBUSER" -p"$PASS" "$DB" -e "
CREATE TABLE ${PFX}template_styles_backup_$(date +%Y%m%d_%H%M%S) AS
SELECT * FROM ${PFX}template_styles;
"

echo "Incident folder: $IR"

5. Look for a clean template style row

In my case, there was another clean row using the same template. This made the repair safer.
mysql -u"$DBUSER" -p"$PASS" "$DB" -e "
SELECT id, template, home, title, LENGTH(params) AS params_length,
CASE
  WHEN params LIKE '%Antonkill%'
    OR params LIKE '%Hacked by%'
    OR params LIKE '%document.body.innerHTML%'
    OR params LIKE '%z-index:2147483647%'
  THEN 'INFECTED'
  ELSE 'CLEAN'
END AS status
FROM ${PFX}template_styles
WHERE template='vina_eclipo';
"

Example result:
+----+-------------+------+---------------------------+---------------+----------+
| id | template    | home | title                     | params_length | status   |
+----+-------------+------+---------------------------+---------------+----------+
|  9 | vina_eclipo | 1    | Vina_Eclipo - Default     |          2799 | INFECTED |
| 11 | vina_eclipo | 0    | Vina_Eclipo - Default (2) |         27066 | CLEAN    |
+----+-------------+------+---------------------------+---------------+----------+

6. Repair the infected row by copying clean params

Since row
11
was clean and used the same template, I copied only the clean
params
from row
11
to the infected active row
9
.
mysql -u"$DBUSER" -p"$PASS" "$DB" -e "
UPDATE ${PFX}template_styles infected
JOIN ${PFX}template_styles clean
  ON clean.id = 11
SET infected.params = clean.params
WHERE infected.id = 9
  AND infected.template = 'vina_eclipo'
  AND clean.template = 'vina_eclipo'
  AND clean.params NOT LIKE '%Antonkill%'
  AND clean.params NOT LIKE '%Hacked by%'
  AND clean.params NOT LIKE '%document.body.innerHTML%'
  AND clean.params NOT LIKE '%z-index:2147483647%';
"

Important: change the row IDs and template name according to your own case.

7. Verify the database is clean
mysql -u"$DBUSER" -p"$PASS" "$DB" -e "
SELECT id, template, home, title, LENGTH(params) AS params_length,
CASE
  WHEN params LIKE '%Antonkill%'
    OR params LIKE '%Hacked by%'
    OR params LIKE '%document.body.innerHTML%'
    OR params LIKE '%z-index:2147483647%'
  THEN 'INFECTED'
  ELSE 'CLEAN'
END AS status
FROM ${PFX}template_styles
WHERE id IN (9,11);
"

Expected result:
id 9  CLEAN
id 11 CLEAN

8. Clear Joomla cache and restart services
rm -rf "$SITE/cache"/*
rm -rf "$SITE/administrator/cache"/*

systemctl restart php-fpm74 2>/dev/null || true
systemctl reload nginx

Adjust the PHP-FPM service name if your server uses a different one.

9. Test the live page again
curl -skL https://example.com/ | grep -niE "Antonkill|Hacked by|document.body.innerHTML|z-index:2147483647|overflow:hidden" | head -20

Expected result:
No output

Also check the page title:
curl -skL https://example.com/ | grep -ni "<title>" | head

The title should no longer show the hacked message.

10. Add a database trigger to block reinjection

To prevent the same visible payload from being saved again into
#__template_styles
, I added a database trigger.

Replace
prefix_
with your real Joomla database prefix.

Example: if your prefix is
fint_
, then the table is
fint_template_styles
.
DROP TRIGGER IF EXISTS prefix_template_styles_block_hack;

DELIMITER //
CREATE TRIGGER prefix_template_styles_block_hack
BEFORE UPDATE ON prefix_template_styles
FOR EACH ROW
BEGIN
  IF NEW.params LIKE '%Antonkill%'
     OR NEW.params LIKE '%Hacked by%'
     OR NEW.params LIKE '%document.body.innerHTML%'
     OR NEW.params LIKE '%z-index:2147483647%'
  THEN
    SIGNAL SQLSTATE '45000'
      SET MESSAGE_TEXT = 'Blocked malicious template_styles injection';
  END IF;
END//
DELIMITER ;

Shell version using variables:
mysql -u"$DBUSER" -p"$PASS" "$DB" <<SQL
DROP TRIGGER IF EXISTS ${PFX}template_styles_block_hack;

DELIMITER //
CREATE TRIGGER ${PFX}template_styles_block_hack
BEFORE UPDATE ON ${PFX}template_styles
FOR EACH ROW
BEGIN
  IF NEW.params LIKE '%Antonkill%'
     OR NEW.params LIKE '%Hacked by%'
     OR NEW.params LIKE '%document.body.innerHTML%'
     OR NEW.params LIKE '%z-index:2147483647%'
  THEN
    SIGNAL SQLSTATE '45000'
      SET MESSAGE_TEXT = 'Blocked malicious template_styles injection';
  END IF;
END//
DELIMITER ;
SQL

11. Block suspicious Joomla AJAX attack paths at Nginx level

In my case, I also blocked suspicious public Joomla AJAX endpoints related to Helix / SP Page Builder style attacks.

Inside the correct Nginx vhost
server { }
block, I added:
location ^~ /component/ajax/ {
    return 444;
    access_log off;
    log_not_found off;
}

if ($args ~* "uploadCustomIcon|com_sppagebuilder|nrframework|plugin=helix3|nrinlinefileupload") {
    return 444;
}

Then:
nginx -t && systemctl reload nginx

12. Test that the dangerous endpoints are blocked
curl -skI -o /dev/null -w "%{http_code}\n" "https://example.com/component/ajax/?format=raw&plugin=nrframework&task=include"

curl -skI -o /dev/null -w "%{http_code}\n" "https://example.com/component/ajax/?format=raw&plugin=helix3"

curl -skI -o /dev/null -w "%{http_code}\n" "https://example.com/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon"

Expected result with Nginx
return 444
:
000
000
000

13. Disable only the risky Helix AJAX plugin

I did not disable the main Helix framework plugin, because that can break the template.

I disabled only the Helix AJAX plugin:
mysql -u"$DBUSER" -p"$PASS" "$DB" -e "
UPDATE ${PFX}extensions
SET enabled=0
WHERE type='plugin'
  AND folder='ajax'
  AND element='helix3';
"

Keep this enabled unless you know it is safe to disable:
System - Helix3 Framework

14. Check for suspicious recent PHP-like files

I also searched for recently modified PHP-like files:
find "$SITE" -type f \( \
-name "*.php" -o -name "*.php5" -o -name "*.php7" -o -name "*.phtml" -o -name "*.pht" -o -name "*.phar" -o -name "*.shtml" \
\) -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %s %p\n' | sort

Pay special attention to suspicious files in:
/tmp
/cache
/administrator/cache
/media
/images
/uploads
/logs

In this specific case, most recent files were Joomla/VirtueMart cache files. A strange duplicated log path was checked manually, but it contained only normal VirtueMart missing-image log entries and no suspicious PHP functions.

15. Check suspicious files with grep

Example:
grep -niE "Antonkill|base64_decode|eval\(|gzinflate|shell_exec|passthru|FilesMan|move_uploaded_file|assert\(" /path/to/suspicious/file.php

If there is no output, it does not guarantee the file is safe, but it is a useful quick check.

16. Important extra issue found

The Nginx/PHP error log also showed this missing Joomla file:
/libraries/joomla/document/html/renderer/head.php

called from:
/templates/vina_eclipo/error.php

This appears to be a separate compatibility or missing-file issue related to the template error page, not the Antonkill payload itself. It should be fixed after the security cleanup.

Final result

The visible hacked page was removed.

The infected template parameters were restored from a clean same-template row.

The Joomla cache was cleared.

Dangerous public AJAX endpoints were blocked.

A database trigger was added to block the same malicious payload from being saved again.

The risky Helix AJAX plugin was disabled.

Recent PHP-like files and suspicious logs were checked.

Important notes
  • Always backup the database before editing
    #__template_styles
    .
  • Do not restore the whole database if only one template style row is infected.
  • Check if there is a clean row from the same template before doing manual cleanup.
  • Do not assume the hacked message is always inside
    index.php
    .
  • In this case, the payload was stored in the database.
  • Update Joomla, the template, SP Page Builder, Helix, VirtueMart, and all extensions as soon as possible.
  • Keep unnecessary public AJAX endpoints blocked.
  • Do not disable the main Helix system framework blindly, because it may break the frontend template.

I hope this helps someone facing the same Joomla “Hacked by Antonkill” issue.


The best possible way to start your online marketing : fspirits.com/go/leadsleap-home
Explode Your Web Site Traffice: fspirits.com/go/sparktraffic
Start your affiliate journey here: fspirits.com/go/olsp-academy
Best Solution To Create Videos: fspirits.com/go/create-studio-pro
Best Solution To Create Graphics: fspirits.com/go/clickdesigns
Smart Chat Automation: fspirits.com/go/chatterpal
Multi-Purpose Video Maker: fspirits.com/go/avatar-builder
Multi-Purpose Video Creator: fspirits.com/go/video-creator
AI Human Spokesperson Videos: fspirits.com/go/humanpal

Last edit: 2 Ημέρες 18 Ώρες πριν by infogate.

Παρακαλούμε Σύνδεση ή Δημιουργία λογαριασμού για να συμμετάσχετε στη συζήτηση.

Χρόνος δημιουργίας σελίδας: 0.075 δευτερόλεπτα
Powered by Kunena Φόρουμ