Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Bei Malware, unerwarteten Weiterleitungen, SEO-Spam, unbekannten Administratoren, Backdoors, Phishing-Seiten oder wiederkehrenden Infektionen trennen wir zuerst sichtbare Symptome von der wahrscheinlichen technischen Ebene. Die erste Analyse nutzt öffentlich mögliche Prüfungen; Datei-, Datenbank- oder Serverzugriff wird nur bei notwendiger Tiefenanalyse angefragt.
Für die erste Prüfung benötigen wir kein wp-admin-, FTP-, SSH- oder Hosting-Passwort. Senden Sie die Website-Adresse, eine kurze Fehlerbeschreibung und falls vorhanden einen Screenshot aus Search Console oder dem Hosting-Sicherheitsscanner.
Malware-, Weiterleitungs-, Spam- und Angriffsindikatoren
Unerwartete Weiterleitungen, fremdsprachige Spam-Seiten bei Google, unbekannte Admin-Konten, PHP-Dateien in Upload-Verzeichnissen, veränderte Core-Dateien, schädliches JavaScript, nach Löschung zurückkehrende Dateien, Search-Console-Sicherheitsprobleme, Phishing-Warnungen, unbekannte Cronjobs und ungewöhnlicher Serververkehr können Hinweise sein. Ein einzelnes Signal beweist keinen Hack; Dateien, Datenbank, Konten, Cronjobs, Logs und Serverebene müssen zusammen bewertet werden.
Versteckte Backdoors oder Datenbank-Payloads sind von außen nicht immer erkennbar. Eine öffentliche Analyse zeigt sichtbare Symptome, Weiterleitungen, Browser-Ressourcen und Sicherheitswarnungen. Für definitive Bereinigung sind häufig Dateisystem, Datenbank, Konten, Cronjobs und Serverlogs erforderlich.
Versteckte Backdoors oder Datenbank-Payloads sind von außen nicht immer erkennbar. Eine öffentliche Analyse zeigt sichtbare Symptome, Weiterleitungen, Browser-Ressourcen und Sicherheitswarnungen. Für definitive Bereinigung sind häufig Dateisystem, Datenbank, Konten, Cronjobs und Serverlogs erforderlich.
Dasselbe Symptom kann aus mehreren Ebenen entstehen. Deshalb wird es mit Belegen und Prüfschritten abgeglichen.
| Symptom | Mögliche Ebene | Erste Prüfung |
|---|---|---|
| Website leitet weiter | JavaScript-Injektion, Rewrite, Plugin/Theme, Datenbank oder Edge-Regel | Redirect-Kette, Quellcode und verschiedene Clients |
| Japanische/Chinesische Seiten bei Google | SEO-Spam, Cloaking oder automatisch erzeugte Spam-URLs | site:-Suche, Search Console, Sitemap und Routing |
| Browser meldet betrügerische Website | Phishing/Social Engineering oder schädlicher Inhalt | Search Console Security Issues und Beispiel-URLs |
| Unbekannter Admin erscheint | Unbefugte Kontoerstellung oder Persistence | Benutzerliste, Erstellungszeit, Rollen und Logs |
| Gelöschte Malware kommt zurück | Backdoor, Cron, MU-Plugin, andere Site oder Server-Persistence | Cron, Serverjobs, andere Sites und Logs |
| CPU steigt plötzlich | Bots, Brute Force, Spam, Miner oder schwerer Cronjob | Access-Logs, Prozesse und Cron |
„Malware“ ist kein einzelnes technisches Problem. Entscheidend sind Angriffsart und Persistence.
Versteckter Mechanismus für erneuten Zugriff nach scheinbarer Bereinigung.
Serverseitiges Skript mit Datei- oder Kommandozugriff über die Webanwendung.
Unbefugt erzeugte Glücksspiel-, Pharma-, Fake-Shop- oder fremdsprachige Suchseiten.
Gefälschte Login- oder Zahlungsseiten unter der kompromittierten Domain.
Browsercode für Redirects, Pop-ups, Fake-Formulare oder externe Payloads.
Unbefugtes privilegiertes Konto als dauerhafter Anwendungszugang.
Schädliche Scripts, Links oder Redirects in Datenbankfeldern statt Dateien.
Geplante Aufgaben, die gelöschte Malware neu erzeugen.
Unerwartete Änderungen an Core- oder Repository-Dateien.
Problem außerhalb des CMS, das bereinigte Dateien erneut infizieren kann.
Langsame Seiten, HTTP-500 oder kodierter PHP-Code sind allein kein Malware-Beweis. Befunde müssen mit Herkunft, Zeitstempel, Logs und erwartetem Verhalten abgeglichen werden.
Erstellen Sie eine Zeitlinie: Wann begann das Problem, welche Updates gab es vorher, wurden Admin-/FTP-Konten angelegt und sind weitere Sites im gleichen Account betroffen?
So werden False Positives reduziert und wiederkehrende Infektionen besser erklärt.
Weiterleitungen können nur mobil, aus Google, bei Erstbesuch oder aus bestimmten Ländern ausgelöst werden.
Zu prüfen sind Webserver-Regeln, .htaccess/Nginx, CMS-URL-Werte, Themes, Plugins, MU-Plugins, Konfiguration, Datenbank und Browser-JavaScript.
Nur die Ziel-Domain zu sperren beseitigt die Injektion nicht.
Solche Ergebnisse können auf gehackten SEO-Spam oder Cloaking hinweisen.
Das Entfernen einzelner URLs in Search Console stoppt den Generator nicht; Datei, Rewrite, Datenbank, Plugin oder Backdoor müssen bereinigt werden.
Danach 404/410, Sitemap, Canonical und Security-Issues erneut prüfen.
Google kann Hacked Content, Malware und Social Engineering im Bericht Security Issues anzeigen.
Bei einer Warnung für betrügerische Websites muss zuerst der kompromittierte Inhalt entfernt und die Ursache geschlossen werden.
Beispiel-URLs sind Hinweise und nicht zwingend die vollständige Liste aller betroffenen Seiten.
Backdoors können als PHP-Datei, Plugin-Code, Admin-Konto, Cronjob, SSH-Key oder Servermechanismus existieren.
Nur die vom Scanner markierte Datei zu löschen reicht nicht, wenn Persistence oder Eintrittsweg bestehen bleiben.
Auch eine alte Site im gleichen Hosting-Account kann eine bereinigte Installation erneut infizieren.
WP-CLI kann WordPress-Core-Dateien und Repository-Plugins gegen offizielle Checksums prüfen.
Ein Unterschied ist nicht automatisch Malware; manuelle Änderungen oder fehlgeschlagene Updates können ebenfalls abweichen.
Premium-/Custom-Plugins benötigen einen vertrauenswürdigen Vendor-Download, Repository oder sauberes Backup zum Vergleich.
Medienverzeichnisse enthalten normalerweise keine ausführbaren PHP-Dateien und werden häufig von Angreifern missbraucht.
Nicht jede Datei automatisch löschen; prüfen, ob ein legitimes Plugin sie erzeugt hat.
Nach Bereinigung kann das Ausführen von Scripts im Upload-Verzeichnis abhängig von der Anwendung eingeschränkt werden.
Code kann in Theme-Dateien, Widgets, Options, Page-Builder-Daten oder kompromittierten Third-Party-Tags liegen.
Browser Network/Sources helfen, unerwartete Domains und Ladepfade zu identifizieren.
Bei kompromittiertem Tag-Manager können lokale Dateien sauber aussehen, obwohl Besucher schädlichen Code erhalten.
Scripts, Iframes, Spam-Links oder Redirects können in Options, Posts, Widgets oder Plugin-Tabellen gespeichert sein.
Blindes Suchen/Ersetzen kann legitime Daten zerstören; vorher Backup und Datensatz prüfen.
Nur Dateien zu bereinigen entfernt keine datenbankbasierten Payloads.
Erstellungszeit, E-Mail, Rolle und Logs sichern, bevor ein unbefugtes Konto entfernt wird.
Danach relevante Passwörter rotieren und aktive Sessions ungültig machen.
Bei anfälligem Endpoint oder Backdoor verhindern Passwortänderungen allein keine Neuerstellung.
WP-Cron, Hosting-Cron, System-Crontab und Anwendungsscheduler können für Persistence missbraucht werden.
Auch Laravel Scheduler/Queues und Worker müssen berücksichtigt werden.
Verdächtige Tasks sollten inhaltlich und zeitlich geprüft werden, bevor sie gelöscht werden.
Andere Sites, FTP-Konten, Control-Panel-Accounts, SSH-Keys oder Serverdienste können Reinfektionen verursachen.
Bei dauerhaften Vorfällen muss der Untersuchungsumfang bei entsprechenden Hinweisen über das CMS hinausgehen.
Auf Shared Hosting sind ggf. Logs des Providers erforderlich.
Core, Themes und Plugins aktualisieren, ungenutzte Komponenten entfernen, eindeutige Passwörter und 2FA nutzen und Admin-Rechte minimieren.
Dateirechte, Config-Schutz, Upload-Ausführung und anwendungsspezifische XML-RPC/REST-Anforderungen prüfen.
WAF, Backups, Logs und Integritätsmonitoring ergänzen Patchen und Bereinigung, ersetzen sie aber nicht.
Senden Sie Domain, Symptom, ungefähres Startdatum und vorhandene Security-Screenshots. Für öffentliche Checks benötigen wir kein Passwort.
Wir unterscheiden sichtbare Kompromittierung von Konfigurations-/Anwendungsfehlern und erklären, ob Datei-/Datenbankzugriff nötig ist.
Bereinigung, Backdoor-Entfernung, Datenbankänderungen und Serverlog-Analyse werden bei Bedarf separat definiert.
Diese Beispiele dienen der Verteidigung. Nicht jede gemeldete Datei oder Checksum-Abweichung automatisch löschen.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
wp core verify-checksums --include-rootwp plugin verify-checksums --all --strictwp user list --fields=ID,user_login,user_email,roles,user_registeredwp cron event listfind wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -printfind . -type f -name "*.php" -mtime -7 -printDie Software muss nicht bei uns gekauft worden sein. Mit Quellcode und autorisiertem Zugriff kann das bestehende System bewertet werden.
Core, Themes, Plugins, Benutzer, Cron, Uploads und Konfiguration
WordPress plus Checkout-, Payment-, Webhook- und Bestellintegrität
Extensions, Modifications, Admins, Config und Upload-Fläche
Module, Overrides, Admins, Cache und geänderte PHP-Dateien
Core, Extensions, Templates, Konten und Konfiguration
.env, public/storage, Composer/vendor, Scheduler/Queue und Custom Code
Datei-, Datenbank-, Auth-, Upload-, Cron- und Log-Prüfung nach Anwendung
Bereinigung ist mehr als Dateien zu löschen. Umfang, Eintritt, Persistence und Reinfektionsrisiko müssen zusammen betrachtet werden.
Redirect, Spam, Warnung oder verdächtige Datei verifizieren.
Datei-/DB-Kopie und verfügbare Logs vor destruktiven Änderungen sichern.
Einzelne Site, Hosting-Account, E-Mail oder Serverebene trennen.
Anfällige Komponenten, Konten, Backdoors, Cron und Server prüfen.
Schädliche Inhalte entfernen und schwache Komponenten ersetzen oder aktualisieren.
Anwendung, Hosting, FTP/SSH, DB, Mail und relevante API-Secrets ändern.
2FA, Least Privilege, WAF, Rechte, Backups und Monitoring verbessern.
Integrität, Benutzer, Cron und öffentliches Verhalten erneut kontrollieren.
Für die kostenlose Voranalyse reichen Domain und kurze Fehlerbeschreibung. Beim ersten Schritt benötigen wir kein Passwort. Falls eine Tiefenbereinigung nötig ist, erklären wir Zugriff und Umfang separat.
Für Sicherheitsinhalte verwenden wir bevorzugt offizielle WordPress-/Google-Dokumentation und technische Herstellerdokumentation.
Zeigt die Voranalyse auf Sicherheit, Anwendung oder eine andere Ebene, finden Sie hier passende Dienste.
Die häufigsten Symptome und Fragen mit direkten Antworten.
Sichtbare Redirects, Spam und Warnungen können extern geprüft werden; versteckte Backdoors oder Datenbank-Payloads benötigen ggf. autorisierten Zugriff.
Nein. Domain und Fehlerbeschreibung reichen für die erste Voranalyse.
Ja, wenn Quellcode und erforderlicher autorisierter Zugriff vorhanden sind.
Nein. Auch Fehlkonfigurationen oder legitime Redirect-Regeln sind möglich.
Das kann auf gehackten SEO-Spam oder Cloaking hinweisen. Der Generator muss entfernt werden, nicht nur einzelne URLs.
Zuerst schädliche oder Phishing-Inhalte entfernen und die Ursache schließen, danach den Security-Review-Prozess in Search Console nutzen.
Backdoor, Cronjob, unbekanntes Konto, andere Site oder Server-Persistence können bestehen bleiben.
Nein. Scanner können individuelle, datenbankbasierte oder serverseitige Persistence übersehen.
Nein. Auch legitime Software nutzt Encoding. Quelle und Kontext müssen geprüft werden.
Zuerst untersuchen. Sie sind verdächtig, können aber in seltenen Fällen legitim erzeugt worden sein.
Alle zum Incident gehörenden Credentials sollten entsprechend dem Umfang rotiert werden.
Nein. Cloudflare kann Traffic/WAF schützen, bereinigt aber keine infizierten Dateien oder Datenbankeinträge.
Nein. Updates, 2FA, Least Privilege, vertrauenswürdige Software, Backups, Logs und Monitoring gehören ebenfalls dazu.
Ja. Herkunft und Integrität sind nicht zuverlässig verifizierbar und Updates fehlen oft.
Für Beweissicherung, Vergleich und Rollback. Eine infizierte Kopie darf nicht blind in Produktion zurückgespielt werden.
Nicht wenn die Schwachstelle bleibt; zudem können aktuelle Bestellungen oder Nutzerdaten verloren gehen.
Nein. Die Ursache, die diese URLs erzeugt, muss bereinigt werden.
Ja. Webshells oder kompromittierte Scripts können Mailfunktionen missbrauchen; Mailkonten können separat kompromittiert sein.
Nein. Traffic, Bots, Cronjobs und schwere Queries können ebenfalls Ursache sein.
Nein. Es werden keine unautorisierten Exploits oder Brute-Force-Angriffe durchgeführt.
Umfang, Plattform, Dateimenge, Persistence, Serverzugriff und Loganalyse unterscheiden sich stark.
Ja. Ein Kauf bei Eka Sunucu oder Eka Yazılım ist nicht erforderlich, wenn autorisierter Zugriff und Quellcode verfügbar sind.
Erst nachdem Malware, Persistence und Schwachstelle wirklich bereinigt und erneut geprüft wurden.
Nein. HTTPS verschlüsselt die Verbindung, schließt aber keine Anwendungs- oder Konto-Schwachstellen.
Domain, Symptom, ungefähres Startdatum und vorhandene Search-Console-/Hosting-Warnung. Beim ersten Schritt keine Passwörter senden.
Für die kostenlose Voranalyse reichen Domain und kurze Fehlerbeschreibung. Beim ersten Schritt benötigen wir kein Passwort. Falls eine Tiefenbereinigung nötig ist, erklären wir Zugriff und Umfang separat.