Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Unbekannte PHP-Dateien, nach dem Löschen zurückkehrende Shells, Wett-/Casino-Snippets bei Google, unerwartete Weiterleitungen, ungewöhnliche CPU-Last oder fremde Administratorkonten haben nicht automatisch dieselbe Ursache. Dieser Leitfaden trennt Symptome von Belegen und korreliert Dateisystem, Anwendung, Datenbank, Hosting-Konten und Zugriffslogs auf einer gemeinsamen Zeitachse.
Bei einem aktiven Vorfall nicht sofort alles löschen. Zuerst Auswirkungen begrenzen und Beweise sichern: vollständige Dateikopie, Datenbank-Dump sowie verfügbare Web-, WAF- und Panel-Logs exportieren, bevor Zeitstempel oder rotierte Logs verloren gehen.
Unkontrollierte Tests auf Production vermeiden. Verdächtige Dateien in Quarantäne kopieren, eine saubere Version im Staging prüfen, Hosting-, FTP/SFTP-, SSH-, Datenbank- und CMS-Zugangsdaten ändern, unbekannte Sitzungen widerrufen und MFA aktivieren.
Unerwartete .php/.phtml-Dateien, ausführbare Skripte in Upload-Verzeichnissen, wiederholte Änderungen an .htaccess/.user.ini, zurückkehrende Dateien, unbekannte Cronjobs, neue Admins und unerklärte externe Links sind wichtige Untersuchungssignale.
Eine kompromittierte Website kann im normalen Browser unauffällig wirken. Bedingter Code kann nur auf Referrer, User-Agent, Cookie, Gerät oder Crawler reagieren. Microsoft dokumentierte 2026 cookie-gesteuerte PHP-Webshells in Linux-Hosting-Umgebungen.
Dateien nicht wegen eines einzelnen Schlüsselworts löschen. eval, base64_decode, gzinflate, shell_exec, system oder exec können auch in legitimer Software vorkommen. Entscheidend sind Kontext, externe Eingabe, Verschleierung, Änderungszeit und unerwarteter Speicherort.
Kürzlich geänderte PHP-Dateien, ausführbare Inhalte in upload/cache/tmp, Doppel-Endungen, irreführende Bildnamen, Besitzer und Rechte prüfen. Hashes und Zeitstempel für spätere Log-Korrelation dokumentieren.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
find public_html -type f -name "*.php" -mtime -7 -printfind public_html -type f -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -100find public_html -path "*/uploads/*" -type f \( -name "*.php" -o -name "*.phtml" \) -printgrep -RInE "eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|shell_exec\s*\(" public_html --include="*.php"Dann ist häufig die Persistenz nicht entfernt: Cron, Panel-Zeitplan, .user.ini auto_prepend_file, Rewrite-Regel, bösartiges Plugin, Datenbank-Payload oder zweite Backdoor können die sichtbare Datei neu erzeugen.
Microsoft beschreibt 2026 Hosting-Fälle, in denen geplante Jobs entfernte PHP-Loader erneut schrieben. Eine gelöschte Shell ist daher nicht gleichbedeutend mit einem behobenen Vorfall.
crontab -lfind /home \( -name .user.ini -o -name .htaccess \) 2>/dev/nullgrep -RIn "auto_prepend_file\|auto_append_file" /home 2>/dev/nullfind public_html -type f -mmin -180 -lsGoogle nennt nicht autorisierte Content-Injection, versteckte Links, Cloaking und bösartige Redirects als Muster gehackter Inhalte. Eine Weiterleitung kann nur bei Besuch aus der Suche oder von bestimmten Geräten auftreten.
site:-Abfragen eignen sich zur ersten Sichtprüfung, sind aber kein Malware-Beweis. Search Console, URL Inspection, Sitemap, Canonical, HTTP-Antwort und Quellenausgabe müssen gemeinsam geprüft werden.
site:alanadi.com casinosite:alanadi.com betsite:alanadi.com slotsite:alanadi.com viagraNicht jeder Vorfall beginnt mit einer App-Lücke. Gestohlene FTP-Zugangsdaten, Passwortwiederverwendung oder Session-Diebstahl können dieselben Dateiveränderungen erzeugen. Panel- und Kontobewegungen mit der Dateizeitachse vergleichen.
Nach Passwortwechsel alte Sitzungen, unbekannte API-Tokens und SSH-Keys widerrufen. Bei gemeinsam genutzten Konten oder Zugangsdaten weitere Sites auf demselben Server prüfen.
Hacklinks und Spam stehen nicht immer in einer physischen PHP-Datei. CMS-Optionen, Widgets, Metadaten, Theme-Einstellungen oder eigene Tabellen können HTML/JavaScript dynamisch ausgeben.
Vor Massenänderungen einen Dump erstellen. Verdächtige Domains, Spam-Begriffe, iframe/script-Fragmente und neue privilegierte Benutzer prüfen. Eine universelle SQL-Bereinigung ist wegen unterschiedlicher Anwendungen nicht sicher.
Den ungefähren Erstellungs-/Änderungszeitpunkt einer verdächtigen Datei bestimmen und ein enges Zeitfenster auf POST/PUT, Upload-Endpunkte, erfolgreiche Statuscodes und Folgeaufrufe zur neuen Datei untersuchen.
Eine IP im Log ist ein technischer Indikator, kein Identitätsbeweis. VPN, CDN, Proxy, Botnet oder kompromittierter Host können dazwischenliegen. Zeit, URL, Methode, Kontoaktivität und Dateiveränderung zusammen bewerten.
Keine globalen String-Replacements über alle PHP-Dateien, keine Log-Löschung, keine ungesicherten SQL-Massenänderungen auf Production und nicht nur die sichtbare Shell entfernen.
Wenn saubere Upstream-Versionen oder Versionskontrolle vorhanden sind, damit vergleichen. Bei eigener Software Dateidiffs und kontrollierte Funktionstests nutzen.
Je nach Umfang werden ZIP/Backup, SQL-Dump, cPanel/Plesk-Logs, Search-Console-Nachweise oder ausdrücklich autorisierter SSH-Zugriff verwendet. Statische Analyse, letzte Änderungen, Persistenz, Spam-URL-Verhalten und Log-Zeitachse werden gemeinsam betrachtet.
Nach der Bereinigung erfolgt die kontrollierte Validierung nur auf einer autorisierten Kopie oder im Staging. Der Bericht trennt Artefakte, wahrscheinliche Eintrittspunkte, Restrisiken und Hardening-Maßnahmen; Reindexierung ist ein eigener Prozess.
Dieses Werkzeug läuft im Browser und sendet die Auswahl nicht an den Server. Es ersetzt keine professionelle Prüfung.
Standardfälle werden nach der Vorprüfung normalerweise in ein Analysefenster von 24–72 Stunden eingeplant. Die Dauer hängt von Dateimenge, Logzugriff, Schadcode-Verbreitung und Anwendungsarchitektur ab.
Wichtiger Hinweis: Nur eigene oder ausdrücklich autorisierte Systeme testen.
Nein. Cron, zweite Backdoor, kompromittiertes Konto oder ursprüngliche Lücke können sie erneut erzeugen.
Ja. Cloaking und Cookie-/Header-gesteuerte Logik können bei normalen Besuchen inaktiv bleiben.
Nein. Inhalt kann aus Datenbank, Routing, Rewrite oder crawler-spezifischer Ausgabe kommen.
Vorfallsbezogene IPs lassen sich ermitteln; sie beweisen aber nicht die Identität einer Person.
Nein. Symptom, Plattform, Backup-Status und Beispiel-Logs reichen zunächst.
Nein. Das ist ein Planungsfenster, der Umfang wird nach der Vorprüfung festgelegt.