HTProtect - schnelle Erste Hilfe für und gegen gehackte Joomlas

    Ich habe heute mehrere /assets/images/accesson.php's in non-Joomla Sites eliminiert, die ich auf dem gleichen Webspace parallel zu mehreren Joomla's hoste. Ich habe die von HTProtect erzeugte Mini-htaccess in alle /images-Verzeichnisse kopiert und damit scheint erst mal Ruhe zu herrschen.

    Zitat von webbie07

    Nun ja, Der IONOS Server musste aber erst das Haus betreten, die Verzeichnisstrukur hinuntersteigen und erkannte dann, das im Keller Licht brennt. 😉

    Nichts für ungut, typisch deutsch. Das sind genau die Typen, die neben einen Kindergarten ziehen und verlangen, dass er dicht macht, weil sie ihre Ruhe haben wollen. Und jetzt mal meinen Senf zu den Mails von kitepascal : Ich betreibe fünf Webseiten mit Joomla und bei einer Seite bekam ich die Mail von ihm, die vor der unsicheren JCE-Komponente warnte. Da war ich aber schon im Absichern. Bei einer Seite ist es mir durch eigene Schusslichkeit misslungen, sie wurde gehackt aber noch um 23:30 Uhr durch ein sauberes Backup ersetzt. Die XML-Files sind öffentlich einsehbar, also was soll dieses Gehabe? Dass ich bei fünf Seiten nur bei einer Seite eine Mail von kitepascal erhielt, beweist doch, dass er nicht alle ereichbaren Seiten gescannt hat. In seiner Mail steht auch nichts davon, dass ich irgendwelche kostenpflichtigen Dienste von ihm in Anspruch nehmen muss, sondern wie man sich beim Hack behilft. Das sehe ich als Nachricht und nicht als Werbung an.

    Zitat von Bergwelten

    Nichts für ungut, typisch deutsch. Das sind genau die Typen, die neben einen Kindergarten ziehen und verlangen, dass er dicht macht, weil sie ihre Ruhe haben wollen.

    Natürlich. Vielleicht einfach mal an die frische Luft gehen. Dann klappt es vielleicht wieder mit einer sachlichen Auseinandersetzung. 😉

    Zitat von kitepascal

    Gern bitte 1x auf die Whitelist und Fehlalarm melden.

    Sorry. Ist schon alles gelöscht. Der Fehler erscheint offensichtlich, wenn man die SP Builder .zip manuell ins tmp-Verzeichnis extrahiert und dann aus dem tmp-Verzeichnis aktualisiert. Beim Update über das System selbst ist es so noch nicht in Erscheinung getreten.

    Ich habe heute früh eine Mail von htprotect erhalten.

    Inhalt: [Datei verändert] Haupt-.htaccess wurde außerhalb von HTProtect geändert.

    Geändert, eingefügt wurde:

    Code
    <IfModule mime_module>
  AddHandler application/x-httpd-ea-php82 .php .php8 .phtml
</IfModule>

    geblockte Angriffe

    (blöde) Frage: Wie kommt jemand ohne Authorisierung Zugriff auf diese Datei bzw. auf den den Server?

    Okay das soll vom cpanel automatisch gekommen sein. Man müsste halt wissen was von htprotect übenommen werden soll und was nicht...

    Moin! Bitdefender findet HTProtect nicht so gut ... 🤔

    Infizierte Webseite gefunden

    Funktion:
    Online-Gefahrenabwehr

    Wir haben diese gefährliche Seite zu Ihrem Schutz blockiert:
    https://www.ihre-webseite.de/administrator/…rotect&sec=scan

    Name der Bedrohung: Generic.PHP.WebShell.X.78660D2A

    Gefährliche Seiten versuchen, Software zu installieren, die dem Gerät schaden, personenbezogene Daten sammeln oder ohne Ihre Zustimmung aktiv werden kann.

    Und noch eine Meldung von Bitdefender:

    Infizierte Webseite gefunden

    Funktion:
    Online-Gefahrenabwehr

    Wir haben diese gefährliche Seite zu Ihrem Schutz blockiert:
    https://www.ihre-webseite.de/administrator/index.php?option=com_htprotect&sec=scan

    Name der Bedrohung: Generic.PHP.WebShell.X.DEF5EBC9

    Gefährliche Seiten versuchen, Software zu installieren, die dem Gerät schaden, personenbezogene Daten sammeln oder ohne Ihre Zustimmung aktiv werden kann.

    Moin,

    da geht es um die von HTProtect gefundenen Dateiinhalte, die Bitdefender nicht gut findet.

    Eine Fuchs-in-den-Schwanz-beiß-Konstellation.

    Der Schadcode aus den Dateien wird ja im [ Inhalt ]-Spoiler dargestellt und auch im Full Page Editor, mit dem sich Dateien bearbeiten lassen, um Injections zu entfernen.

    Das Gleiche hat man auch, wenn man z. B. ein Backup der infizierten Website lokal entpackt mit Bitdefender o. Ä..

    -> Echtzeitschutz temporär abschalten.

    Wenn man solche Dateien im Texteditor öffnet, besteht keine Gefahr.

    Gruß

    Pascal

    Zitat von kitepascal

    Moin,

    da geht es um die von HTProtect gefundenen Dateiinhalte, die Bitdefender nicht gut findet.

    Eine Fuchs-in-den-Schwanz-beiß-Konstellation.

    Der Schadcode aus den Dateien wird ja im [ Inhalt ]-Spoiler dargestellt und auch im Full Page Editor, mit dem sich Dateien bearbeiten lassen, um Injections zu entfernen.

    Die Seite ist sauber. Aber nun. Danke für die Antwort.

    OK. Ich habe mal versucht, die möglicherweise auslösenden Bestandteile zu optimieren.

    Du könntest die 2.3.4 noch mal (drüber) installieren und testen, ob sich was am Bitdefender-Verhalten geändert hat.

    Wenn nicht, gibt's vielleicht die Möglichkeit, dem Bitdefender mitzuteilen, dass das ein False-Positive ist.

    bei den websites die bei einem speziellen Hoster liegen habe ich folgendes gefunden:

    System & Selbsttest

    • Joomla 5.4.6 · PHP 8.2.31
    • Server: Apache kompatibel · HTTP-Selbsttest: verfügbar
    • Letzter Selbsttest: 2 von 4 bestanden 2026-06-25 11:55:47
    • Startseite erreichbar200OK
      Backend erreichbar (401 = Passwortschutz aktiv)200OK
      PHP-Schild aktiv (Test-Aufruf wird mit 403 abgewiesen)
      Antwort 404: Rewrite-Regeln greifen evtl. nicht (kein Apache/LiteSpeed oder AllowOverride aus).      		404prüfen
      configuration.php gesperrt (403 erwartet)404prüfen

    Welche Prüfungen soll ich durchführen?

    Scheinbar wird ein 403 bei diesem Server zum 404? Das gibt's - manche Server liefern bei verbotenem Zugriff bewusst ein 404 statt 403 aus (Security-by-Obscurity Verschleierungs-Strategie).

    Bitte versuch es mal mit der dahingehend gefixten 2.3.4 (erkennt wenn Server eigentlich 403 als 404 zurückgibt) - was dann dort jetzt im Selbsttest rauskommt. Gggf. nach drüberinstallieren noch mal auf den Update Button am Selbsttest klicken.

    Zitat von kitepascal

    Scheinbar wird ein 403 bei diesem Server zum 404? Das gibt's - manche Server liefern bei verbotenem Zugriff bewusst ein 404 statt 403 aus (Security-by-Obscurity Verschleierungs-Strategie).

    Bitte versuch es mal mit der dahingehend gefixten 2.3.4 (erkennt wenn Server eigentlich 403 als 404 zurückgibt) - was dann dort jetzt im Selbsttest rauskommt. Gggf. nach drüberinstallieren noch mal auf den Update Button am Selbsttest klicken.

    sieht jetzt so aus:

    • Joomla 5.4.6 · PHP 8.2.31
    • Server: Apache kompatibel · HTTP-Selbsttest: verfügbar
    • Letzter Selbsttest: 3 von 4 bestanden 2026-06-25 14:18:34

    Welche Prüfungen? (Details anzeigen)

    PrüfungStatusErgebnis
    Startseite erreichbar200OK
    Backend erreichbar (401 = Passwortschutz aktiv)200OK
    PHP-Schild aktiv (Test-Aufruf wird mit 403 abgewiesen)
    Antwort 404: Rewrite-Regeln greifen evtl. nicht (kein Apache/LiteSpeed oder AllowOverride aus).    		404prüfen
    configuration.php gesperrt404OK

    php-schild wäre noch zu prüfen...

    deevau

    Womöglich ist auf diesem Server AllowOverride tatsächlich aus, wie es dort steht. /administrator Schutz greift ja auch nicht (oder ist der einfach nicht eingerichtet?)
    Dann greift die .htaccess in vielen Teilen nicht.

    Was passiert, wenn du einfach eine test.php mit Inhalt: <?php echo 'It works'; ?> im Basisverzeichnis anlegst und aufrufst?

    Ich hatte heute schon jemanden auf Individualserver im Chat, der AllowOverride dann eingeschaltet hat.

    SantaClaus Danke für die Aufmerksamkeit, ist im Feed gefixt ('Definitionen jetzt aktualisieren' in Übersicht).

    Zitat von kitepascal

    OK. Ich habe mal versucht, die möglicherweise auslösenden Bestandteile zu optimieren.

    Du könntest die 2.3.4 noch mal (drüber) installieren und testen, ob sich was am Bitdefender-Verhalten geändert hat.

    Wenn nicht, gibt's vielleicht die Möglichkeit, dem Bitdefender mitzuteilen, dass das ein False-Positive ist.

    Bis jetzt keine Auffälligkeiten. Wir werden beobachten. :)

    Wenn ich beim Editor jce-pro mein Profil aufrufe, nichts verändere und wieder schließe, kommt als Hinweis:

    "HTProtect hat das Joomla-Backward-Compatibility-Plugin wieder aktiviert: Komponente com_jce benötigte die veraltete Klasse JFormFieldProfileordering – sonst wäre die Seite abgestürzt. Um ohne B/C auszukommen, aktualisiere oder ersetze diese Erweiterung."

    JCE läuft bei mir in der Version 2.9.99.7. Diese Version benötigt meines Wissens das Joomla-Backward-Compatibility-Plugin nicht.

    Wenn ich das Plugin deaktiviere, JCE aufrufe und einen Beitrag editiere und speichere, kommt als Meldung

    "HTProtect hat das Joomla-Backward-Compatibility-Plugin wieder aktiviert: Plugin system/jcepro benötigte die veraltete Klasse JFormFieldHeliximage – sonst wäre die Seite abgestürzt. Um ohne B/C auszukommen, aktualisiere oder ersetze diese Erweiterung."

    Die beiden Meldungen kann ich nicht einordnen.

    PHP-Version: 8.5
    Joomla: 5.46

    Gruß aus dem Emsland
    HoSe