Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Webshells sind nicht auf alte Familiennamen beschränkt. Moderne Vorfälle können inaktive cookie-gesteuerte Loader, in legitime Dateien eingebettete Backdoors, Cron-basierte Wiederherstellung, Datenbank-Hacklinks und crawler-spezifisches Cloaking enthalten. Der Schwerpunkt liegt auf Erkennung und Abwehr, nicht auf Angriffscode.
CISA und MITRE ATT&CK führen Webshells als T1505.003. Da Webserver ohnehin erreichbar sind, kann eine bösartige serverseitige Komponente im normalen Anwendungsverkehr verborgen bleiben und nach dem Erstzugriff Persistenz bieten.
Dateinamen allein reichen nicht. Unauffällige Namen oder wenige eingefügte Zeilen in legitimen Dateien sind möglich. Integrität, Änderungszeit, URL-Zugriffe und Laufzeitverhalten gemeinsam prüfen.
Microsoft dokumentierte 2026 PHP-Webshells in Linux-Hosting-Umgebungen, die im normalen Verkehr inaktiv blieben und erst bei bestimmten Cookie-Bedingungen aktiv wurden. Teilweise wurden Funktionsnamen erst zur Laufzeit rekonstruiert.
Daher Dateisignaturen mit Verhaltenssignalen kombinieren: Webprozess startet Shell, Cron schreibt PHP ins Webverzeichnis, ungewöhnliche Panel-Aufgabe oder auffällige Request-Muster.
base64_decode, gzinflate oder dynamische Aufrufe sind allein kein Malware-Beweis. Kritisch wird die Kombination aus starker Verschleierung, nicht vertrauenswürdiger Eingabe, Execution-Sink, unerwarteter Änderung und ungewöhnlichem Pfad.
Hashes und Datenfluss prüfen, unbekannte Payloads nicht auf Production ausführen.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
sha256sum public_html/supheli.phpgrep -nE "\$_(GET|POST|COOKIE|REQUEST|SERVER)|eval|base64_decode|gzinflate|shell_exec|system|exec|passthru|proc_open" public_html/supheli.phpphp -l public_html/supheli.phpNein. Webshells ermöglichen serverseitige Kontrolle; Hacklinks sind nicht autorisierte SEO-Inhalte/Links. Beide können gemeinsam auftreten, benötigen aber unterschiedliche Bereinigung.
Hacklinks können in Theme-Dateien, Datenbank-Optionen, JavaScript oder crawler-spezifischem HTML liegen. Google nennt versteckte Links und Cloaking als Spam-/Hacked-Content-Muster.
Google weist darauf hin, dass gehackte Redirects von Referrer, User-Agent oder Gerät abhängen können. Direkter Aufruf kann normal wirken, während ein Suchklick umleitet.
Antworten in kontrollierten Kontexten vergleichen und CDN-Cache berücksichtigen. Ziel ist Konsistenzprüfung, nicht die Reproduktion schädlicher Aktivität.
Wenn nur die sichtbare Shell entfernt wird, kann ein anderer Mechanismus sie zurückbringen. Cron, auto_prepend_file, Rewrite-Regeln, Plugins, Bootstrap-Dateien und Panel-Zeitpläne prüfen.
Häufige Jobs mit Schreibzugriff in Webroot oder Decode/Download-Tools prüfen, aber legitime Wartung berücksichtigen.
crontab -lgrep -RIn "auto_prepend_file\|auto_append_file" /home /var/www 2>/dev/nullfind public_html -type f -mmin -60 -printDatei-, Request-, Prozess- und Persistenzsignale kombinieren. Verdächtige Funktion plus passender POST, Webprozess→Shell und neuer Cronjob im selben Zeitfenster sind deutlich stärker als ein einzelner codierter String.
Wenn möglich mit offiziellen Checksums oder einem sauberen Repository vergleichen.
Skriptausführung in Upload-Verzeichnissen sperren, Uploads außerhalb des Webroots ablegen, minimale Dateirechte, MFA, aktuelle Runtime/Frameworks, WAF und sichere Upload-Prüfung einsetzen.
OWASP empfiehlt mehrere Upload-Schutzschichten: Allowlist, serverseitige Typ-/Signaturprüfung, generierte Namen, Limits, Autorisierung und sichere Speicherung.
Bericht mit verdächtigen Dateien/Hashes, geänderten Dateien, Persistenz, Hacklink/Cloaking, Log-Zeitachse, Anwendungsrisiken und Maßnahmen.
Unbekannte Payloads werden nicht auf Production ausgeführt; dynamische Prüfung erfolgt nur auf ausdrücklich autorisierter isolierter Kopie.
PHP-Ausschnitt einfügen; grundlegende defensive Indikatoren werden nur in diesem Browser-Tab geprüft. Der Code wird nicht hochgeladen und das Ergebnis ist kein Malware-Urteil.
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.
Historische Namen gibt es weiterhin, aber eigene Loader und eingebettete/bedingt aktive Backdoors können wichtiger sein.
Nein. Kontext, Herkunft, Version und Datenfluss zuerst prüfen.
Nein. Root, Plugin, Theme, Cache, Vendor oder legitime Datei sind möglich.
Ja. Quelle kann Datei, Datenbank, JavaScript oder Cloaking sein; Indexbereinigung ist separat.
Ja. Deshalb sind Verhalten und Logs wichtig.
Der Job kann die gelöschte Datei erneut erzeugen.