Mein Hosting wurde gehackt, alle Domains sind betroffen.

    Heute habe ich eine Nachricht von Google Console erhalten, dass sich jemand als Eigentümer meiner Domains registriert hat.

    Er hat dies getan, indem er eine Google-Verifizierungs-HTML-Datei auf mein Hosting hochgeladen hat. Zunächst dachte ich – okay, das muss ein anfälliges WordPress-Plugin sein, aber nachdem ich mich näher damit befasst habe, stellte sich heraus, dass er es geschafft hat, alle meine Domains zu infizieren, darunter auch einige, die nur eine standard HTML-Datei enthielten.

    Das bedeutet, dass der Hacker aus dem Chroot-Jail ausbrechen konnte. Ich kann es nicht anders erklären. Leider muss dies auf Hosting-Ebene behoben werden.

    pasted-from-clipboard.png

    Sicher, dass deine Domains in getrennten Chroot liegen ? Die liegen doch sicher in einem Hosting Paket?

    WordPress, Plugins und Theme alle auf einem aktuellen Stand ? Erster Schritt wäre erstmal alle Passwörter ändern. Anschließend WordPress vom Schadcode befreien

    hi,

    - deine zeile abgetippt und mal das script angeschaut. indonesische sprachfetzen,

    irgendwo jakarta als time zone

    - der github user mit der id hat auch ein asiatisches mädchen als profilbild

    - es gibt eine datei wp-checkbox.php mit dem schönen namen bypass shell

    - dort gibt es einen hex codierten string mail, der "tampungbosgantz@outlook.com" ergibt

    dort wird wohl servername und request uri hingeschickt?

    zuletzt ein neues theme ausprobiert? functions.php darin verseucht?


    nur ganz schnell geschaut. ich kann wp nicht leiden ;)

    Zitat von KBDigital

    Sie sind alle in einem Hosting-Paket, aber sie sollten doch nicht aufeinander zugreifen können, oder verstehe ich das falsch?

    Wenn es um ein Webspace-Produkt geht und Du keine besonderen Maßnahmen getroffen hast, haben Skriptsprachen wie z.B. PHP standardmäßig auf alles im gleichen Webspace eines Kunden Zugriff! Ein eigener Docroot und z.B. open_basedir reichen als Abschottung nicht aus, solange z.B. exec() u.ä. Funktion aktiv sind. Mit einer passenden Sicherheitslücke in einer PHP-Anwendung (RCE o.ä.) bricht ein Angreifer da sofort aus und infiziert alle Websites innerhalb des gleichen Tarifs des Kunden.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    2 Mal editiert, zuletzt von KB19 (17. Januar 2026 um 03:31)

    Zitat von KBDigital

    Leider muss dies auf Hosting-Ebene behoben werden.

    Das wurde 2018 schon erklärt. Die Domains sind nicht abgeschottet. Dazu bedarf es eines separaten Tarifs. Kunden sollten immer ihr Hosting Package besitzen mit der Domain. Mach ich von Hause aus. Staging gehört auf einen VPS.

    WordPress ist ja unsicher by design und der crypto miner hat die Motivations Schwelle in einen Graben verwandelt. Der betrifft ja auch die NodeReactFrameFraktion und das wird noch lustig. Je mehr WordPress Domains innerhalb eines Hosting Paketes desto ROI

    The universe tends toward maximum irony. Don't push it.

    Einmal editiert, zuletzt von webdesignheld (17. Januar 2026 um 08:38)

    Ok- ich meinte eher - im Design ist vorgesehen das man sich in die Seite einloggen kann um was zu aendern.

    let me rephrase that

    CMS is insecure by design


    und ist ja auch nicht schlimm - kann man mit leben. Wenn man ein cms braucht. Und ich denke bei 99% der Webseiten ist wordpress nicht nötig.

    The universe tends toward maximum irony. Don't push it.

    Gestern habe ich alles aus dem Backup wiederhergestellt, die Prüfsummen aller WordPress-Domains überprüft, alle Passwörter geändert, mit Cloudflare den Zugriff nur aus der EU erlaubt und ein Skript geschrieben, das jede Änderung im Dateisystem überwacht und mir heimlich eine Benachrichtigung schickt. Heute Morgen habe ich eine Benachrichtigung erhalten, dass zwei Dateien geändert wurden:

    Code
    🔍 File Integrity Alert

File System Changes Detected
🆕 New Files: 2
• .ssh/id_rsa
• .ssh/id_rsa.pub

    Es scheint, als hätten sie immer noch Zugriff auf Plesk. Ich weiß nicht, wie sie hineingekommen sind, ich habe überall eine Zwei-Faktor-Authentifizierung.

    Die beiden Dateien id_rsa bzw. id_rsa.pub sind ja der private und öffentliche Schlüssel, die man benötigt, wenn man sich von einem System ohne Passwort auf einem anderen System einloggen will. Sie entstehen beispielsweise beim Aufruf von ssh-keygen.

    Die Datei id_rsa.pub könnte man ja mal anschauen, vielleicht steht ein Kommentar drin für den Verwendungszweck.

    Zitat von KBDigital

    Ja, tatsächlich hatte ich selbst keine Key-Authentifizierung eingerichtet.

    also sshkeys sind ja in .ssh/authorized_keys und ich hab auch ein id_rsa und id_rsa.pub in meinem .ssh und ich hab nur die authorized_keys geschrieben - ich wuesste aber nicht wieso ein Intruder die anlegen wuerde oder was er davon haette.

    The universe tends toward maximum irony. Don't push it.