Gerade gemerkt, das nach dem Update mein Submenü nicht mehr geöffnet wird. Mal sehen wie ich den Fehler finden kann.
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.
-
Hab ich erst danach installiert
-
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=images Attempted 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:
-
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.php16.03.2026 um 01:34:40
IP: 198.186.130.10
Rename von 47785d75cdd3983.svg auf 47785d75cdd3.php, danach direkter Aufruf von /images/47785d75cdd3.php16.03.2026 um 02:05:02
IP: 155.212.0.109
Rename von 47785d75cdd3656.svg auf 47785d75cdd3.php, danach direkter Aufruf von /images/47785d75cdd3.php16.03.2026 um 03:11:29
IP: 46.246.126.191
Rename von 47785d75cdd3146.svg auf 47785d75cdd3.php, danach direkter Aufruf von /images/47785d75cdd3.php16.03.2026 um 03:42:04
IP: 89.188.178.88
erneut dasselbe Muster mit 47785d75cdd3907.svg16.03.2026 um 04:47:06
IP: 198.186.130.10
erneut dasselbe Muster mit 47785d75cdd3836.svg16.03.2026 um 05:16:33
IP: 155.212.0.109
erneut dasselbe Muster mit 47785d75cdd3526.svgDie 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 DateiIm 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.php16.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.php16.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.php16.03.2026 um 05:39:24 und 05:39:25
IP: 45.143.20.147
wieder POSTs auf /images/47785d75cdd3.php16.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.php16.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.phpSpä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.php16.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.245Fü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.
-
Hat sich erledigt.
-
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.
-
Der Support hat geantwortet. EasyBlog ist zwar Joomla 5 kompatibel, jedoch nur mit dem Kompatibilitäts-Plugin

-
Da gehts auch mit dem Strg + V
Danke Dir
-
Zum Beispiel Notepad
-
Nein, Windows. Egal aus welchen Program ich es rausziehe, immer kommt der Strich. Einfügen geht nicht.
-
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.
-
-
-
Ich häng mich mal ran Wie kann ich denn bei dem individuellen Bereich, eine große Menge Css Code reinkopieren, ohne dass er nach vor jedem Anweisungsende einen \ reinmacht? Den Befehl zum einfügen gibt es ja nicht, nur reinziehen funktioniert.
-
Ich hatte es deaktiviert, und trotzdem kamen noch Fehlermeldungen, welche auf EasyBlog zeigten. Warscheinlich müsste man es komplett löschen oder es sind noch andere Dinge damit im Zusammenhang istalliert, wie z.B.: das Foundry