291 Intercept: Liczba prób wykrycia odsłoniętych repozytoriów Git w naszej infrastrukturze wzrosła ponad dwukrotnie

Przedstawiamy 291 Intercept

291 Intercept to nowy cotygodniowy cykl przygotowywany przez 291 Group. Jak każda organizacja obecna w sieci, codziennie mamy w naszej infrastrukturze dostępnej z internetu do czynienia z automatycznymi skanerami. Szukają one furtek, które ktoś zostawił otwarte: odsłoniętych plików z hasłami, zapomnianych kopii zapasowych i niezałatanych paneli administracyjnych. W każdym wydaniu opisujemy, czego te skanery szukały w ciągu jednego tygodnia w naszej własnej infrastrukturze, aby inni administratorzy systemów i firmy mogli sprawdzić swoje systemy pod kątem tych samych problemów.

W każdym wydaniu omawiamy wzorce, które wyróżniały się w naszej infrastrukturze, i to, jak zmieniły się w porównaniu z poprzednim tygodniem. Opisujemy też, skąd pochodził ruch, i podajemy krótką listę rzeczy, które warto sprawdzić na własnych serwerach. Wszystkie dane są zagregowane. Nigdy nie podajemy pojedynczych adresów ani systemów i uwzględniamy wyłącznie wzorce obserwowane z wielu niezależnych źródeł. Każde wydanie dotyczy tygodnia, który zakończył się co najmniej siedem dni przed publikacją.

Od 19 do 25 października około 240 źródeł skanowało naszą infrastrukturę dostępną z internetu w poszukiwaniu repozytoriów kodu źródłowego pozostawionych na serwerach WWW. To o 137% więcej niż średnia tygodniowa z dwóch poprzednich tygodni. Skanery żądały plików takich jak /.git/config, /.git/index i /.svn/entries. W tym tygodniu jedynym celem w naszej infrastrukturze, który przyciągnął więcej skanerów niż kod źródłowy, był WordPress.

W tym samym czasie przybyło też pokrewnych wyszukiwań w naszych serwisach. Liczba źródeł polujących na pliki z kluczami do chmury wzrosła o 51%, a źródeł żądających kopii zapasowych i zrzutów baz danych o 75%. Zaobserwowaliśmy również skanery szukające całej grupy plików .env w podkatalogach, które wcześniej budziły znacznie mniejsze zainteresowanie. Żaden z tych celów nie jest błędem w oprogramowaniu. Każdy z nich to plik, którego ktoś zapomniał usunąć z publicznego serwera.

Tydzień w skrócie

Odnotowaliśmy około 660 różnych źródeł, o 28% więcej niż w tym samym okresie bazowym. Najwięcej źródeł, 56%, przyciągnęły strony logowania WordPress, XML-RPC i ścieżki wtyczek. Pliki z sekretami i konfiguracją przyciągnęły 32% źródeł. Liczba źródeł szukających stron diagnostycznych, takich jak /info.php, wzrosła o 33%, a źródeł sondujących wewnętrzne mechanizmy aplikacji, takie jak /actuator/env, o 37%.

Spośród źródeł, które do nas dotarły, 88% używało ciągów User-Agent podszywających się pod zwykłe przeglądarki, a 64% pochodziło z wynajmowanych serwerów. Najczęściej występujące kraje to Stany Zjednoczone, Niemcy, Holandia, Singapur i Indie.

Jak odsłonięty folder .git zdradza witrynę

Większość zespołów programistycznych śledzi zmiany w kodzie za pomocą systemu Git, a każdy projekt Git przechowuje swoją historię w ukrytym folderze .git. Jeśli witryna trafia na produkcję przez skopiowanie całego folderu projektu na serwer WWW, ten ukryty folder może zostać skopiowany razem z nim, a wtedy każdy, kto zażąda jego plików, może je odczytać.

/.git/config należał do najczęściej żądanych ścieżek związanych z kodem źródłowym w naszej infrastrukturze dostępnej z internetu. Ten plik wskazuje repozytorium, z którego pochodzi kod, a czasem zawiera dane uwierzytelniające używane przy wdrożeniu. Skanery żądały od nas też plików /.git/head, /.git/logs/head i /.git/index, które pokazałyby, czy da się odczytać wystarczająco dużą część folderu, by pójść dalej. Gdy folder jest odsłonięty, atakujący mogą czasem odtworzyć pełny kod źródłowy i historię commitów.

To częsty błąd. Badanie opisane w lutym 2026 roku wykazało około 4.96 mln publicznych serwerów WWW ujawniających metadane Git. Na 252 733 z nich plik config zawierał dane uwierzytelniające do wdrożeń, co według tego samego raportu może prowadzić do przejęcia repozytorium i ataków na łańcuch dostaw.

Sekrety w nieoczekiwanych folderach

Skanery żądały od naszych witryn pliku /.env w katalogu głównym, ale w tym tygodniu wiele z nich szukało go też w podkatalogach. /mailer/.env przyciągnął 40 źródeł, czyli 7.8 raza więcej niż wynosiła jego dotychczasowa średnia. /live/.env, /mail/.env, /v3/.env, /sitemaps/.env, /releases/.env i /exapi/.env przyciągnęły po 40 źródeł, mniej więcej sześć do siedmiu razy więcej niż ich dotychczasowe średnie. Cztery ścieżki pojawiły się u nas po raz pierwszy, każda z około 10 źródeł: /core/database/.env, /.changeset/config.json, /secrets i /settings/credentials.

Dla atakującego te pliki są warte zachodu. Aplikacje webowe przechowują w plikach .env klucze API, hasła do baz danych i klucze dostępowe do chmury. Śledztwo z kwietnia 2026 roku dotyczące jednego masowego skanera ujawniło pliki .env wykradzione z ponad 900 zaatakowanych firm, przy czym między 10 a 21 kwietnia 2026 roku zebrano ponad 30 000 różnych nazw plików .env. Skradzione sekrety dotyczyły usług AI, chmurowych, płatniczych i komunikacyjnych.

Ten sam wzorzec zaobserwowaliśmy w przypadku danych uwierzytelniających do chmury. /application_default_credentials.json przyciągnął 40 źródeł, czyli 6.2 raza więcej niż wynosiła jego dotychczasowa średnia. Skanery żądały od nas także plików /service-account.json i /.config/gcloud/application_default_credentials.json. Ten plik tworzy narzędzie wiersza poleceń chmury podczas logowania, a według wytycznych samego dostawcy jest on przechowywany w postaci niezaszyfrowanej i pozwala każdemu, kto go posiada, bezterminowo uzyskiwać tokeny dostępu. Jeśli jego kopia trafi do katalogu głównego serwera WWW, atakujący, który ją znajdzie, zachowa dostęp aż do jej unieważnienia.

Jedno skanowanie, wiele celów

Kilka skoordynowanych grup źródeł przepuszczało przez naszą infrastrukturę dostępną z internetu te same listy ścieżek. W jednej z nich 20 źródeł z 7 krajów żądało tych samych 8 ścieżek, w tym /.git/config, /.env, /info.php, /config.json, /actuator/env i /server-status. Większość z nich rozpoczęła działanie w odstępie nie większym niż 60 godzin. Dwie mniejsze grupy, liczące po około 10 źródeł, używały znacznie dłuższych list, obejmujących 210 i 158 ścieżek. Obie zawierały /.git/config, warianty .env, takie jak /.env.old i /.env.development, oraz pliki z kluczami do chmury.

Ścieżka /actuator/env należy do tej samej rodziny. Gdy endpoint Spring Boot Actuator w aplikacji Java jest dostępny bez logowania, zwraca zmienne środowiskowe i konfigurację aplikacji, w tym potencjalnie dane uwierzytelniające do baz danych i klucze do chmury. Zmienne środowiskowe mogą ujawniać także pozostawione strony phpinfo, a w naszej infrastrukturze zainteresowanie ścieżką /admin/phpinfo.php wzrosło do poziomu 5.9 raza wyższego niż jej dotychczasowa średnia. W jednym rzeczywistym przypadku wtyczka WordPress zawierała plik phpinfo.php, który mógł otworzyć każdy.

WordPress stał się celem osobnej kampanii wymierzonej w nasze witryny: 20 źródeł z 7 krajów żądało pliku /xmlrpc.php oraz kopii wlwmanifest.xml w zgadywanych folderach, takich jak /blog/wp-includes/wlwmanifest.xml i /wordpress/wp-includes/wlwmanifest.xml. Żądanie tego samego pliku pod wieloma nazwami folderów to szybki sposób, by ustalić, czy witryna korzysta z platformy WordPress, a jeśli tak, to w którym miejscu. Przez XML-RPC atakujący może sprawdzić setki, a nawet tysiące haseł w jednym żądaniu.

Co zrobić w tym tygodniu

• Sprawdź z zewnątrz. Z sieci spoza swojej infrastruktury wyślij do każdej ze swoich witryn żądania /.git/config i /.env. Jeśli którekolwiek z nich zwróci rzeczywistą zawartość, przyjmij, że ktoś już ją odczytał.
• Wdrażaj gotowe artefakty, a nie katalogi robocze. Publikuj tylko pliki potrzebne witrynie i zablokuj dostęp z sieci do .git, .env i innych ukrytych plików.
• Wymień wszystko, co wyciekło. Jeśli pliki .git lub .env dało się odczytać, zmień zawarte w nich dane uwierzytelniające i klucze. Usunięcie pliku nie cofnie kopii, którą ktoś już zrobił.
• Trzymaj sekrety poza katalogiem głównym serwera WWW. Przechowuj pliki .env i pliki z danymi uwierzytelniającymi do chmury poza wszelkimi publikowanymi folderami. Jeśli plik z danymi uwierzytelniającymi kiedykolwiek był publicznie dostępny, unieważnij go.
• Posprzątaj pozostałości. Skasuj kopie zapasowe takie jak /wp-config.php.bak i /database.sql oraz usuń strony phpinfo i strony debugowania.
• Zamknij endpointy zarządzania. Zabezpiecz endpointy Actuator uwierzytelnianiem i wyłącz XML-RPC w witrynach WordPress, które z niego nie korzystają.

O tych obserwacjach

Ten raport przygotowuje 291 Heat Seeker One, system monitorowania bezpieczeństwa 291 Group, działający na 291 Crossband, naszej autorskiej platformie operacji bezpieczeństwa. Raport obejmuje wyłącznie ruch kierowany do infrastruktury 291 Group dostępnej z internetu.

Liczby są zaokrąglone, a udziały i zmiany mierzymy liczbą niezależnych źródeł, a nie liczbą żądań. Uwzględniamy wyłącznie wzorce zaobserwowane z co najmniej 20 niezależnych źródeł.