Wyciek w GitLab RedHat – co się wydarzyło, jakie dane wyciekły, jak się chronić

Co się stało — opis incydentu

Wstęp i potwierdzenie

W październiku 2025 roku Red Hat potwierdził, że doszło do nieautoryzowanego dostępu do instancji GitLab wykorzystywanej przez zespół konsultingowy Red Hat (Red Hat Consulting). CyberScoop+3redhat.com+3SecurityWeek+3

Atakujący – grupa Crimson Collective – ogłosili, że wykradli około 570 GB skompresowanych danych z 28 000 prywatnych repozytoriów. Help Net Security+4SecurityWeek+4blog.gitguardian.com+4

Repozytoria dotyczyły głównie projektów konsultingowych Red Hat – tzw. Customer Engagement Reports (CERs), przykładowego kodu, specyfikacji projektów i wewnętrznych komunikacji związanych z konsultacjami. CyberScoop+5redhat.com+5blog.gitguardian.com+5

Red Hat zapewnia, że inne usługi, w tym łańcuch dostaw, kod źródłowy produktu i kanały dystrybucji, nie zostały naruszone (przynajmniej na obecnym etapie analizy). redhat.com+2SecurityWeek+2

Zakres wycieku i jakie dane mogły być odsłonięte

Co konkretnie mogło wyciec

Na bazie oświadczeń Red Hat i analiz niezależnych:

• Customer Engagement Reports (CERs): raporty z projektów konsultingowych – zawierają opisy architektury, diagramy sieci, ustawienia konfiguracji, dane infrastrukturalne (VPN, serwery, połączenia) CyberScoop+5cybersecuritydive.com+5blog.gitguardian.com+5
• Fragmenty kodu / przykładowy kod – kod demonstracyjny, skrypty automatyzacji, konfiguracje etc. Dark Reading+3redhat.com+3SecurityWeek+3
• Komunikacje wewnętrzne związane z konsultacjami – notatki, wymiany maili lub dokumenty dotyczące projektów i interakcji z klientem. redhat.com+2SecurityWeek+2
• Dane klienta, ale ograniczone: choć Red Hat twierdzi, że nie znaleziono danych osobowych ani użytkowników końcowych w dotychczasowym etapie analizy, dane pośrednie jak struktura sieci, tokeny integracyjne, dane klienta jako część projektu mogą być w CER. cybersecuritydive.com+5redhat.com+5SecurityWeek+5

Organizacje, które mogły zostać dotknięte

Analizy sugerują, że w CER-ach wymieniono wielu znanych graczy: banki, firmy telekomunikacyjne, instytucje rządowe, duże korporacje. W publikacjach pojawiają się nazwy takie jak Walmart, HSBC, American Express, Siemens, Verizon, instytucje rządowe USA, inne. Dark Reading+4cybersecuritydive.com+4blog.gitguardian.com+4

W niektórych analizach pojawia się sugestia, że nawet 800 organizacji mogło być objętych danymi z CER. blog.gitguardian.com+2SecurityWeek+2

Jak to się stało — możliwy przebieg ataku

Choć Red Hat nie ujawnia pełnych szczegółów metody ataku, z analizy doniesień nazwijmy możliwe etapy:

1. Wejście początkowe (Initial Access)
   Atakujący zdobyli dostęp do instancji GitLab (self-managed) – możliwe vektor: słaba konfiguracja dostępu, przestarzała wersja GitLab, kompromitacja konta z uprawnieniami administracyjnymi albo błąd zero-day w instancji GitLab.
2. Eksploracja środowiska / eskalacja uprawnień
   Poruszanie się po repozytoriach konsultingowych, identyfikacja repozytoriów z danymi klientów, poszukiwanie tokenów dostępowych, skryptów, konfiguracji zawierających dane dostępu.
3. Eksfiltracja danych
   Skopiowanie dużej ilości repozytoriów i plików (570 GB danych skompresowanych) do zewnętrznego serwera. redhat.com+3SecurityWeek+3blog.gitguardian.com+3
4. Wymuszenie / extorsja
   Grupa Crimson Collective żądała od Red Hat okup i groziła ujawnieniem danych, jeśli Red Hat nie odpowie w terminie. blog.gitguardian.com+3Techzine Global+3BleepingComputer+3
   Następnie inny podmiot – ShinyHunters – włączył się w żądania extorsji, publikując próbki danych na platformie wycieków i współpracując z Crimson Collective. Techzine Global+2BleepingComputer+2

Jak zauważyć taki problem i wykrywać incydenty

Monitorowanie aktywności Git / repozytoriów

• Logi dostępu GitLab: kto, kiedy, jakie repozytorium, jakie operacje (klonowanie, push, fetch).
• Anomalie w klonowaniu dużych ilości repozytoriów: nagły masowy git clone lub git archive z wielu projektów – alarm.
• Dzienniki systemowe (audit logs) dla procesu GitLab i serwera (np. /var/log/auth.log, logi SSH, logi systemowe).
• Wskaźniki „secrets / tokeny w repozytorium” – narzędzia takie jak git-secrets, truffleHog, repo-scan mogą skanować istniejące repozytoria w poszukiwaniu zaszytych poświadczeń.
• Monitorowanie ruchu sieciowego: outbound transfer duże pakiety z serwera GitLab do zewnętrznych adresów – alarm.
• Wewnętrzne rozwiązania DLP / EDR / SIEM – agregowanie alertów, korelacja aktywności.

Alerty i wskaźniki kompromitacji

• Nieautoryzowane logowania adminów lub kont systemowych
• Nagłe zmiany uprawnień repozytoriów
• Nowe lub nieznane repozytoria w instancji
• Zmiany plików konfiguracyjnych GitLab
• Procesy kompresji / pakowania wielu repozytoriów

Jak reagować na taki incydent — kroki działania

Poniżej propozycja planu reakcji (Incident Response):

1. Izolacja i odcięcie dostępu
   • Odcięcie sieciowe instancji GitLab od zewnętrznych interfejsów.
   • Zmiana haseł i wycofanie kluczy dostępowych.
   • Dezaktywacja kont i sesji administracyjnych.
2. Zgromadzenie dowodów (forensic)
   • Zrzuty systemów plików, logów GitLab, logów OS, zrzuty pamięci (jeśli to możliwe).
   • Zabezpieczenie logów i procesów pomiarowych, aby uniknąć modyfikacji.
3. Analiza zakresu wycieku
   • Które repozytoria zostały sklonowane / pobrane?
   • Jakie pliki w nich były – kod, dokumenty, konfiguracje?
   • W poszukiwaniu wrażliwych danych: hasła, tokeny, łańcuchy połączeń do bazy danych, pliki certyfikatów, skrypty automatyzacji.
   • Sprawdzenie, czy dane z wycieku były używane do dalszych ruchów wewnętrznych (pivot).
4. Powiadomienia / komunikacja
   • Poinformowanie klientów dotkniętych wyciekiem (zwłaszcza tych, których dane mogły być w CER).
   • Zgłoszenie incydentu do odpowiednich organów (np. krajowe organy ds. cyberbezpieczeństwa, CERT).
   • Komunikat publiczny, jeśli to konieczne.
5. Remediacje i wzmocnienie bezpieczeństwa
   • Audyt i naprawa ustawień GitLab: zabezpieczenia dostępu (MFA, ograniczenia IP, RBAC).
   • Przegląd repozytoriów: usunięcie wrażliwych danych i migracja ich do bezpiecznych repozytoriów/secrets managera.
   • Rotacja wszystkich kluczy, tokenów i haseł używanych w projektach konsultingowych.
   • Wdrożenie skanowania tajemnic (secrets scanning) i ciągłego monitoringu repozytoriów.
   • Backup i plan odtwarzania, ale w bezpiecznym środowisku.
   • Przeprowadzenie testów penetracyjnych i audytów bezpieczeństwa.
6. Monitorowanie i ocena wpływu
   • Śledzenie prób wykorzystania danych – np. logowań, prób dostępu spoza normalnej lokalizacji.
   • Korelacja alarmów w SIEM, analizowanie anomalii.

Garść ciekawostek i przemyśleń

• Grupa Crimson Collective określiła swój atak jako czysto extortion, bez dodatku ransomware, operując na tipie „daj pieniądze albo upublicznimy dane”. BleepingComputer+2Techzine Global+2
• W kolejnych etapach do żądań dołączył ShinyHunters, który przejął aspekt publikacji danych. To pokazuje, że niektóre grupy specjalizują się w mechanizmach wycieku/extorsji („leak-as-a-service”). Techzine Global+2BleepingComputer+2
• Choć dane konsultingowe zawierają wrażliwe informacje, Red Hat zapewnia, że instancja ta nie przechowuje zazwyczaj danych osobистych klientów końcowych. redhat.com+2SecurityWeek+2
• Co ciekawsze: GitLab wyjaśnił, że atak nie dotyczył infrastruktury GitLab.com — była to samodzielna instancja Red Hat (self-managed GitLab CE). Dark Reading+3CyberScoop+3SecurityWeek+3
• Dla usług konsultingowych incydent pokazuje, jak bardzo niebezpieczne jest przechowywanie zaszytych poświadczeń w repozytoriach – konsultanci często używają kodów demonstracyjnych z kluczami, co drastycznie zwiększa ryzyko. Aembit+1