KRITISCH: Gehacktes Webhosting – Support reagiert nicht

    Zitat von hackuni

    Derzeit ist der gesamte Webspace nicht nutzbar. Mir hatte jemand via PN geholfen und so weit so gut, es mussten Rechte geändert werden nun kommt man nicht mehr auf den http.... Ordner vom gesamten Webspace. Die Malware wurde immer wieder über eine spezielle Domain nachgeladen. Auch das löschen der befallenen Dateien hat nix gebracht.

    Ich denke mehr als hoffen das der Support sich dem Problem animmt und alles neu aufsetzt habe ich nicht. Das war bislang 5 Monate umsonst zahlen :(. Hoffentlich geht die Geschichte noch gut aus.

    >alles neu aufsetzt habe ich nicht
    Also hast du noch das gehackte Wordpress drauf? Dann ist es kein Wunder wenn es sich immer wieder infiziert.
    Es ist viel mehr befallen als du glaubst. Und es gibt noch die Lücke wodurch es angefangen hat.

    Zitat von hackuni

    Derzeit ist der gesamte Webspace nicht nutzbar. Mir hatte jemand via PN geholfen und so weit so gut, es mussten Rechte geändert werden nun kommt man nicht mehr auf den http.... Ordner vom gesamten Webspace. Die Malware wurde immer wieder über eine spezielle Domain nachgeladen. Auch das löschen der befallenen Dateien hat nix gebracht.

    Ich denke mehr als hoffen das der Support sich dem Problem animmt und alles neu aufsetzt habe ich nicht. Das war bislang 5 Monate umsonst zahlen :(. Hoffentlich geht die Geschichte noch gut aus.

    Das löschen wird nichts bringen, solange nicht die Ursache behoben wurde. Kannst du dich nicht in der Oberflächen anmelden und einfach mal alles löschen?

    Zitat von MyMattes

    Danke dafür, dass Du mit Deinem verantwortungslosen Verhalten beim Aufbau von Bot-Farmen unterstützt, damit Spammer und DDoSer genügend Resourcen haben. Ohne Worte…

    Ist ja nicht mein fehler gewesen sondern das Plugin hatte eine schwachstelle. Die zwar behoben wurde aber teilweise injectionen schon vorhanden waren. Das war also nicht mein Verschulden


    Nun ist erstmal alles gelöscht und ich Ziehe meinen Space wieder auf einen anderen Webspace da ist für jemand der einfach nur eine Webseite haben möchte und kein Itler sein möchte angenehmer. Danke Euch

    Zitat von hackuni

    Ist ja nicht mein fehler gewesen sondern das Plugin hatte eine schwachstelle.

    NATÜRLICH ist das deine Schuld. Denn ist deine Verantwortung als Administrator, deine Webseite auf dem aktuellen Stand zu halten und Sicherheitslücken umgehend zu schließen - wie auch immer. Wenn es kein Update gibt, musst du das entsprechende Plugin deaktivieren. Wenn du dem nicht nachkommen kannst - aus Zeitgründen oder warum auch immer - dann solltest du keine Webseite betreiben.

    was ich ja getan habe, aber vll war es so ein gekauftes Plugin. Ich habe aber nichts mitbekommen was da sein sollte. Auf dem Alten Space war ja auch nichts. Also wie soll man dann solche Dinge raus finden. Kannst du mir da helfen?

    Ja über die Plugin oberfläche, habe ja auch so ein WP Managment System Mainwp . Wurde alles immer Aktuell gehalten. Allerdings kann es ja dennoch sein das da jemand schlechten Code produziert hat oder oder.

    Naja das Kind ist ja im Brunnen anstelle zu reden warum wie, versuch ich gerade eher wie Lebend rausholen

    Wichtig ist zu verstehen, dass die Anzahl der Plugins so gering wie möglich gehalten werden muss. Viele einfache Funktionen können ganz einfach in der functions erfolgen. Damit verringern sich die Angriffspunkte enorm. Genau hier liegt aber das Probleme. Es gibt für jeden Müll ein Plugin. Ich habe Wordpress Installationen von "Agenturen" gesehen, die hatten mehr als 40 Plugins im Einsatz. Die Hälfte der Plugins war vollkommen überflüssig. Ist aber halt einfach, schnell mal ein Plugin zu installieren.

    Die Infektion war auch schon auf der alten Seite und im Backup enthalten, ich habe von hackuni Zugriff aufs SSH bekommen und bin dran mit Ihm die Bereinigung durchzuführen, hierfür muss aber erstmal PHP von Ihm deaktiviert werden. Hier mal die KI unterstütze Analyse:

    Symptome

    • index.php im Webroot ist stark vergrößert (tausende Zeilen statt 2)
    • Unbekannte Verzeichnisse unter wp-content/ mit Zufalls-Hash-Namen (z.B. wp-content/ad6ccaf1/)
    • Darin: index.php oder edit.php mit obfuskiertem Code
    • Löschen hilft nicht – Dateien erscheinen nach wenigen Sekunden wieder
    • Im Access-Log: massenhaft 200 OK auf URLs die nicht existieren (/items/involved/123.htm, /goods.php?detail/...)
    • Alle diese Responses haben exakt dieselbe Byte-Größe

    Infektionskette (vereinfacht)

    Code
    httpdocs/index.php              ← Stufe 1: SEO-Cloaker + Trigger
    └── wp-content/[hash]/*.php ← Stufe 2: Remote-Code-Loader
            └── C&C-Server      ← Stufe 3: Web-Shell (im RAM, nie auf Disk)

    Stufe 1: index.php – SEO-Cloaker

    Die echte WordPress-index.php (normalerweise 2 Zeilen) wurde durch eine massiv obfuskierte Version ersetzt.

    Obfuskierungstechniken:

    • Hunderte goto-Sprünge um den Kontrollfluss zu verschleiern
    • Alle Strings als Oktal/Hex-Escape-Sequenzen ("\x47\x45\x54" = "GET")
    • C&C-Domain rückwärts eingebaut + per strrev() zur Laufzeit zusammengesetzt
    • Zusätzlich alle Zeichen um -5 verschoben (ASCII-Verschlüsselung)

    Was der Code macht:

    1. Prüft ob Besucher ein Suchmaschinen-Bot ist (Googlebot, Bingbot, Baidu, Yandex...)
    2. Für normale Nutzer: lädt WordPress normal
    3. Für Bots: liefert gefälschte Shop-Seiten mit JS-Redirect auf Spam-Domains aus
    4. Baut bei jedem Request den C&C-Server-Hostname zusammen und ruft Stage 2 auf
    5. Kann Google-Verifikationsdateien ins Webroot schreiben (Domain-Hijacking in Search Console)
    6. Exfiltriert das komplette $_SERVER-Array an den Angreifer

    Stufe 2: wp-content/[hash]/*.php – Stage-2 Loader

    Diese Dateien sind der eigentliche Regenerator. Solange sie aktiv sind, wird alles andere nach dem Löschen sofort neu erstellt.

    Zwei Varianten gefunden:

    Variante A (edit.php) – Voller HTTP-Client:

    • Baut URL rückwärts zusammen: https://*/1ser.txt
    • Holt PHP-Code vom C&C (cURL, Fallback: raw TCP-Socket)
    • Tarnt sich als echter Chrome-Browser (User-Agent-Spoofing)
    • SSL-Zertifikat-Verifikation deaktiviert
    • eval() auf den heruntergeladenen Code

    Variante B (index.php) – Backup-Loader:

    • Anderer C&C: https://*/tt.txt
    • Bewusst redundant – fällt Server A aus, übernimmt Server B

    Stufe 3: tt.txt – die eigentliche Payload (Web-Shell)

    Das ist der gefährlichste Teil. Die Datei auf dem C&C-Server enthält:

    PHP
    <?php
// Passwortschutz (doppeltes SHA256)
if (hash('sha256', hash('sha256', $_POST['pwdyt'])) == '[hash]') { ... }

// Komprimierte Web-Shell (~35KB gzinflate)
$ULTRA = "eJwB...";

// Triple-kodierter eval:
@eval(base64_decode(base64_decode("\x57\x6c..."))); 
// → eval(gzinflate(base64_decode($ULTRA)));

    Die Web-Shell wird nie auf Disk geschrieben – sie läuft ausschließlich im PHP-Prozess-Speicher. Enthält nach Analyse:

    • File Manager (lesen/schreiben/löschen)
    • Shell-Command-Execution
    • PHP-eval-Interface
    • SQL-Client (direkter Datenbankzugriff)
    • File-Upload
    • Reverse-Shell-Funktionalität

    ArtCore7 hast du schon mal ne Wordpress Installation von Schadcode bereinigt? Eine KI‑Unterstützung kann sicherlich behilflich sein, es kommt aber immer auf den jeweiligen Fall an. Ich bin der Meinung, dass auch ein gewisser Erfahrungswert hierbei ganz wichtig ist.

    Hier gibt es keine Wordpress Installation zu bereinigen, da keine Wordpress Installation da - Nur der PHP Prozess der aktiv nachliefert. Deswegen muss hier vor der Bereinigung erst mal der PHP Prozess der immer wieder nachschiebt beendet werden. Und ja ich habe ein wenig Hintergrund mit IT-Security und Bereinigung von befallenen Endgeräten. Ich hab nur keine Lust die Zusammenfassung manuell zu machen oder eine "De-Obfuskierung" von Hand durchzuführen, wenn man die Arbeit abgeben kann. <- Und hier kostenlos unterstützt.

    Hier geht es aber nicht um die Bereinigung von irgendwelchen aktiven Installation, sondern erst mal wieder das Webhosting bereinigt hinzustellen.

    Denke es klappt so in 60 Sekunden:

    1) httpdocs umbenennen auf httpdocs_
    Nun kann der Hack nicht mehr zugreifen oder etwas neu schreiben

    2) Alle Dateien verschieben in einen anderen Ordner. Es ist davon auszugehen, dass alle Webseiten infiziert sind.

    3) Dann PHP Version wechseln, dies startet PHP FPM neu und ist die einzige Möglichkeit die uns netcup gibt.
    Nun kann er nicht mehr aus dem Ram einen neuen Hack schreiben

    4) Nun wieder httpdocs_umbenennen auf httpdocs

    5) Nun neu installieren