Anatomie eines echten Angriffs: gsocket-Backdoor und JCE-Exploit

Gründer und Digitalisierungs-Experte

Aktualisiert: Juni 29, 2026

Lesezeit ca.: 18 Minuten

Es beginnt fast immer gleich: mit einer E-Mail, die man lieber nicht bekommen hätte. „Auf Ihrem Webspace wurde Schadsoftware gefunden.“ Genau so startete im Juni 2026 einer der lehrreichsten Vorfälle, die wir in einem Kundenprojekt bereinigt haben. Was als kurze Aufräumarbeit aussah, entpuppte sich als ein vollständig ausgebauter Angriff mit getarnten Prozessen, einer versteckten Hintertür und einem Selbstheilungs-Mechanismus, der jede halbe Bereinigung sofort zunichte machte.

Dieser Beitrag erzählt einen echten Fall Schritt für Schritt: wie ein Angreifer über eine veraltete Joomla-Erweiterung eindrang, sich mit einer gsocket-Backdoor festkrallte und warum der naheliegende erste Bereinigungsversuch genau in die Falle lief. Alles streng anonymisiert und rein defensiv erklärt.

Auf einen BlickEinfallstor: eine veraltete JCE-Erweiterung (JoomlaContentEditor) auf einer Joomla-5-Website im Shared Hosting, die einen unautorisierten Datei-Upload erlaubte. Befund: eine getarnte Webshell, ein als harmloser System-Prozess maskierter Schadprozess und eine gsocket-Backdoor zur versteckten Fernsteuerung. Persistenz: Cronjobs, Autostart-Einträge und ein Dropper, der etwa alle zehn Minuten neue Schaddateien anlegte, mit gefälschten Zeitstempeln. Lehre: Wer nur die sichtbaren Schaddateien löscht, hat in wenigen Stunden alles zurück.

Der Auslöser: eine E-Mail vom Hoster

Der erste Hinweis kam nicht aus einem Monitoring-Dashboard und auch nicht von einem aufmerksamen Nutzer. Er kam vom Hoster. In einer knappen automatischen E-Mail teilte er mit, dass auf dem betroffenen Webspace „Schadsoftware gefunden“ wurde. Solche Meldungen sind ernst zu nehmen, denn Hoster scannen ihre Shared-Server regelmäßig nach bekannten Mustern. Wenn ihr Scanner anschlägt, ist meist schon etwas passiert, das über einen Fehlalarm hinausgeht.

Die betroffene Seite war eine Joomla-5-Website, die auf einem gemeinsam genutzten Server lag. Shared Hosting heißt: mehrere Websites teilen sich denselben Account und dieselbe Umgebung. Das ist günstig und für viele Projekte völlig ausreichend, hat aber eine Eigenheit, die in diesem Fall entscheidend wurde. Ein Befall bleibt selten auf eine einzige Seite beschränkt.

Wir haben in solchen Fällen eine klare Regel: erst verstehen, dann handeln. Wer sofort wild löscht, vernichtet Spuren, die man für die saubere Bereinigung dringend braucht. Also haben wir zunächst forensisch geschaut, was auf dem Server tatsächlich vor sich ging.

WichtigEine Hoster-Meldung ist ein Symptom, keine Diagnose. Sie sagt, dass etwas gefunden wurde, nicht wie der Angreifer hereinkam oder wie tief er sich eingenistet hat. Genau diese Lücke zwischen „etwas gefunden“ und „verstanden“ ist die gefährlichste Phase eines Vorfalls.

Spurensuche: was wir auf dem Server fanden

Die erste Auffälligkeit war eine sogenannte Webshell. Eine Webshell ist eine kleine Datei, die ein Angreifer auf einem Server ablegt und über den Browser aufruft. Sie gibt ihm eine Art Fernbedienung für den Server: Dateien lesen, Befehle ausführen, weitere Schadsoftware nachladen. In diesem Fall war die Webshell getarnt. Sie trug einen unauffälligen Namen, lag zwischen normalen Projektdateien und war im Inneren so verschleiert, dass ein flüchtiger Blick nichts Verdächtiges zeigte. Genau das ist der Sinn der Tarnung: nicht beim ersten Hinsehen aufzufallen.

Die zweite Auffälligkeit war ein laufender Prozess. Ein Prozess ist ein aktives Programm im Arbeitsspeicher des Servers. Dieser Prozess war als harmloser System-Prozess maskiert. Er trug einen Namen, wie ihn ganz normale Hintergrunddienste tragen, und fiel in einer schnellen Übersicht der laufenden Programme nicht auf. Wer nicht genau wusste, wonach er suchte, hätte ihn für einen regulären Bestandteil des Systems gehalten. Tatsächlich war er der aktive Teil des Angriffs.

Solche versteckten Prozesse haben oft einen klaren Zweck. Manchmal verschicken sie Spam, manchmal greifen sie weitere Ziele an, und sehr häufig schürfen sie heimlich Kryptowährung. Ein solcher Krypto-Miner auf einem Webserver verbraucht Rechenleistung, treibt die Last nach oben und fällt deshalb irgendwann durch ungewöhnliche Auslastung auf. In diesem Fall diente der getarnte Prozess vor allem dazu, die Verbindung nach außen offen zu halten, und dafür kam ein besonderes Werkzeug zum Einsatz.

Vereinfachte Übersicht der Befundkette: getarnte Webshell, maskierter Prozess und Hintertür griffen ineinander.

Begriff erklärtEine Webshell ist Fernsteuerung per Browser. Ein versteckter Prozess ist ein aktives Schadprogramm, das im Hintergrund läuft. Beide zusammen geben einem Angreifer dauerhaften Zugriff, ohne dass er sich erneut einloggen müsste. Sicherheitsbehörden wie die US-amerikanische CISA stufen Webshells deshalb als ernste, schwer zu entdeckende Bedrohung ein.^[3]

gsocket: eine Hintertür, die durch jede Firewall telefoniert

Das Kernstück des Angriffs war ein sogenanntes gsocket-Relay. „gsocket“ steht für „Global Socket“ und ist ein öffentlich bekanntes, frei verfügbares Werkzeug.^[1] Es wurde nicht als Angriffswaffe erfunden, wird aber von Angreifern gerne zweckentfremdet. Um zu verstehen, warum es so beliebt ist, muss man wissen, wie eine normale Firewall funktioniert.

Eine Firewall überwacht den Datenverkehr eines Servers. In den meisten Konfigurationen blockiert sie eingehende Verbindungen, also Versuche von außen, sich direkt mit dem Server zu verbinden. Ausgehende Verbindungen, also Verbindungen, die der Server selbst nach außen aufbaut, sind dagegen oft erlaubt, weil sie für ganz normale Aufgaben gebraucht werden. Genau diese Asymmetrie nutzt eine gsocket-Backdoor aus.

Statt darauf zu warten, dass jemand von außen anklopft, baut der infizierte Server selbst eine Verbindung nach draußen auf, zu einem öffentlichen Vermittlungsdienst. Der Angreifer verbindet sich mit demselben Vermittlungsdienst, und beide treffen sich in der Mitte. Aus Sicht der Firewall sieht das aus wie eine gewöhnliche ausgehende Verbindung. Es muss kein Port geöffnet werden, es braucht keine feste IP-Adresse des Angreifers, und der Datenverkehr ist verschlüsselt. So entsteht ein verdeckter Fernzugriff, der durch viele Firewalls hindurch funktioniert, ohne dass die üblichen Schutzregeln greifen.

Warum das so gefährlich istKlassische Schutzmaßnahmen prüfen vor allem eingehende Verbindungen. Eine gsocket-Backdoor dreht den Spieß um und nutzt eine erlaubte ausgehende Verbindung. Wer nur auf offene Ports oder verdächtige Zugriffe von außen schaut, sieht eine solche Hintertür schlicht nicht. Sie verrät sich eher über den getarnten Prozess, der sie am Leben hält.

Wir erklären das hier bewusst nur auf der Konzeptebene. Es geht darum, das Risiko zu verstehen und einordnen zu können, nicht darum, irgendetwas nachzubauen. Genau deshalb beschreiben wir keine Befehle, keine Konfiguration und keine Vorgehensweise eines Angreifers.

Wie sich der Angreifer festkrallte

Ein gut gemachter Angriff verlässt sich nie auf eine einzige Datei. Er sorgt dafür, dass er auch nach einem Neustart oder einer Teilbereinigung wiederkommt. Fachleute nennen das Persistenz, also Beständigkeit. Das MITRE-ATT&CK-Framework, ein anerkannter Katalog typischer Angreifer-Techniken, listet zahlreiche solcher Methoden auf.^[2] In unserem Fall fanden wir gleich mehrere davon.

1Cronjobs. Ein Cronjob ist eine zeitgesteuerte Aufgabe, die der Server automatisch und regelmäßig ausführt. Der Angreifer hatte eigene Cronjobs hinterlegt, die in festen Abständen prüften, ob seine Schadsoftware noch lief, und sie bei Bedarf neu starteten.

2Autostart-Einträge. Zusätzlich gab es Einträge, die dafür sorgten, dass die Schadsoftware bei bestimmten Ereignissen automatisch wieder anlief. So überlebte der Angriff selbst dann, wenn ein einzelner Prozess beendet wurde.

3Ein Dropper alle zehn Minuten. Das Herzstück der Persistenz war ein sogenannter Dropper. Das ist ein kleines Programm, dessen einzige Aufgabe es ist, weitere Schaddateien abzulegen. Dieser Dropper lief etwa alle zehn Minuten und legte immer wieder frische Schaddateien neu an. Löschte man eine, war kurze Zeit später eine neue da.

4Gefälschte Zeitstempel. Jede Datei auf einem Server hat ein Datum, das verrät, wann sie zuletzt geändert wurde. Bei einer Bereinigung sucht man oft gezielt nach Dateien, die zur Zeit des Angriffs neu auftauchten. Der Angreifer hatte die Zeitstempel seiner Dateien gefälscht, sodass sie auf ein altes, unverdächtiges Datum zeigten. Damit lief eine Suche nach Datum ins Leere.

Diese Kombination ist tückisch. Cronjobs und Autostart bringen die Schadsoftware immer wieder zurück, der Dropper erzeugt laufend neue Dateien, und die gefälschten Zeitstempel führen die Suche in die Irre. Wer hier nicht systematisch vorgeht, jagt Symptomen hinterher, die sich schneller vermehren, als man sie löschen kann.

Der erste Fehler: warum die Seite sofort wieder infiziert war

Der naheliegende erste Reflex bei einem Befund lautet: weg mit den Schaddateien. Genau das war auch der erste Versuch in diesem Projekt. Die gefundene Webshell und die offensichtlichen Schaddateien wurden entfernt, die Seite sah wieder sauber aus. Wenige Stunden später war alles zurück.

Der Grund ist einfach und gleichzeitig der wichtigste Lerneffekt dieses Falls. Es wurden nur die Symptome entfernt, nicht die Ursache. Die Persistenz blieb unangetastet: Die Cronjobs liefen weiter, der Dropper legte alle zehn Minuten neue Dateien an, und die Autostart-Einträge starteten den Schadprozess neu. Vor allem aber blieb das Einfallstor offen. Solange die veraltete Erweiterung mit ihrer Sicherheitslücke installiert war, konnte der Angreifer jederzeit erneut eindringen, selbst wenn man jede einzelne Datei erwischt hätte.

Warum eine Seite immer wieder infiziert wird: Persistenz und offenes Einfallstor füllen jede gelöschte Datei sofort nach.

Erschwerend kam die Eigenheit des Shared Hostings hinzu. Der Befall beschränkte sich nicht auf die eine Joomla-Seite. Mehrere Websites desselben Hosting-Accounts waren betroffen. Eine vermeintlich gesäuberte Seite konnte also über eine Nachbarseite im selben Account erneut infiziert werden. Wer nur eine einzige Seite anschaut, übersieht in dieser Konstellation den Rest des Hauses, während im Keller weiter ein Feuer brennt.

Die teure LektionSchaddateien zu löschen, ohne Persistenz und Einfallstor zu schließen, ist keine Bereinigung. Es ist eine Pause. Innerhalb von Stunden ist die Infektion zurück, oft aggressiver als zuvor. Eine erfolgreiche Bereinigung erkennt man nicht daran, dass die Seite kurz sauber aussieht, sondern daran, dass sie sauber bleibt.

Der saubere Fix

Nach diesem ersten Rückschlag haben wir den Vorfall in der richtigen Reihenfolge angepackt. Die Reihenfolge ist hier nicht nebensächlich, sie ist der eigentliche Schlüssel. Wer Schaddateien löscht, während der Dropper noch läuft, hat schon verloren. Wer das Einfallstor offen lässt, lädt den Angreifer wieder ein.

1Zuerst die Persistenz. Wir entfernten die fremden Cronjobs, die Autostart-Einträge, etwaige untergeschobene Benutzerkonten und fremde Editor-Profile. Damit verlor der Angriff seine Fähigkeit, sich selbst neu zu starten und nachzuladen.

2Dann die Schadprozesse beenden. Erst als die Persistenz weg war, beendeten wir den getarnten Prozess und die gsocket-Backdoor. Jetzt konnten sie nicht mehr einfach wieder anlaufen, weil ihre Startmechanismen bereits beseitigt waren.

3Dann die Schaddateien. Nun erst entfernten wir die Webshell und alle weiteren Schaddateien. Weil weder Dropper noch Cronjobs sie nachlegen konnten, blieben die gelöschten Dateien diesmal auch gelöscht. Den gefälschten Zeitstempeln vertrauten wir bewusst nicht, sondern prüften nach Inhalt und Muster.

4Dann das Einfallstor schließen. Jetzt kam der entscheidende Schritt, der beim ersten Versuch gefehlt hatte. Wir aktualisierten den Joomla-Kern und alle Erweiterungen, allen voran die JCE-Erweiterung, deren veraltete Version die Tür geöffnet hatte. Damit war die ausgenutzte Schwachstelle geschlossen.

5Zum Schluss härten. Wir erneuerten alle Passwörter und Schlüssel, denn nach einem solchen Zugriff muss jedes Geheimnis als kompromittiert gelten. Anschließend härteten wir die Installation und prüften den gesamten Hosting-Account, nicht nur die eine Seite.

Das Einfallstor war eine veraltete JCE-Erweiterung, im Kern JoomlaContentEditor mit der Komponente com_jce. Die ausgenutzte Schwachstelle erlaubte einen unautorisierten Datei-Upload über die Editor-Profile. Betroffen waren JCE-Versionen unterhalb von 2.9.99.5, behoben wurde das Ganze mit den Versionen 2.9.99.5 und 2.9.99.6. Wer eine dieser Fix-Versionen oder neuer einsetzt, ist gegen genau diese Lücke geschützt. Eine ausführliche Einordnung dieser Schwachstelle finden Sie in unserem Beitrag zur JCE-Sicherheitslücke und dem nötigen Joomla-Update.

Verdacht auf einen Hack? Jede Stunde zählt.

Wir analysieren den Befall, schließen das Einfallstor und sorgen dafür, dass die Bereinigung diesmal hält. Diskret, in der richtigen Reihenfolge, mit forensischem Blick.

Soforthilfe anfordern

So bleibt es sauberErst als Persistenz und Einfallstor geschlossen waren, blieb die Seite stabil. Eine ausführliche, allgemein anwendbare Anleitung zum Vorgehen finden Sie in unserem Leitfaden zum Bereinigen einer gehackten Joomla-Website.

Lessons Learned

Jeder Vorfall hinterlässt Lehren. Bei diesem waren sie besonders deutlich, weil der erste Bereinigungsversuch genau das vorführte, was man nicht tun sollte. Fünf Punkte nehmen wir mit, und sie gelten weit über diesen einen Fall hinaus.

Die Reihenfolge zählt. Persistenz zuerst, dann Prozesse, dann Dateien, dann Einfallstor, dann härten. Wer diese Reihenfolge umstellt, arbeitet gegen einen Mechanismus, der schneller nachlegt, als man entfernen kann. Diese Reihenfolge ist kein Detail, sie ist der Unterschied zwischen einer echten Bereinigung und einer kurzen Pause.

Symptome entfernen reicht nie. Sichtbare Schaddateien sind das Ende einer Kette, nicht ihr Anfang. Wer nur sie löscht, lässt den Motor des Angriffs laufen. Eine Bereinigung muss bis zur Wurzel gehen, sonst ist sie keine.

Das Einfallstor schließen ist Pflicht. Solange die ausgenutzte Schwachstelle offen bleibt, ist jede Bereinigung nur eine Frage der Zeit. Aktuelle Joomla-Kerne und aktuelle Erweiterungen sind keine Kür, sie sind die wichtigste Einzelmaßnahme gegen genau diese Art von Angriff.

Zeitstempeln nicht vertrauen. Datumsangaben lassen sich fälschen, und genau das tun Angreifer. Eine Suche allein nach Datum übersieht getarnte Dateien. Maßgeblich sind Inhalt und Muster, nicht das angezeigte Änderungsdatum.

Ein Account-weiter Befall braucht eine Account-weite Prüfung. Im Shared Hosting hängen mehrere Seiten am selben Account. Eine einzelne Seite zu säubern, während daneben weiter etwas läuft, führt zur erneuten Infektion. Geprüft und bereinigt wird der gesamte Account. Einen kompakten Leitfaden zum Erkennen, Bereinigen und Schützen finden Sie in unserem Beitrag Joomla gehackt: erkennen, bereinigen, schützen.

Ihre nächsten Schritte

Ein Befall wie dieser wirkt im ersten Moment überwältigend. Mit dem richtigen Vorgehen ist er beherrschbar. Wenn Sie unsicher sind, ob Ihre Joomla-Seite betroffen ist oder ob eine frühere Bereinigung wirklich hielt, sprechen Sie mit uns, bevor weitere Stunden verstreichen.

Incident Response, die wirklich hält

Wir analysieren den Vorfall forensisch, schließen Persistenz und Einfallstor in der richtigen Reihenfolge und härten Ihre Installation nach. Diskret, schnell und mit klarer Dokumentation. Schildern Sie uns Ihren Fall über unser Kontaktformular.

Zur Soforthilfe

Häufige Fragen

Was ist eine gsocket-Backdoor in einfachen Worten?

Eine gsocket-Backdoor ist eine versteckte Hintertür. Der infizierte Server baut von sich aus eine Verbindung nach außen zu einem öffentlichen Vermittlungsdienst auf, über den sich der Angreifer einklinkt. Weil es sich um eine ausgehende, verschlüsselte Verbindung handelt, lässt sie sich durch viele Firewalls hindurch herstellen, ohne dass ein Port geöffnet werden muss. „gsocket“ steht für „Global Socket“ und ist ein öffentlich bekanntes Werkzeug, das hier missbraucht wurde.

Wie kam der Angreifer auf die Joomla-Seite?

Über eine veraltete JCE-Erweiterung. In Versionen unterhalb von 2.9.99.5 gab es eine Schwachstelle, die einen unautorisierten Datei-Upload über die Editor-Profile erlaubte. Darüber konnte eine Schaddatei auf den Server gelangen. Behoben ist das in den Versionen 2.9.99.5 und 2.9.99.6 sowie neueren Versionen.

Warum war die Seite nach dem Löschen sofort wieder infiziert?

Weil nur die sichtbaren Schaddateien entfernt wurden, nicht aber die Persistenz und das Einfallstor. Cronjobs und Autostart-Einträge starteten den Angriff neu, ein Dropper legte etwa alle zehn Minuten frische Schaddateien an, und die offene Schwachstelle erlaubte ein erneutes Eindringen. Wer Symptome löscht, aber Ursachen stehen lässt, gewinnt nur eine kurze Pause.

In welcher Reihenfolge muss man eine solche Infektion bereinigen?

In dieser Reihenfolge: zuerst die Persistenz entfernen (Cronjobs, fremde Benutzer, Autostart, fremde Editor-Profile), dann die Schadprozesse beenden, dann die Schaddateien löschen, dann das Einfallstor schließen (Joomla-Kern und alle Erweiterungen aktualisieren, vor allem JCE), und zum Schluss alle Passwörter und Schlüssel erneuern und die Installation härten. Die Reihenfolge ist entscheidend, sonst legt der Angriff schneller nach, als man entfernen kann.

Warum darf man Dateizeitstempeln nicht trauen?

Weil Angreifer sie fälschen. In diesem Fall waren die Zeitstempel der Schaddateien auf ein altes, unverdächtiges Datum gesetzt, damit eine Suche nach dem Zeitpunkt des Angriffs sie übersieht. Eine zuverlässige Bereinigung stützt sich deshalb auf Inhalt und Muster der Dateien, nicht auf das angezeigte Änderungsdatum.

Kann ein Hack auf einer Seite andere Seiten im selben Hosting befallen?

Ja. Im Shared Hosting teilen sich mehrere Websites einen Account und eine Umgebung. In diesem Fall waren mehrere Seiten desselben Accounts betroffen. Wer nur eine Seite säubert, riskiert eine erneute Infektion über eine Nachbarseite. Deshalb gehört bei einem solchen Befall der gesamte Account auf den Prüfstand.

Was ist eine Webshell und warum ist sie so gefährlich?

Eine Webshell ist eine kleine Datei auf dem Server, die ein Angreifer über den Browser aufruft und damit den Server fernsteuern kann. Gefährlich ist sie, weil sie oft gut getarnt zwischen normalen Dateien liegt und im Inneren verschleiert ist. Sicherheitsbehörden wie die US-amerikanische CISA stufen Webshells als schwer zu entdeckende, ernste Bedrohung ein, gerade weil sie sich unauffällig in bestehende Projekte einfügen.

Quellen

1gsocket (Global Socket), Projektseite
GitHub, hackerschoice. Öffentlich bekanntes Werkzeug, hier nur zur Begriffserklärung. Vertrauen: mittel.

2MITRE ATT&CK: Persistence und Web Shell
MITRE Corporation. Anerkannter Katalog von Angreifer-Techniken. Vertrauen: hoch.

3CISA: Web Shell Detection und Mitigation
Cybersecurity and Infrastructure Security Agency (USA). Behördliche Schutzempfehlungen. Vertrauen: hoch.

5/5 - (1 vote)

Florian Konrad

Florian Konrad, Mitbegründer und Geschäftsführer der Unicorn Factory, begann bereits in der Schule mit Webentwicklung und Online-Marketing. Mit Jahren der Erfahrung hat er umfassende Expertise in SEO, Automatisierung und Webentwicklung entwickelt.

Florian Konrad

Diesen Beitrag teilen!