291 Intercept: Zugriffsversuche auf offen liegende Git-Repositories haben sich auf unserer Infrastruktur mehr als verdoppelt

Das ist 291 Intercept

291 Intercept ist eine neue wöchentliche Reihe von 291 Group. Wie bei jeder Organisation im Netz wird auch unsere aus dem Internet erreichbare Infrastruktur täglich von automatisierten Scannern abgeklopft, die nach offen gelassenen Türen suchen: frei zugängliche Passwortdateien, vergessene Backups, ungepatchte Admin-Seiten. Jede Ausgabe berichtet, worauf es diese Scanner in einer Woche auf unserer eigenen Infrastruktur abgesehen hatten, damit andere Systemadministratoren und Unternehmen ihre Systeme auf dieselben Schwachstellen prüfen können.

Jede Woche erwartet Sie: die Muster, die auf unserer Infrastruktur aufgefallen sind, und wie sie sich gegenüber der Vorwoche verändert haben, die Herkunft des Traffics und eine kurze Liste mit Punkten, die Sie auf Ihren eigenen Servern prüfen sollten. Alle Angaben sind aggregiert. Wir nennen nie einzelne Adressen oder Systeme und berücksichtigen nur Muster, die von vielen unterschiedlichen Quellen ausgingen. Jede Ausgabe behandelt eine Woche, die bei Veröffentlichung mindestens sieben Tage zurückliegt.

Vom 19. bis 25. Oktober suchten rund 240 Quellen unsere aus dem Internet erreichbare Infrastruktur nach Quellcode-Repositories ab, die auf Webservern liegen geblieben sind. Das sind 137 % mehr als im Wochendurchschnitt der beiden Vorwochen. Angefragt wurden Dateien wie /.git/config, /.git/index und /.svn/entries. Auf unserer Infrastruktur zog in dieser Woche nur WordPress mehr Scanner an als Quellcode.

Verwandte Suchen gegen unsere Sites nahmen gleichzeitig zu. Die Zahl der Quellen, die nach Schlüsseldateien für Cloud-Dienste fahndeten, stieg um 51 %, die der Quellen, die Backups und Datenbank-Dumps anforderten, um 75 %. Zudem nahmen Scanner eine Reihe von .env-Dateien in Unterordnern ins Visier, die zuvor deutlich weniger Interesse geweckt hatten. Keines dieser Ziele ist ein Softwarefehler. Jedes ist eine Datei, die jemand vergessen hat, von einem öffentlichen Server zu entfernen.

Die Woche im Überblick

Wir zählten rund 660 verschiedene Quellen, 28 % mehr als in derselben Vergleichsbasis. WordPress-Logins, XML-RPC und Plugin-Pfade zogen mit 56 % der Quellen die meisten an. Auf Geheimnisse und Konfigurationsdateien entfielen 32 %. Die Zahl der Quellen, die nach Diagnoseseiten wie /info.php suchten, stieg um 33 %, die der Quellen, die Anwendungsinterna wie /actuator/env abklopften, um 37 %.

Von den Quellen, die uns erreichten, nutzten 88 % User-Agent-Strings, die sich als gewöhnliche Browser ausgeben, und 64 % kamen von gemieteten Servern. Die häufigsten Herkunftsländer waren die USA, Deutschland, die Niederlande, Singapur und Indien.

Wie ein offener .git-Ordner eine Website verrät

Die meisten Softwareteams verwalten Änderungen an ihrem Code mit Git, und jedes Git-Projekt speichert seine Historie in einem versteckten .git-Ordner. Wird eine Website veröffentlicht, indem man den gesamten Projektordner auf den Webserver kopiert, kann dieser versteckte Ordner mitkopiert werden, und jeder, der seine Dateien anfordert, kann sie lesen.

/.git/config gehörte zu den am häufigsten angefragten Quellcode-Pfaden auf unserer aus dem Internet erreichbaren Infrastruktur. Diese Datei nennt das Repository, aus dem der Code stammt, und enthält mitunter die Zugangsdaten für das Deployment. Außerdem fragten Scanner bei uns /.git/head, /.git/logs/head und /.git/index ab, woran sich erkennen lässt, ob genug vom Ordner lesbar ist, um weiterzumachen. Liegt der Ordner offen, können Angreifer mitunter den vollständigen Quellcode samt Commit-Historie rekonstruieren.

Der Fehler ist weit verbreitet. Eine im Februar 2026 veröffentlichte Studie fand rund 4.96 Millionen öffentliche Webserver, die Git-Metadaten preisgeben. Bei 252,733 davon enthielt die config-Datei Zugangsdaten für das Deployment, was laut demselben Bericht zur Übernahme von Repositories und zu Supply-Chain-Angriffen führen kann.

Geheimnisse in unerwarteten Ordnern

Scanner fragten auf unseren Sites /.env im Stammverzeichnis ab, doch in dieser Woche suchten viele auch in Unterordnern. /mailer/.env zog 40 Quellen an, das 7.8-Fache des bisherigen Durchschnitts. /live/.env, /mail/.env, /v3/.env, /sitemaps/.env, /releases/.env und /exapi/.env kamen auf jeweils 40 Quellen, etwa sechs bis sieben Mal so viele wie im bisherigen Durchschnitt. Vier Pfade erreichten uns zum ersten Mal, jeweils von etwa 10 Quellen: /core/database/.env, /.changeset/config.json, /secrets und /settings/credentials.

Für Angreifer lohnt sich der Aufwand bei diesen Dateien. Webanwendungen legen API-Schlüssel, Datenbankpasswörter und Cloud-Zugangsschlüssel in .env-Dateien ab. Eine Untersuchung eines Massenscanners vom April 2026 stieß auf abgegriffene .env-Dateien von mehr als 900 kompromittierten Unternehmen; zwischen dem 10. und 21. April 2026 wurden über 30,000 verschiedene .env-Dateinamen gesammelt. Die gestohlenen Geheimnisse betrafen KI-, Cloud-, Zahlungs- und Messaging-Dienste.

Dasselbe Muster zeigte sich bei Cloud-Zugangsdaten. /application_default_credentials.json zog 40 Quellen an, das 6.2-Fache des bisherigen Durchschnitts. Außerdem fragten Scanner bei uns /service-account.json und /.config/gcloud/application_default_credentials.json ab. Diese Datei wird bei einer Anmeldung über die Cloud-Kommandozeile geschrieben, und laut den Empfehlungen des Anbieters selbst wird sie unverschlüsselt gespeichert und erlaubt es jedem, der sie besitzt, zeitlich unbegrenzt Zugriffstokens anzufordern. Landet eine Kopie in einem Web-Root, behält ein Angreifer, der sie findet, den Zugriff, bis sie widerrufen wird.

Ein Durchlauf, viele Ziele

Mehrere koordinierte Gruppen von Quellen arbeiteten dieselben Listen gegen unsere aus dem Internet erreichbare Infrastruktur ab. In einer davon fragten 20 Quellen aus 7 Ländern dieselben 8 Pfade ab, darunter /.git/config, /.env, /info.php, /config.json, /actuator/env und /server-status. Die meisten legten innerhalb von 60 Stunden los. Zwei kleinere Gruppen mit jeweils etwa 10 Quellen nutzten deutlich längere Listen mit 210 bzw. 158 Pfaden. Beide enthielten /.git/config, .env-Varianten wie /.env.old und /.env.development sowie Schlüsseldateien für Cloud-Dienste.

Der Pfad /actuator/env gehört in dieselbe Familie. Ist bei einer Java-Anwendung der Endpunkt von Spring Boot Actuator ohne Anmeldung erreichbar, liefert er die Umgebungsvariablen und die Konfiguration der Anwendung, unter Umständen einschließlich Datenbank-Zugangsdaten und Cloud-Schlüsseln. Auch zurückgelassene phpinfo-Seiten können Umgebungsvariablen offenlegen, und auf unserer Infrastruktur stieg /admin/phpinfo.php auf das 5.9-Fache des bisherigen Durchschnitts. In einem realen Fall lieferte ein WordPress-Plugin eine phpinfo.php aus, die jeder aufrufen konnte.

Auch gegen WordPress lief auf unseren Sites eine eigene Kampagne: 20 Quellen aus 7 Ländern fragten /xmlrpc.php ab, dazu Kopien von wlwmanifest.xml unter geratenen Ordnern wie /blog/wp-includes/wlwmanifest.xml und /wordpress/wp-includes/wlwmanifest.xml. Wer dieselbe Datei unter vielen Ordnernamen anfragt, findet schnell heraus, ob und wo eine Site WordPress einsetzt. Über XML-RPC kann ein Angreifer mit einer einzigen Anfrage Hunderte oder Tausende Passwörter durchprobieren.

Was Sie diese Woche tun sollten

• Von außen prüfen. Rufen Sie aus einem fremden Netz auf jeder Ihrer Sites /.git/config und /.env ab. Liefert eine der beiden Anfragen echten Inhalt, gehen Sie davon aus, dass er bereits ausgelesen wurde.
• Builds ausliefern, keine Arbeitsordner. Spielen Sie nur die Dateien aus, die die Site braucht, und sperren Sie den Webzugriff auf .git, .env und andere versteckte Dateien.
• Alles rotieren, was abgeflossen ist. Waren .git- oder .env-Dateien lesbar, ändern Sie die darin enthaltenen Zugangsdaten und Schlüssel. Das Löschen der Datei macht eine bereits angefertigte Kopie nicht ungeschehen.
• Geheimnisse aus dem Web-Root fernhalten. Legen Sie .env-Dateien und Cloud-Zugangsdateien außerhalb aller veröffentlichten Ordner ab. War eine Zugangsdatei jemals öffentlich erreichbar, widerrufen Sie sie.
• Überbleibsel beseitigen. Löschen Sie Backups wie /wp-config.php.bak und /database.sql, und entfernen Sie phpinfo- und Debug-Seiten.
• Management-Endpunkte schließen. Stellen Sie Actuator-Endpunkte hinter eine Authentifizierung, und deaktivieren Sie XML-RPC auf WordPress-Sites, die es nicht nutzen.

Über diese Beobachtungen

Dieser Bericht wird von 291 Heat Seeker One erstellt, dem Sicherheits-Monitoring-System von 291 Group, das auf 291 Crossband läuft, unserer proprietären Plattform für Security Operations. Er erfasst ausschließlich Traffic zur eigenen, aus dem Internet erreichbaren Infrastruktur von 291 Group.

Die Zahlen sind gerundet. Anteile und Veränderungen beziehen sich auf die Zahl unterschiedlicher Quellen, nicht auf die Zahl der Anfragen, und berücksichtigt werden nur Muster, die von mindestens 20 unterschiedlichen Quellen ausgingen.