Kurz gesagt: Ein Malware-Scanner für Websites findet vor allem bekannte Muster in Dateien oder in der ausgelieferten Seite. Neuer und verschleierter Code, Hintertüren in der Datenbank, fremde Konten, Cronjobs und SSH-Schlüssel bleiben oft unsichtbar. „Nichts gefunden“ bedeutet deshalb nicht „sauber“. Verlässlich wird eine Prüfung erst durch die Kombination aus Scanner, Abgleich mit dem Original, Prüfung von Datenbank und System sowie Verhaltensüberwachung.
Die trügerische Ruhe nach dem grünen Haken
Nach PHP2Shell haben viele Betreiber das getan, was naheliegt: einen Scanner laufen lassen. Ein Online-Dienst prüft die Startseite, ein Sicherheits-Plugin durchsucht das Webverzeichnis, das Ergebnis ist grün. Damit scheint die Frage beantwortet, ob vor dem Patch etwas passiert ist.
Das Problem liegt im Prinzip. Die meisten Scanner vergleichen Inhalte mit Mustern bekannter Schadsoftware. Für die Lücken CVE-2026-109618 und CVE-2026-109619 gibt es aber keine veröffentlichten, bestätigten Indicators of Compromise; die Erkennung beruht auf Verhaltensanalyse. Ein Scanner kann nicht nach Spuren suchen, die niemand kennt. Er findet bestenfalls allgemeine Schadsoftware, die nach einem Einbruch nachgeladen wurde, sofern sie bekannten Mustern folgt.
Das macht Scanner nicht wertlos. Es bedeutet nur, dass ihr Ergebnis richtig eingeordnet werden muss. Welche Anzeichen über Scanner hinaus zählen, beschreibt Bin ich schon kompromittiert?.
Malware-Scanner für Websites: drei Bauarten
| Bauart | Was sie sieht | Was sie nicht sieht |
|---|---|---|
| Externer Scanner (Online-Dienst) | ausgelieferte Seiten, eingebundene Skripte, Weiterleitungen, Sperrlisten | Dateien, Datenbank, Konten, alles, was nur unter Bedingungen ausgeliefert wird |
| Scanner im CMS (Plugin oder Erweiterung) | Dateien im Webverzeichnis, teils Datenbankinhalte, Abgleich mit Kerndateien | Systemebene, Cronjobs, SSH; läuft im möglicherweise kompromittierten System |
| Scanner auf dem Server (signaturbasiert) | alle lesbaren Dateien, auch außerhalb des Webverzeichnisses | unbekannte und verschleierte Muster, Datenbank, Konten, Verhalten |
Externe Scanner sind nützlich, um sichtbare Folgen zu erkennen, etwa Weiterleitungen oder Einträge auf Sperrlisten. Viele Hacks liefern ihre Spam- oder Umleitungsinhalte aber nur bestimmten Besuchern aus, zum Beispiel Suchmaschinen oder Mobilgeräten. Der Scanner sieht dann eine saubere Seite.
Scanner im CMS haben mehr Einblick, aber ein grundsätzliches Problem: Sie laufen im selben System, das sie prüfen sollen. Code mit ausreichenden Rechten kann ihre Ergebnisse beeinflussen, Dateien ausblenden oder den Scanner deaktivieren. Server-Scanner arbeiten außerhalb der Anwendung, bleiben aber auf Muster angewiesen.
Was Scanner grundsätzlich übersehen
Unabhängig von der Bauart gibt es Bereiche, die ein Datei- oder Seitenscanner kaum abdecken kann:
- Neuer oder individuell verschleierter Code: Jede Variante, die anders aussieht als bekannte Muster, rutscht durch.
- Die Datenbank: Skripte in Inhalten, geänderte Einstellungen, Trigger und fremde Konten. Mehr dazu unter Die Datenbank auf eingeschleusten Code prüfen.
- Zugänge: zusätzliche Admin-Konten, SSH-Schlüssel, Datenbankbenutzer, Konten im Hosting-Panel.
- Systemdienste und Cronjobs: Mechanismen, die Schadcode regelmäßig nachladen.
- Unauffällige Änderungen an legitimen Dateien: eine einzige zusätzliche Zeile in einer Kerndatei, die harmlos aussieht.
- Abgeflossene Daten: Ob Zugangsdaten oder Kundendaten kopiert wurden, zeigt kein Scanner.
Was stattdessen Gewissheit schafft
Mehr Sicherheit bringt die Kombination von Prüfarten, die unterschiedlich arbeiten:
- Abgleich mit dem Original: Er findet jede Veränderung an bekannten Dateien, unabhängig von Mustern. Das Vorgehen beschreibt CMS-Kerndateien mit dem Original vergleichen.
- Gezielte Suche nach Auffälligkeiten: PHP-Dateien in Upload-Ordnern, kürzlich geänderte Dateien, verschleierter Code, ausführbare Dateien in temporären Ordnern.
- Prüfung von Konten und Systemdiensten: Benutzer, Schlüssel, Cronjobs und Dienste mit dem bekannten Soll vergleichen.
- Logauswertung: Anfragen auf unbekannte Dateien, Häufungen von Fehlern, ungewöhnliche Anmeldungen.
- Verhaltensüberwachung: Prozesse des Webservers, die eine Shell starten, unerwartete ausgehende Verbindungen, neue Dateien in sensiblen Ordnern.
Die letzte Kategorie ist die wichtigste, wenn es keine bekannten Spuren gibt. Sie fragt nicht, wie Schadcode aussieht, sondern was er tut. Ein Webserver-Prozess, der plötzlich eine Shell startet, fällt auf, egal wie der auslösende Code verschleiert ist.
Lassen Sie einen Server-Scanner von einem sauberen System aus über eine schreibgeschützte Kopie laufen, statt auf dem verdächtigen Server selbst. So kann eingeschleuster Code das Ergebnis nicht beeinflussen.
Wie Sie Scanner sinnvoll einsetzen
Scanner haben ihren Platz, als ein Werkzeug unter mehreren. Ein externer Scanner eignet sich als regelmäßige Kontrolle der sichtbaren Folgen, etwa wöchentlich. Ein Scanner im CMS meldet bekannte Schadsoftware und veränderte Kerndateien im Alltag. Ein Server-Scanner ergänzt die Suche nach bekannten Mustern im ganzen Dateisystem.
Entscheidend ist der Umgang mit dem Ergebnis. Ein Fund ist ein klarer Prüfauftrag und rechtfertigt eine vollständige Untersuchung, weil selten nur eine Datei betroffen ist. Ein leeres Ergebnis ist dagegen nur eine Aussage über die geprüften Muster. Halten Sie in Ihrer Dokumentation fest, welcher Scanner wann mit welchem Stand gelaufen ist, und schreiben Sie nicht „System sauber“, sondern „keine bekannten Muster gefunden“.
Für die Geschäftsführung heißt das: Ein grüner Haken ersetzt keine Prüfung durch jemanden, der Dateien, Datenbank, Konten und Verhalten gemeinsam betrachtet. Nach einem Vorfall mit möglicher Codeausführung, wie bei PHP2Shell denkbar, sollte diese Prüfung stattfinden.
Meldet ein Scanner dagegen einen Fund, ist schnelles, aber geordnetes Handeln gefragt. Löschen Sie die gemeldete Datei nicht sofort über die Scanner-Funktion. Sichern Sie zuerst Datei und Logs, damit sich klären lässt, wie sie auf den Server kam. Wie eine vollständige Bereinigung abläuft, beschreibt die Leistung Malware und Webshells entfernen lassen.
Wie hilft PHP SOS konkret?
- Wir kombinieren Scanner mit Abgleich gegen das Original, gezielter Suche und Auswertung von Konten, Diensten und Logs.
- Wir prüfen verdächtige Systeme über gesicherte Kopien, damit Ergebnisse nicht vom kompromittierten System beeinflusst werden.
- Wir kennzeichnen jedes Ergebnis ehrlich als belegt, wahrscheinlich oder unbekannt.
- Mit dem Security-Monitoring für Webserver überwachen wir dauerhaft das Verhalten Ihrer Server, nicht nur bekannte Muster.
Häufige Fragen
Ist meine Website sauber, wenn der Malware-Scanner nichts findet?
Nicht zwingend. Scanner finden vor allem bekannte Muster. Neuer oder gut verschleierter Code, Hintertüren in der Datenbank, fremde Konten, Cronjobs und SSH-Schlüssel bleiben oft unentdeckt. Ein leeres Ergebnis ist ein Baustein, kein Freispruch.
Was ist der Unterschied zwischen einem externen Scanner und einem Plugin-Scanner?
Ein externer Scanner ruft die Website von außen auf und sieht nur, was ausgeliefert wird. Ein Plugin-Scanner läuft innerhalb des CMS und kann Dateien lesen, läuft aber im selben System, das möglicherweise kompromittiert ist. Beide haben eigene blinde Flecken.
Gibt es Scanner-Signaturen für PHP2Shell?
Für PHP2Shell gibt es keine veröffentlichten, bestätigten Indicators of Compromise. Scanner können deshalb nicht gezielt nach gesicherten PHP2Shell-Spuren suchen. Die Erkennung beruht auf Verhaltensanalyse und auf der Suche nach allgemeinen Anzeichen einer Kompromittierung.
Welcher Scanner ist der beste?
Die Frage führt in die Irre. Wichtiger als ein bestimmtes Produkt ist die Kombination verschiedener Prüfarten: Abgleich mit dem Original, Suche in Dateien und Datenbank, Prüfung von Konten und Systemdiensten sowie Überwachung des Verhaltens.