Wie gesagt, das kann sonst ein FTP Client in deinem System gewesen sein. Da kommen eindeutig FTP Puts von deiner IP, und in den hochgeladenen Dateien waren deine Zugangsdaten. Es spricht einiges dafür, dass die aus deinem Server kamen.
Das ist aber offenbar eine IP-Adresse eines (Shared) Webhosting-Servers. Ist aber zugegebenermaßen unwahrscheinlich, dass die Anfragen von einen anderen Kunden kamen...
Ist aber zugegebenermaßen unwahrscheinlich, dass die Anfragen von einen anderen Kunden kamen...
Ich hätte halt keine Erklärung dafür, dass die Dateien vom TE übertragen wurden ... außer, der Host ist involviert.
Moin,
wenn ich das richtig sehe, nutzt du doch ein shared Webhosting von Netcup. Somit zeigt dieser Log, ohne weitere Infos lediglich, dass diese Pakete von dem Netcup-Server versendet wurden, der auch deine Website hosted.
Da bei der anderen Seite nun anscheinend deine Login-Daten vorliegen, klingt es zwar zunächst plausibel, kann aber nicht 100% bestätigt werden, dass der Zugriff von deinem Hosting-Paket erfolgte.
Den Vorschlag alle Logs zu sichern halte ich so oder so für äußerst sinnvoll.
EDIT: Da habe ich wohl etwas langsamer als meine "Vorredner" getippt
ja klar kann das via angreifbares plugin geschehen sein.
und wo stehen denn deine zugangsdaten?!
Alles anzeigenMacht ja alles Sinn was ihr schreibt.
Dass mein Wordpress irgendwie gehackt wurde, ok.
Aber, dass jemand/ein Bot sowohl an meine Wordpress-Zugangsdaten als auch die FTP-Zugangsdaten des anderen Unternehmens kommt, will nicht in meinen Kopf.
Ich hatte tatsächlich noch nie in meinem Leben den Fall, dass jemand irgendwo meine Zugangsdaten gehackt hätte. Aber gut, irgendwann ist immer das erste Mal.
Kann es nicht sein, dass es, wie manche ja geschrieben haben, über ein veraltetes Plugin geschehen ist, also nicht wirklich über die echten Zugangsdaten, sondern eben über eine Sicherheitslücke?
In den PUTs stehen ja nur die Dateien. Ob da meine Zugangsdaten drin waren, ist ja erst mal nur eine (valide) Vermutung. Oder sehe ich das falsch?
Vielen Dank nochmals an all den wertvollen Input!
Ein befreundeter Anwalt hatte einmal eine Joomla-Installation, auf einem Hosting, bei dem PHP abgedreht wurde. Die configuration.php wurde somit im Klartext ausgeliefert, samt Passwort für die Datenbank. Nicht lustig, weil er darin einen Mailverteiler hatte.
Ich habe ihm dann auch gleich ein Mail geschrieben und ihn auch angerufen, dass er, soweit der SQL-Server Anfragen von draußen beantwortet, er einen data breach befürchten muss, und habe ihm Abwehrmaßnahmen und Tips fürs Audit genannt.
Ja, ein Passwort kann bei so einer Konstellation und bots, die danach aktiv suchen, sehr leicht leaken. Natürlich nicht das Admin-Passwort, das in der DB hoffentlich nur als salted Hash vorliegt. Aber selbst anhand eines Hashwerts kann man bekannte, wiederverwendete Passwörter gut auffinden.
Daher hier immer nur komplexere, maschinengenerierte Passwörter nehmen und im Zweifelsfall diese austauschen. Zur Diskussion über 2FA. Ja, aber, wenn eine illegitime solche Anfrage durchdringt, ist das Passwort auch bekannt. Der zweite Faktor ist dann auch nur das letzte Sicherungsseil.
Kann es nicht sein, dass es, wie manche ja geschrieben haben, über ein veraltetes Plugin geschehen ist, also nicht wirklich über die echten Zugangsdaten, sondern eben über eine Sicherheitslücke?
Bei einer Sicherheitslücke findet kein klassischer Login statt. Da verschafft man sich über andere Wege Zugriff auf die Server. Der FTP Upload am morgen, der könnte durch eine solche Lücke entstanden sein. Der Login am Nachmittag fand mit regulären Zugangsdaten statt, deshalb auch die Meldung von Wordfence.
In den PUTs stehen ja nur die Dateien.
Und das sind auch deine Dateien? Das war ja noch eine der offenen Fragen.
Ob da meine Zugangsdaten drin waren, ist ja erst mal nur eine (valide) Vermutung.
Schau mal in die wp-config.php.
Ich hatte tatsächlich noch nie in meinem Leben den Fall, dass jemand irgendwo meine Zugangsdaten gehackt hätte.
In den allermeisten Fällen werden Zugänge ja nicht gehackt, sondern die Zugangsdaten abgefischt. Die häufigsten Gründe, wenn jemand unautorisiert Zugang erlangt, dürfen m.E. sein:
* Auf Phishingmail reingefallen
* Zugang offengelassen (Nicht abgemeldet, wenn man den Rechner verlässt)
* Zugangsdaten irgendwo aufgeschrieben
* Unsicherer Layer 7 (Löchrige Plugins, Keine Absicherung mit WebApplication-FIrewall, Betriebssystem und Software nicht auf dem aktuellen Stand)
Ein befreundeter Anwalt hatte einmal eine Joomla-Installation, auf einem Hosting, bei dem PHP abgedreht wurde. Die configuration.php wurde somit im Klartext ausgeliefert, samt Passwort für die Datenbank.
Wenn php down ist, kommt doch aber eigentlich ein 503 und nicht die php-Datei im Klartext?
ja klar kann das via angreifbares plugin geschehen sein.
und wo stehen denn deine zugangsdaten?!
Ja, nirgends. Also jedenfalls nicht, dass ich wüsste.
Mein Passwort ist absolut garantiert einzigartig auf der Welt und steht nirgends außer in meinem Kopf. Es muss wohl irgendwie abgefischt worden sein.
In der Zwischenzeit habe ich natürlch alle PWs geändert und wenn möglich auf 2FA geändert.
Bei einer Sicherheitslücke findet kein klassischer Login statt. Da verschafft man sich über andere Wege Zugriff auf die Server. Der FTP Upload am morgen, der könnte durch eine solche Lücke entstanden sein. Der Login am Nachmittag fand mit regulären Zugangsdaten statt, deshalb auch die Meldung von Wordfence.
Und das sind auch deine Dateien? Das war ja noch eine der offenen Fragen.
Schau mal in die wp-config.php.
Ob es meine Dateien waren weiß ich nicht. die wp-config z.B. ist ja auf der Wordpress-Installation vorhanden.
Bei mir auf dem Server sieht so normal aus, beinhaltet halt die Datenbank und deren Zugangsdaten, aber natürlich nicht meine WP-Zugangsdaten.
Was die Dateien für einen Inhalt hatten, die dort geputtet wurden, weiß ich natürlich nicht. Mir wurden nur die Logs zugeschickt, nicht die Dateien selbst.
Diese "reports2.js", "results.xml" und "resng.css" sind auf meinem Server z.B. überhaupt nicht vorhanden.
Oder verstehe ich das falsch?
Diese "reports2.js", "results.xml" und "resng.css" sind auf meinem Server z.B. überhaupt nicht vorhanden.
Oder verstehe ich das falsch?
Das war die Frage. Kannst du sicher ausschließen, dass die Dateien von dir sind? Das wäre dann ein Hinweis darauf, dass der Upload nicht von dir kam.
Wenn php down ist, kommt doch aber eigentlich ein 503 und nicht die php-Datei im Klartext?
Wenn *.php in der Webserver-Konfiguration plötzlich nicht mehr speziell behandelt wird, ist es eine reguläre statische (Text) Datei. Diesen Fall habe ich in freier Wildbahn schon viel zu oft gesehen, was natürlich meistens schlimme Konsequenzen hat. Die Ursachen dafür waren immer sehr unterschiedlich.
Das war die Frage. Kannst du sicher ausschließen, dass die Dateien von dir sind? Das wäre dann ein Hinweis darauf, dass der Upload nicht von dir kam.
Also 100% ausschließen kann ich hier ja leider nichts. Theoretisch könnten das ja irgendwelche generierten Dateien sein.
Jedenfalls sind diese 3 Dateien weder auf meinem Server auffindbar, noch in den Logs sichtbar.
Also zu 99% würde ich sagen, sie sind nicht von meinem Server.
Luke42 Mal ein paar andere Fragen, da das womöglich unterging...
Wenn php down ist, kommt doch aber eigentlich ein 503 und nicht die php-Datei im Klartext?
Bei seinem Hoster vor einigen Jahren war das mit mod_php noch ein bisserl anders. Falscher oder kein Handler für .php und schon wird Klartext geliefert.
Für Nginx mit php-fpm wäre dann das Backend down, worüber er eine Fehlermeldung wirft.
In den allermeisten Fällen werden Zugänge ja nicht gehackt, sondern die Zugangsdaten abgefischt. Die häufigsten Gründe, wenn jemand unautorisiert Zugang erlangt, dürfen m.E. sein:
* Auf Phishingmail reingefallen* Zugang offengelassen (Nicht abgemeldet, wenn man den Rechner verlässt)
* Zugangsdaten irgendwo aufgeschrieben
* Unsicherer Layer 7 (Löchrige Plugins, Keine Absicherung mit WebApplication-FIrewall, Betriebssystem und Software nicht auf dem aktuellen Stand)
Vergiss nicht: Unsicheres Passwort für einen Passwortsafe im Netz...
Luke42 Mal ein paar andere Fragen, da das womöglich unterging...
- Hast Du die Inhalte Deines gesamten Webspaces (inkl. Datenbanken!) mittlerweile komplett heruntergeladen bzw. extern/offline gesichert?
- Ist Deine Wordpress Instanz noch immer online und erreichbar? Alleine aufgrund des nicht authorisierten Adminlogins würde ich persönlich die jedenfalls offline nehmen, solange nicht restlos geklärt ist, woher die Zugangsdaten stammen und was der Angreifer alles anrichten konnte. Der erfolgreiche Login war vielleicht nur die Spitze des Eisbergs und die Installation ist vielleicht sowieso schon länger kompromittiert.
Beides ja.
Habe nur leider das Gefühl, dass meine Fähigkeiten und mein Wissen hier nicht wirklich ausreichen, das restlos aufzuklären 
Mein laienhaftes Wordfence scannen, Serverlogs durchsuchen, Dateien und Statisiken auf dem Server anschauen hat bisher leider absolut nichts ergeben.
Ja, nirgends. Also jedenfalls nicht, dass ich wüsste.
das war schon mehr rhetorisch gemeint. in deiner wp-config stehen die daten zur datenbank.
falls deine seite noch normal online ist, wäre es zeit das ding platt zu machen.
edit: dann sag mal kurz an, in welchem verzeichnis dein WP läuft (oder screenshot vom datei manager im WCP).
das solltest du verschieben, und nicht einfach via WP deaktivieren.
das war schon mehr rhetorisch gemeint. in deiner wp-config stehen die daten zur datenbank.
falls deine seite noch normal online ist, wäre es zeit das ding platt zu machen.
edit: dann sag mal kurz an, in welchem verzeichnis dein WP läuft (oder screenshot vom datei manager im WCP).
das solltest du verschieben, und nicht einfach via WP deaktivieren.
httpdocs.
Ok, danke, werde ich machen!
evtl. so (dann ist es auch dokumentiert):
0. im datei manager des WCP die anzeige versteckter dateien (dotfiles) anschalten, falls nicht standardeinstellung.
1. verzeichnis /z-www anlegen (im / [root] des webhostings, nicht in /httpdocs)
2. inhalt + unterverzeichnisse von /httpdocs nach /z-www verschieben (nicht httpdocs direkt umbenennen – /httpdocs einfach leer stehenlassen)
3. datenbank exportieren via phpmyadmin im WCP
extra (zippen sollte im datei manager funktionieren):
4. verzeichnis /z-www zippen -> /z-www.zip
5. verzeichnis /logs zippen -> /logs.zip
bescheid geben, ob sensible daten enthalten sein könnten (kunden, bilder, firmendaten etc.)
