Website-Sicherheit & Malware-Entfernung: Hilfe, wenn Ihre Website gehackt wurde

// Woran erkennen Sie, dass Ihre Website gehackt wurde?

Eine gehackte Website fällt oft zuerst Google, dem Hoster oder Kunden auf – nicht dem Betreiber. Angreifer wollen eine Website meist unbemerkt nutzen statt sie lahmzulegen; die Startseite sieht daher normal aus, während im Hintergrund Spam-Seiten entstehen. Trifft eines der folgenden Anzeichen zu, sollte die Website geprüft und bereinigt werden.

• In den Google-Suchergebnissen steht „Diese Website wurde möglicherweise gehackt“, oder der Browser zeigt eine rote Sicherheitswarnung
• In der Suche erscheinen Seiten, die Sie nie angelegt haben, Titel in japanischen Schriftzeichen oder Pharma- und Glücksspiel-Spam
• Besucher – vor allem mobil oder über Google – werden auf fremde Websites umgeleitet
• Ihr Hoster hat die Website wegen „schädlicher Inhalte“ gesperrt oder das Konto eingeschränkt
• E-Mails von Ihrer Domain landen im Spam-Ordner oder kommen zurück
• Auf dem Server liegen unbekannte Dateien, Admin-Konten oder geplante Aufgaben (Cronjobs)

Weiterleitungen können nur bestimmten Besuchern angezeigt werden; wenn Sie die Website selbst öffnen, wirkt womöglich alles normal. Der Bericht „Sicherheitsprobleme“ in der Search Console zeigt solche versteckten Anzeichen meist als Erstes.

// Wie wird eine gehackte Website bereinigt?

Eine gehackte Website wird bereinigt, indem der Zugang des Angreifers gefunden und geschlossen wird – nicht nur durch Löschen schädlicher Dateien; solange der Einstiegspunkt offen ist, wird die Website bald erneut infiziert. Der Einsatz hat vier Schritte und dauert in einem typischen Fall 2 bis 3 Arbeitstage. Zuerst sichern wir den aktuellen Zustand, prüfen die Bereinigung auf einer Kopie und spielen sie zu verkehrsarmen Zeiten live.

Googles Überprüfung dauert bei Malware meist einige Tage, bei Spam mitunter mehrere Wochen; wir folgen dabei den Schritten aus Googles Leitfaden zu gehackten Websites. Dringt der Angreifer innerhalb von 7 Tagen nach Abschluss über dieselbe Lücke erneut ein, ist unser Einsatz kostenlos.

// Welche Sicherheitslücken treten in individueller Software auf?

In individueller PHP- und Node.js-Software entstehen Lücken meist im Code selbst: dort, wo Nutzereingaben ungeprüft in Datenbank, Seite oder Dateisystem gelangen. Diese Typen begegnen uns am häufigsten.

• SQL-Injection: Abfragen, die per String-Verkettung statt mit Parametern gebaut werden, können die gesamte Datenbank preisgeben
• XSS (Cross-Site-Scripting): ungefiltert ausgegebene Kommentare, Suchbegriffe oder Formulareingaben führen den Code des Angreifers im Browser Ihrer Besucher aus
• Lücken beim Datei-Upload: Uploads ohne Prüfung von Typ und Endung sind der kürzeste Weg, ein ausführbares Skript auf dem Server abzulegen
• Offen liegende Dateien: im Web-Root vergessene .env-Dateien, .git-Ordner, Datenbank-Dumps oder .zip-Backups, deren Passwörter und API-Schlüssel direkt herunterladbar sind
• Fehler bei Authentifizierung und Berechtigungen: unbegrenzte Login-Versuche, erratbare Admin-Adressen und IDs, die fremde Datensätze öffnen

Wir prüfen entlang der Kategorien der OWASP Top 10; jeder Fund wird mit Schweregrad und Lösungsvorschlag dokumentiert. Erfordert das Schließen einer Lücke Codeänderungen, setzen wir sie selbst um oder beschreiben sie technisch für Ihren eigenen Entwickler.

// Was umfasst präventive Website-Sicherheit?

Präventive Website-Sicherheit besteht aus Schichten, die Angreifern die Arbeit erschweren und den Schaden begrenzen, falls doch ein Angriff gelingt; kein einzelnes Plugin oder Tool leistet das allein. Nach einer Bereinigung oder auf einer bisher nicht angegriffenen Website richten wir folgende Schichten ein.

• Updates: regelmäßige Aktualisierung von Kernsoftware, Bibliotheken, Paketen und Serversoftware; Ersatz verwaister Abhängigkeiten
• WAF und Rate Limiting: eine Firewall, die bekannte Angriffsmuster und Brute-Force-Logins stoppt, bevor sie die Anwendung erreichen
• Security-Header: HSTS für erzwungenes HTTPS, eine CSP, die nur Skripte aus freigegebenen Quellen zulässt, X-Content-Type-Options und Referrer-Policy
• Backup-Strategie: automatische Backups mit mindestens einer Kopie außerhalb des Servers und tatsächlich getesteter Wiederherstellung
• Rechteverwaltung und 2FA: eigenes Konto pro Person, minimale Rechte, Zwei-Faktor-Authentifizierung für Admin-Bereich und Serverzugang

Das Risiko ist nicht nur ein Ausfall: Gelangen Formular-, Konto- oder Bestelldaten nach außen, müssen Sie als Verantwortlicher eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde melden. Deshalb zählen wir bei Websites mit personenbezogenen Daten auch das Vermeiden unnötiger Datenspeicherung und das Führen von Zugriffsprotokollen zur Sicherheit. Zur Backup-Seite unter WordPress siehe WordPress-Backup & Wiederherstellung.

// Was ist enthalten und wovon hängt der Preis ab?

Der Umfang teilt sich in Notfalleinsatz und präventive Härtung; beides ist einzeln oder zusammen buchbar. Die Tabelle zeigt, welche Leistung wozu gehört.

Vier Faktoren bestimmen den Preis: die Plattform, wie weit sich die Infektion in Dateien und Datenbank ausgebreitet hat, der Umfang des Serverzugriffs und ob die Website auf Google- oder E-Mail-Blacklists steht. Bei einer kleinen Website mit einem einzigen Einstiegspunkt rechnet sich der Aufwand in Stunden; eine monatelang unbemerkte Infektion mit Tausenden Spam-Seiten braucht länger. Die Erstprüfung ist kostenlos, das Angebot wird danach fest und steigt später nicht.

// Mit welchen Plattformen arbeiten wir?

Wir arbeiten mit individueller PHP-Software, Node.js- und Next.js-Anwendungen, statischen HTML-Websites, REST-API-Integrationen und WordPress/WooCommerce. Statische Websites bieten wenig Angriffsfläche, Server- und FTP-Zugang bleiben aber ein Risiko; bei dynamischen Anwendungen prüfen wir zusätzlich Code und Abhängigkeiten.

Läuft Ihre Website mit WordPress, finden Sie WordPress-spezifische Schritte wie Plugin-Lücken, gefälschte Admin-Konten und in Theme-Dateien versteckten Code auf unserer Seite WordPress-Sicherheit & Wiederherstellung. Auf geschlossenen Plattformen wie Wix, Shopify oder Squarespace gibt es keinen Server- und Dateizugriff; dort beschränkt sich unser Spielraum auf Kontosicherheit, Integrationen und eingebundene Skripte – das sagen wir bei der Erstprüfung offen. Geht es nicht um Sicherheit, sondern um Abstürze oder Fehlermeldungen, ist die Website-Fehlerbehebung der bessere Einstieg.

// Beispiele aus unseren Projekten

In den Systemen, die wir entwickeln, ist Sicherheit Teil des Designs und keine nachträglich aufgesetzte Schicht. Die zwei folgenden Projekte zeigen, wo dieser Ansatz bei Systemen mit personenbezogenen Daten und Zahlungen greift.

• AVM Gazette – Ein von uns als Individualsoftware entwickeltes Nachrichtenportal zu Einkaufszentren, Einzelhandel und Gewerbeimmobilien. Es umfasst ein Abonnementsystem und ein KVKK-konformes Cookie-Management; in einem System mit Abonnentendaten ist Datenschutz von der ersten Codezeile an ein Designthema.
• Lisansimo – Ein von uns entwickelter WooCommerce-Shop für digitale Lizenzen. In einem Shop mit Zahlungsablauf bedeutet Sicherheit den Schutz des Checkouts, der Bestelldaten und des Admin-Zugangs.

Wir zeigen diese Projekte als Beispiele für von Anfang an eingebaute Sicherheit, nicht als gehackte oder wiederhergestellte Websites. Im Angriffsfall arbeiten wir nach dem oben beschriebenen Vier-Schritte-Ablauf.

Eine Bereinigung ohne geschlossenen Einstiegspunkt verschafft dem Angreifer nur Zeit für den nächsten Besuch.

// Wer übernimmt die Arbeit – und wann ist sie nicht nötig?

Den Einsatz leitet Caner Zep Çelik, Gründer & Technischer Berater von Zep Bilişim. Seit 2020 hat er an mehr als 100 Projekten für Kunden in Deutschland, dem Vereinigten Königreich und der Türkei mitgewirkt; Server-Logs, Code und Datenbank prüft er selbst und gibt die Arbeit nicht an Subunternehmer weiter. Auch den Ursachenbericht schreibt er selbst.

Gibt es keine Anzeichen, meldet die Search Console keine Sicherheitsprobleme und wird die Software aktuell gehalten, ist kein Notfalleinsatz nötig; eine präventive Prüfung genügt. Erscheint die Browserwarnung „Nicht sicher“ nur, weil das SSL-Zertifikat abgelaufen ist, liegt kein Angriff vor – eine Erneuerung des Zertifikats löst das. Ist das der Fall, sagen wir es Ihnen bei der Erstprüfung offen.

// Häufig gestellte Fragen