Red Heron nutzt kritische Gitea-RCE aus und dringt in 13 Organisationen ein

Ein mutmaßlich mit China verbundener Bedrohungsakteur, der unter dem Namen Red Heron verfolgt wird, hat eine kritische Gitea-Schwachstelle ausgenutzt, um Entwicklungsplattformen zu kompromittieren, Repositories zu stehlen, Zugangsdaten abzugreifen und in verbundene Infrastrukturen einzudringen.

Die Acronis Threat Research Unit identifizierte 13 bestätigte Kompromittierungen von Organisationen in Kanada, Argentinien, Taiwan, den Vereinigten Staaten, Katar und Sri Lanka. Die Ziele waren in Bereichen wie Verteidigung, Wahlen, Energie, Luft- und Raumfahrt, Telekommunikation, Behörden, öffentliche Sicherheit und Forschung tätig.

Die Kampagne ging weit über den Diebstahl von Quellcode hinaus. In einer taiwanischen Umgebung erlangte Red Heron nach dem Zugriff über einen verwundbaren Gitea-Server administrative Kontrolle auf Root-Ebene über einen Proxmox-Cluster mit drei Knoten.

Red Heron kombinierte massenhaftes Scanning mit gezielter Auswahl

Red Heron scannte 1.386 aus dem Internet erreichbare Gitea-Instanzen in sieben Ländern. Der Akteur verfügte außerdem über einen separaten Datensatz mit 477 Systemen in Taiwan. Ob sich diese Systeme mit den Ergebnissen des umfassenderen Scans überschnitten, ist jedoch nicht bekannt.

Die 13 bestätigten Kompromittierungen verteilten sich wie folgt:

• Vier Organisationen in Taiwan
• Vier in den Vereinigten Staaten
• Zwei in Kanada
• Eine in Argentinien
• Eine in Katar
• Eine in Sri Lanka

Welches siebte Land von der Scan-Aktion betroffen war, ist nicht bekannt.

Ein Teil der Aktivitäten ähnelte opportunistischen Exploit-Versuchen im gesamten Internet. Die Auswahl und Kennzeichnung der Ziele deuteten jedoch auf eine gezieltere Informationsbeschaffung hin. Zu den betroffenen Bereichen gehörten Organisationen, die wahrscheinlich über sensible Technologien, Infrastrukturdaten, Regierungsinformationen oder privilegierten Zugriff auf andere Netzwerke verfügten.

Die TRU bewertete den Akteur mit mittlerer Sicherheit als in einem China-verbundenen Kontext operierend. Diese Einschätzung stellt keine definitive Zuordnung zur chinesischen Regierung dar. Sie basiert auf der Verwendung vereinfachter chinesischer Bezeichnungen durch Red Heron, der konsequenten Einstufung Taiwans als Teil Chinas und einer Zielauswahl, die den vermuteten chinesischen Nachrichtendienstprioritäten entsprach.

Im Zusammenhang mit den Aktivitäten standen außerdem eine in Indien ansässige Beratungsfirma für Auslandsstudium und ein Managed-IT-Services-Anbieter in den Vereinigten Staaten. Diese Organisationen wurden über zugehörige Infrastruktur angegriffen, gelten jedoch nicht als weitere bestätigte Kompromittierungen über die insgesamt 13 Länder hinaus.

CVE-2026-60004 ermöglicht Remote Code Execution ohne Authentifizierung

Der Vektor für den Erstzugriff war CVE-2026-60004, eine Schwachstelle für Remote Code Execution, die Gitea-Versionen vor 1.27.1 betrifft.

Die Schwachstelle befindet sich in der diffpatch-API von Gitea und ermöglicht es einem Angreifer, einen Git-Hook zu installieren. Da Git-Hooks als Reaktion auf Repository-Operationen Befehle ausführen können, eröffnet der Missbrauch dieses Mechanismus dem Angreifer die Möglichkeit, Code auf dem zugrunde liegenden Server auszuführen.

CVE-2026-60004 hat einen CVSS-v3-Score von 9.8 und ist als CWE-94, improper control of code generation, klassifiziert. Der Vektor lautet:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Die Schwachstelle ist aus der Ferne erreichbar, erfordert eine geringe Angriffskomplexität und setzt weder ein bestehendes Konto noch eine Interaktion des Benutzers voraus. Eine erfolgreiche Ausnutzung kann Vertraulichkeit, Integrität und Verfügbarkeit erheblich beeinträchtigen.

Die Schwachstelle wurde im Juli 2026 veröffentlicht. Laut Berichten über die Kampagne begann Red Heron am 29. Juli 2026 damit, öffentlich verfügbares Exploit-Material in ein automatisiertes Python-Framework namens exp_enhanced.py zu überführen.

Das Framework automatisierte mehrere Schritte, die ansonsten getrennte Aktionen des Operators erfordert hätten: das Registrieren von Konten, das Ausnutzen verwundbarer Server, den Diebstahl von Repositories und das Entfernen ausgewählter Spuren. Dadurch verkürzte sich die Zeit zwischen dem Auffinden einer exponierten Instanz und dem Sammeln ihrer Daten.

Der Repository-Zugriff wurde zum Weg in interne Netzwerke

Eine selbst gehostete Entwicklungsplattform kann deutlich mehr als nur Anwendungscode enthalten. Repositories enthalten häufig Deployment-Dateien, Serveradressen, API-Tokens, SSH-Material, Integrationszugangsdaten und Konfigurationsgeheimnisse. Selbst wenn einzelne Geheimnisse veraltet sind, können sie Aufschluss über Namenskonventionen und die Netzwerkstruktur geben.

Red Heron nutzte kompromittierte Gitea-Systeme als Sammelpunkte und, soweit möglich, als Brücken in die Umgebungen der Opfer. Die beobachteten Aktivitäten umfassten den Diebstahl von Repositories, das Abgreifen von Zugangsdaten, Persistenz, interne Aufklärung und laterale Bewegungen.

Bei einem taiwanischen Unternehmen für industrielle Automatisierung exfiltrierte der Akteur Hunderte von Repositories. Das gestohlene Material umfasste ein SCADA/HMI-Produkt, Integrationen für eine IoT-Plattform, einen Netzwerk-Sniffer, Serverkonfigurationen, Überwachungs- und Monitoring-Software sowie interne Geschäftsanwendungen.

Der Angriff weitete sich später auf Root-Zugriff auf drei Proxmox-Knoten aus. Die Kontrolle auf Root-Ebene über die Virtualisierungshosts hätte einem Angreifer weitreichenden Einblick und umfassende administrative Kontrolle über die auf dem Cluster laufenden Workloads ermöglichen können. Die vollständigen Folgen dieses Vorfalls wurden jedoch nicht offengelegt.

Ein kanadisches Unternehmen für erneuerbare Energien war von umfangreicher Infrastrukturkartierung und Repository-Diebstahl betroffen. Zu den offengelegten Daten gehörten Konfigurationsgeheimnisse, interne Tokens, SSH-Hostschlüssel und proprietäre Anwendungen.

Bei einem argentinischen Unternehmen für quantitativen Handel erfasste Red Heron die Infrastruktur der Organisation umfassend. Ein Opfer in Katar verlor Repositories zu einer Learning-Management-Plattform, einem KI-Chatbot, Tools zur Workflow-Automatisierung und WordPress-Plugins.

Diese Vorfälle zeigen, warum das Patchen des Gitea-Servers allein einen Angriff nicht unbedingt beendet. Zugangsdaten und Schlüssel, die vor der Behebung der Schwachstelle erlangt wurden, können auch danach noch verwendet werden.

JITTERLY und SIXZUT ermöglichten dauerhaften Linux-Zugriff

Die Red Heron zugeschriebene Infrastruktur enthielt ein in C++ geschriebenes Linux-Implantat namens JITTERLY. Die Malware unterstützt mehr als 30 Befehle für die Post-Exploitation, darunter die Ausführung von Shell-Befehlen, Dateiübertragungen, das Beenden von Prozessen, Netzwerktunneling, den Zugriff auf interaktive Terminals und interne Pivoting-Aktivitäten.

Ein Forscher unter dem Alias „dmpdump“ dokumentierte JITTERLY im Juli 2026 und stellte Überschneidungen mit dem AdaptixC2-Agenten fest. Die verfügbaren Informationen belegen nicht, ob Red Heron das Implantat selbst entwickelt oder bestehenden Code übernommen hat.

In derselben Staging-Umgebung befand sich SIXZUT, ein zuvor nicht dokumentiertes Linux-Rootkit auf Basis von LD_PRELOAD. Durch diese Technik wird eine bösartige Shared Library vor legitimen Bibliotheken geladen, sodass sie von Programmen auf dem System ausgeführte Aufrufe abfangen kann.

SIXZUT verändert 15 Linux-Funktionen, um Dateien, Prozesse und Netzwerkverbindungen zu verbergen. Außerdem ist es darauf ausgelegt, sich nach einer Beendigung selbst erneut zu starten und so einer Entfernung zu widerstehen. Diese Fähigkeiten können Command-and-Control-Datenverkehr und bösartige Prozesse vor routinemäßigen Administrationsprüfungen verbergen.

Gemeinsame Infrastruktur verband die Gitea-Kampagne mit Angriffen auf 18 Joomla-Websites in zehn Ländern. Für die Joomla-Aktivitäten wurde ein Python-Skript namens exp.py verwendet, bevor der Operator öffentlich verfügbaren Exploit-Code für CVE-2026-60004 in seine Gitea-Tools integrierte. Dies deutet auf eine umfassendere Web-Exploitation-Operation hin, die nicht auf ein einzelnes Softwareprodukt beschränkt war.

CISA nahm die Schwachstelle mit einer Frist von drei Tagen in den KEV-Katalog auf

CISA nahm CVE-2026-60004 am 25. August 2026 in seinen Known Exploited Vulnerabilities-Katalog auf. Die Frist für die Behebung durch US-Bundesbehörden endete am 28. August 2026.

Die kurze Frist spiegelte bestätigte Ausnutzung und kein rein theoretisches Risiko wider. Gemäß der dokumentierten Maßnahme müssen Behörden die vom Hersteller bereitgestellten Gegenmaßnahmen umsetzen und dabei BOD 26-04, „Priorizing Security Updates Based on Risk“, sowie die Forensics Triage Requirements von CISA einhalten.

Die einschlägigen Vorgaben aus BOD 26-04 gelten auch für Cloud-Dienste. Wenn keine wirksamen Gegenmaßnahmen verfügbar sind, weist CISA die Behörden an, die Nutzung des betroffenen Produkts einzustellen. Organisationen bleiben dafür verantwortlich, die Internet-Exponierung jedes Assets zu bewerten und die jeweils geltenden Anforderungen an das Patchen zu erfüllen.

Alle Gitea-Releases vor 1.27.1 sind betroffen. Betreiber sollten auf Version 1.27.1 oder höher aktualisieren und dabei die Anweisungen von Gitea sowie die eigenen Change-Control-Verfahren befolgen.

Patching muss mit einer Prüfung auf Kompromittierung einhergehen

Organisationen sollten zunächst jede Gitea-Installation erfassen, einschließlich vergessener Testserver und Instanzen, die über Reverse Proxies erreichbar sind. Jedes betroffene System mit Internetzugang sollte sofort priorisiert werden.

Anschließend sollten Verteidiger prüfen, ob die Schwachstelle bereits vor dem Upgrade ausgenutzt wurde. Zu den relevanten Prüfbereichen gehören:

• Unerwartete Registrierung von Gitea-Konten
• Erstellung oder Änderung von Git-Hooks
• Ungewöhnliche Aktivitäten über die diffpatch-API
• Massenzugriffe auf Repositories oder ausgehende Übertragungen
• Neu erstellte SSH-Schlüssel oder veränderte Dateien mit autorisierten Schlüsseln
• Offenlegung oder Verwendung von Konfigurationsgeheimnissen und internen Tokens
• Unerwartete administrative Aktionen in Proxmox
• Verdächtige Linux-Prozesse, Tunnel oder ausgehende Verbindungen
• Nicht erkannte LD_PRELOAD-Konfigurationen und Shared Libraries
• Dateien oder Befehle im Zusammenhang mit exp_enhanced.py, exp.py, JITTERLY oder SIXZUT

In betroffenen Repositories gespeicherte Geheimnisse sollten als potenziell offengelegt betrachtet werden. Relevante API-Tokens, Passwörter, SSH-Schlüssel, Signaturmaterial und Service-Zugangsdaten sollten ausgetauscht werden. Zudem sollten Authentifizierungsprotokolle auf eine anschließende Nutzung überprüft werden.

Systeme, die Anzeichen von SIXZUT zeigen, liefern möglicherweise keine vertrauenswürdigen Informationen zu Prozessen oder Netzwerken, da das Rootkit die Sichtbarkeit im User-Space manipulieren kann. In solchen Fällen sollten Incident Responder bekannte saubere Forensik-Tools verwenden und Beweismaterial sichern, bevor betroffene Hosts neu aufgebaut werden.

Das zentrale Risiko beschränkt sich nicht auf die Gitea-Anwendung. Sobald ein Entwicklungsserver Quellcode, Zugangsdaten und Infrastrukturkonfigurationen offenlegt, kann sich die Kompromittierung auf die Systeme ausweiten, die die Software einer Organisation erstellen, ausliefern, hosten oder verwalten.