Insgesamt kommt mir das alles etwas ungewöhnlich vor was und wie hier berichtet wird. Fast so als wären die Antworten und Zusammenfassungen von einer KI erstellt worden. Aus anderen Beiträgen kenne ich es eher so, dass beim Wiederonline Nehmen problematischer Web/VPS über den Support eher umständlich ist und nicht umgekehrt.
KRITISCH: Gehacktes Webhosting – Support reagiert nicht
-
Stencil -
27. März 2026 um 14:05 -
Erledigt
-
-
Gabs nicht im WCP die Möglichkeit, das Webhosting komplett zurückzusetzen?
Ich glaube, hier wird das eigentliche Risiko unterschätzt: Wenn ich als rechtmäßiger User keine Ownership mehr über meine Verzeichnisse habe und chmod fehlschlägt, ist dieser Account auf Systemebene (Root/Kernel) kompromittiert.
Nicht unbedingt.
Wie kommst du denn auf das System, wenn die id_rsa manipuliert wurde? Welchem Nutzer ist die id_rsa zugeordnet, und welche Rechte hat sie (600)? Vielleicht wären ein paar Screenshots hilfreich, um sich mal ein Bild zu machen, wie es überhaupt bei dir aussieht. Welche Prozesse laufen im System?
Im Moment hört sich das alles sehr undurchsichtig an.
-
Wenn ich als rechtmäßiger User keine Ownership mehr über meine Verzeichnisse habe und chmod fehlschlägt, ist dieser Account auf Systemebene (Root/Kernel) kompromittiert.
Bruder..
Wer übernimmt die Verantwortung, wenn dieser Account als Basis für einen größeren Angriff auf netcup-Infrastruktur genutzt wird?
LOL
ast so als wären die Antworten und Zusammenfassungen von einer KI erstellt worden.
+1
-
Dieser Thread zieht zu schnell die falschen Schlüsse:
> In meinem Basisverzeichnis sind plötzlich Systemordner wie .ssh, /bin, /dev, /etc, /lib64, /usr, /var sichtbar.
normal bei Linux Plesk installs, und kein Wunder wenn du diese nicht löschen kannst, sollst du auch nicht.>ssh-keygen wurde vom Angreifer im Verzeichnis abgelegt.
normal bei mir auch vorhanden>Eine unbefugte id_rsa.pub wurde erstellt.
normal wenn man einen Key für Login in Plesk UI hinterlegt hat, eventuell auch schon bevor man es gemacht hat.>Die .htaccess wurde mit FilesMatch Deny from all komplett verriegelt.
normal nach einem Hack, damit nicht gleich zugegriffen wird auf eine gehackte Datei
> Isolation-Breakout: Die rekursiven bin/bin/
Dies ist nicht normal aber eher ein Symlink Loop.
>Gefahr für das Netzwerk: Ein Account, der so tief infiziert ist, dass der User ausgesperrt wird, fungiert als perfektes Sprungbrett (Jump-Host) für Angriffe auf andere Kunden auf demselben Host-System.
naja, eher nicht.
Nun kann es sein, dass ein Wordpress über ein Plugin gehackt wurde und dies kann sich bei einem normalen Hosting unter gewissen Umständen auf andere Domains im selben Dokumentenordner auswirken. Die Domains sind nicht abgeschottet. Dazu bedarf es eines separaten Tarifs. Kunden sollten immer ihr Hosting Package besitzen mit der Domain.
Weiters kann es auch ein geläufiger Plesk Hack sein, der schwer zu entfernen ist. Dabei trägt sich der Hacker in den Cronjob ein und repliziert sich selbst.
Hierzu 3 Links:
-
Du kannst selber eine php datei machen, die einfach nur die liste betreffenden Dateien per exec löschen kann und per Cronjob aufrufst, dann hast du dieselben Rechte wie der Hacker.
Sollte so gehen. Feuer mit Feuer.
Auch kannst du http Ordner mal auf Rechte 0400 setzen, dann kann der Angreifer nichts dort schreiben oder aufrufen.
Die htaccess mit Deny hilft auch.
Der Hoster den Account resetten muss? Ich weiß nicht, ob dies gerne gemacht wird. Könnte auch andere Domains, die dem Hosting zugewiesen wurden betreffen. Customerpanel und Webhostingpanel sind ziemlich verwoben.
Aber falls du dazu die Konditionen erfährst teile es hier mit. -
Cronjobs kannst Du in Plesk sehen und auch löschen. Hast Du dort bei Geplante Aufgaben schon einmal nachgeschaut?
Was die nicht löschbaren Dateien angeht, ist eine finale Beurteilung aus der Ferne natürlich schwierig. Ich persönlich würde an Deiner Stelle (nochmals) die Fehlermeldungen, insbesondere die vom Dateimanager in Plesk, einmal 1:1 dem Support schicken und um Löschung dieser Dateien bzw. Ordner bitten. Erwähne nochmals explizit, dass Du offenbar keine Zugriffsrechte zum Löschen hast und das Ticket an die Fachabteilung weitergeleitet werden soll. Selbstverständlich solltest Du da nicht Systemordner wie /bin, /etc oder /usr erwähnen. Die müssen erhalten bleiben, das ist normal.
-
- Hilfreichste Antwort
File Diagnosis without delete:
PHP
Alles anzeigen<?php declare(strict_types=1); $files = [ '/path/to/file1.php', '/path/to/file2.php', ]; function runCmd(string $cmd): array { $output = []; $code = 0; exec($cmd . ' 2>&1', $output, $code); return ['code' => $code, 'output' => implode("\n", $output)]; } header('Content-Type: text/plain; charset=utf-8'); foreach ($files as $file) { echo "=== $file ===\n"; if (str_contains($file, "\0")) { echo "Invalid path\n\n"; continue; } $exists = file_exists($file); echo "exists: " . ($exists ? 'yes' : 'no') . "\n"; if (!$exists) { echo "\n"; continue; } clearstatcache(true, $file); echo "is_file: " . (is_file($file) ? 'yes' : 'no') . "\n"; echo "is_writable: " . (is_writable($file) ? 'yes' : 'no') . "\n"; echo "owner_uid: " . @fileowner($file) . "\n"; echo "group_gid: " . @filegroup($file) . "\n"; echo "perms_octal: " . substr(sprintf('%o', @fileperms($file)), -4) . "\n"; $quoted = escapeshellarg($file); $ls = runCmd("ls -ld " . $quoted); echo "ls -ld:\n" . $ls['output'] . "\n"; $lsattr = runCmd("lsattr -d " . $quoted); echo "lsattr:\n" . $lsattr['output'] . "\n"; $stat = runCmd("stat " . $quoted); echo "stat:\n" . $stat['output'] . "\n"; echo "\n"; } -
Wenn alles im ganzen Account runter ist was man noch braucht, könnte ein Cronjob mit rm -rf / helfen
-
Delete list of files. Use with cronjob to elevate permission.
PHP
Alles anzeigen<?php declare(strict_types=1); /* * Safe file cleanup script * - No shell exec * - Deletes only files inside a fixed base directory * - Uses relative paths only * - Logs results */ $baseDir = '/var/www/app/storage/tmp'; $filesToDelete = [ 'old-cache-1.tmp', 'old-cache-2.tmp', 'stale/report.json', ]; $baseRealPath = realpath($baseDir); if ($baseRealPath === false || !is_dir($baseRealPath)) { http_response_code(500); exit("Base directory is invalid.\n"); } $results = []; foreach ($filesToDelete as $relativePath) { $entry = [ 'file' => $relativePath, 'status' => 'unknown', 'message' => '', ]; if ($relativePath === '' || str_contains($relativePath, "\0")) { $entry['status'] = 'skipped'; $entry['message'] = 'Invalid path.'; $results[] = $entry; continue; } if (str_starts_with($relativePath, '/') || preg_match('/^[A-Za-z]:[\\\\\\/]/', $relativePath)) { $entry['status'] = 'skipped'; $entry['message'] = 'Absolute paths are not allowed.'; $results[] = $entry; continue; } $candidate = $baseRealPath . DIRECTORY_SEPARATOR . $relativePath; $resolvedDir = realpath(dirname($candidate)); if ($resolvedDir === false) { $entry['status'] = 'skipped'; $entry['message'] = 'Parent directory does not exist.'; $results[] = $entry; continue; } $normalizedPath = $resolvedDir . DIRECTORY_SEPARATOR . basename($candidate); if ( $normalizedPath !== $baseRealPath && !str_starts_with($normalizedPath, $baseRealPath . DIRECTORY_SEPARATOR) ) { $entry['status'] = 'skipped'; $entry['message'] = 'Path escapes base directory.'; $results[] = $entry; continue; } if (!file_exists($normalizedPath)) { $entry['status'] = 'skipped'; $entry['message'] = 'File does not exist.'; $results[] = $entry; continue; } if (!is_file($normalizedPath)) { $entry['status'] = 'skipped'; $entry['message'] = 'Not a regular file.'; $results[] = $entry; continue; } if (!is_writable($normalizedPath)) { $entry['status'] = 'skipped'; $entry['message'] = 'File is not writable.'; $results[] = $entry; continue; } if (@unlink($normalizedPath)) { $entry['status'] = 'deleted'; $entry['message'] = 'File removed successfully.'; } else { $entry['status'] = 'failed'; $entry['message'] = 'unlink() failed.'; } $results[] = $entry; } header('Content-Type: application/json'); echo json_encode($results, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES) . PHP_EOL; -
Ob die KI es schafft die 2 PHP Files vor dem Ausführen anzupassen?
Sorry, ich verstehe ja das man KI zur Unterstützung und Hilfe hernimmt, man sollte aber verstehen was die KI gerade so für Halluzinationen hat.
Und dann noch ganze Beiträge von der KI schreiben lassen, mit der Fütterung von den Antworten im Thread geht echt zu weit und wir können hier einen Chatbot einpflanzen der sich mit dir unterhält.
-
Du solltest oben mit Thema bearbeiten / erweitert den Threadtitel ändern auf "Gehacktes Webhosting", oder ähnlich.
Der Titel enthält aktuell die falschen Rückschlüsse hinsichtlich der Unzulässigkeit von ganz normalen Systemordnern. -
Ob die KI es schafft die 2 PHP Files vor dem Ausführen anzupassen?
Sorry, ich verstehe ja das man KI zur Unterstützung und Hilfe hernimmt, man sollte aber verstehen was die KI gerade so für Halluzinationen hat.
Und dann noch ganze Beiträge von der KI schreiben lassen, mit der Fütterung von den Antworten im Thread geht echt zu weit und wir können hier einen Chatbot einpflanzen der sich mit dir unterhält.
Die Fehlermeldungen waren ja auch schon KI geschrieben
Aber die Vorgehensweise für diese nervige Malware ist schon richtig. -
Ich habe bei dir in einem Beitrag den Datenbanknamen „joomla“ gelesen. Nutzt du in deinem Joomla das Astroid Framework? Da gibt es gerade die CVE-2026-21628 mit Score 10 also sehr kritisch.
Darüber laden Angreifer Remote Shells hoch und übernehmen Webspaces, so wie wahrscheinlich bei dir geschehen.
Die anderen im Thread fragen nicht ohne Grund nach dem kompletten ls-Output. Ich habe bis jetzt immer nur Rechte-Nummer (0644) gesehen. Die Frage ist aber generell, wem gehören alle Dateien?
Es könnte sein wenn so eine Datei über die Webseite hochgeladen wird, dass sie dem www-user gehört, während du möglicherweise als Plesk User drin bist, und die Dateien des anderen Users nicht anfassen darfst. Was ich nicht weiß, könnte sein das Netcup einen Virenscanner hat, und die Datei bereits weggesperrt hat.
Vielleicht kann dir die KI dabei helfen.
Eine andere Idee wäre, Supports sind meist in mehrere Stufen unterteilt. 1st Level könnte mit Textbausteinen umeinander werfen. Verlange mal, dass das Ticket an das nächst höhere Level eskaliert wird, mit dem Wortlaut das nach einem Incident etwas schadhaftes auf dem Space liegt mit möglicherweise anderen Benutzerrechten (vorher prüfen) oder ein möglicher Virenscanner hat das gesperrt.
Löschen ist immer eine schwierige Sache, sie sollen die Benutzerrechte anpassen/reparieren wenn das wirklich so ist, und ein mögliches immutable entfernen. Danach solltest du es selbst löschen dürfen/können.
Schau auch, dass das Joomla von außen nicht erreichbar ist, nicht dass Remote ein Bot drauf sitzt und möglicherweise die Rechte sofort wieder umschreibt, wenn in der .htaccess aber
deny from all drin steht ist es möglicherweise eh verriegelt. -
-
-
Das Gute an diesen Infektionen und CVE's ist dass man dafür jetzt kein Abitur mehr braucht. Jedes Skript Kiddie kann sehr bald mit der delusional KI solche feindlichen Übernahmen masterminden. Goldene Zeiten für statische Seiten. Mark my words.
-
Fast so als wären die Antworten und Zusammenfassungen von einer KI erstellt worden
Nicht nur fast. Stil und auch "Formatierung" ganz eindeutig K"I"-generiert.
-
Das Gute an diesen Infektionen und CVE's ist dass man dafür jetzt kein Abitur mehr braucht. Jedes Skript Kiddie kann sehr bald mit der delusional KI solche feindlichen Übernahmen masterminden. Goldene Zeiten für statische Seiten. Mark my words.
Don't feed the troll"
-
Stencil
29. März 2026 um 16:29 Hat den Titel des Themas von „KRITISCH: Chroot-Breakout? Verzeichnisse /bin, /etc, /dev in meinem Webhosting sichtbar – Support reagiert nicht“ zu „KRITISCH: Gehacktes Webhosting – Support reagiert nicht“ geändert. -
Meine Ziele:
Die Wiederherstellung meiner administrativen Handlungsfähigkeit.
Einen vollständigen Full-Wipe (Reset) des Accounts, da eine manuelle Bereinigung unter diesen Umständen technisch unmöglich und unsicher ist.Ich vermute, das kann man auch Support erreichen. Allerdings diskutieren wir hier immer noch quasi ohne belastbare Information, wie es bei dir auf dem System aussieht und welche Versuche du wie unternommen hast. Von daher wird es schwer.
-
Don't feed the troll"
are you talking to me? who the hell you talking to? .... well, I dont see anyone else here so ... you talking to me?
