Cel czytelnika: po co analizować atak od logów VPN do włamania
Intencja jest prosta: zrozumieć, jak z pozornie „nudnych” logów VPN wrzuconych na Dark Web rodzi się pełnoprawne włamanie do startupu oraz przełożyć tę wiedzę na bardzo konkretne zmiany w konfiguracji, procedurach i monitoringu. Innymi słowy: prześledzić cały łańcuch ataku i zamknąć po kolei wszystkie luki, które napastnik wykorzystał.
Tło incydentu: jak logi VPN startupu trafiły na Dark Web
Profil startupu i jego środowiska IT
Scenariusz dotyczy średniego startupu produktowego z branży SaaS B2B. Zespół około kilkudziesięciu osób: programiści, product, sales, marketing, kilka osób od supportu technicznego. Infrastruktura głównie w chmurze, z elementami on-premise: serwer plików, serwer AD, kilka maszyn wirtualnych. Do zdalnego dostępu używany jest klasyczny VPN, który otwiera drogę do sieci wewnętrznej.
Technologicznie obraz jest znajomy: VPN typu SSL lub IPsec (często gotowy appliance od dużego vendora), do tego GitLab / GitHub, CI/CD (Jenkins, GitLab CI, GitHub Actions), Jira, Slack / Teams, parę usług SaaS do księgowości i HR. Dostęp deweloperów i adminów do produkcji zabezpieczony właśnie przez tunel VPN, czasem dodatkowo przez bastion SSH. Użytkownicy korzystają z laptopów służbowych z Windows 10/11, część z macOS, większość w modelu BYOD jeśli chodzi o telefony.
Startup rósł szybko i – jak to bywa – bezpieczeństwo często przegrywało z terminami release’ów. VPN wdrożono na początku działalności „na szybko”, potem dokładano zasoby, ale nikt nie wrócił do porządnego przeglądu uprawnień, segmentacji i konfiguracji. W teorii istniały procedury haseł, offboardingu i aktualizacji, w praktyce – różnie z tym bywało.
Co konkretnie wyciekło i gdzie to znaleziono
Incydent zaczyna się od odkrycia dumpa zatytułowanego w stylu „vpn-logs-2023-2024-companyX” na jednym z popularnych forów na Dark Webie. Paczka pojawiła się w sekcji poświęconej dostępowi do sieci korporacyjnych. Dane wypatrzył zewnętrzny partner bezpieczeństwa prowadzący dla startupu podstawowy monitoring Dark Webu.
W dumpie znajdują się:
surowe logi z serwera VPN (pliki tekstowe lub JSON-y eksportowane z systemu logowania),
fragmenty konfiguracji VPN (np. nazwy hostów, profile połączeń),
czasami dodatkowe pliki: skrypty pomocnicze, wygenerowane raporty logowań.
Miejsce publikacji sugeruje, że ktoś chciał sprzedać lub udostępnić te dane pod dalsze ataki, ewentualnie pochodzą one z wcześniejszego, bardziej „hurtowego” włamania do innego systemu, skąd przy okazji zgrano logi VPN tej firmy. Źródło samego wycieku (czy to błędnie wystawiony serwer syslog, czy skompromitowana stacja admina) będzie przedmiotem osobnej analizy, ale na potrzeby rekonstrukcji ataku najważniejsza jest zawartość plików.
Charakter logów: format, zakres danych i ich świeżość
Logi VPN zwykle wyglądają mało spektakularnie. W praktyce stanowią jednak bogate źródło informacji dla napastnika. Przykładowy rekord zawiera:
login użytkownika (często w formie maila firmowego),
zewnętrzny adres IP, z którego zestawiono połączenie,
przypisany adres IP w sieci wewnętrznej,
czas rozpoczęcia i zakończenia sesji,
information o powodzeniu lub niepowodzeniu logowania,
niekiedy user-agent klienta VPN lub systemu operacyjnego,
kody błędów (np. nieprawidłowe hasło, błąd certyfikatu itd.).
W analizowanym przypadku logi obejmowały okres około kilku miesięcy i były stosunkowo świeże – ostatnie wpisy pochodziły sprzed zaledwie kilku dni. To kluczowy element: świeży dump logów oznacza, że większość kont, urządzeń i schematów logowania jest nadal aktualna. Dodatkowo w paczce znalazły się fragmenty raportu generowanego przez administratora – z listą najaktywniejszych użytkowników, czasów połączeń i agregacją błędnych logowań.
Na tym etapie napastnik widzi już: ilu jest użytkowników VPN, jak często i skąd się logują, jakie loginy występują oraz które konta są „ważniejsze” (dłuższe sesje, nocna aktywność, adresy IP z serwerowni lub operatorów data center, bardziej techniczne user-agenty).
Wstępna ocena skali i pierwsza reakcja zespołu
Partner bezpieczeństwa przesyła zrzut ekranu z ogłoszenia na Dark Webie i próbkę logów. W startupie wywołuje to klasyczną mieszankę: od paniki i prób „wyłączenia wszystkiego”, po głosy typu „to tylko logi, przecież nie ma tam haseł”. Tu pojawia się pierwszy test dojrzałości organizacji.
Sensowna pierwsza reakcja wygląda tak:
wyznaczenie osoby odpowiedzialnej za koordynację (incident manager, zwykle security lead, CTO lub doświadczony DevOps),
szybka weryfikacja próbki logów: czy format zgadza się z serwerem VPN, czy dane są prawdziwe i czy są aktualne,
tymczasowe zamrożenie działań: wstrzymanie niekrytycznych zmian w infrastrukturze, aby nie zacierać śladów,
decyzja o natychmiastowym włączeniu szczegółowego monitoringu logów VPN i systemów krytycznych.
Nerwowe zmiany haseł „na oślep” czy restartowanie wszystkiego bez planu może bardziej zaszkodzić niż pomóc. Na tym etapie liczy się chłodna ocena sytuacji i szybkie zrozumienie, co w logach jest dla napastnika użyteczne.
Co napastnik widzi w logach VPN: mapa drogowa do ataku
Najcenniejsze informacje w wyciekłych logach VPN
Dla kogoś, kto umie czytać logi, dump z serwera VPN jest jak mapa: nie widać jeszcze wnętrza budynku, ale można zrozumieć drzwi, korytarze i godziny pracy ochrony. Kilka elementów jest szczególnie atrakcyjnych:
nazwy użytkowników i format loginów – zwykle maile firmowe lub loginy typu imię.nazwisko; dają one natychmiastową listę celów,
wzorce logowania – o której godzinie kto się łączy, jak długo trwa sesja; to pozwala ocenić, które konta są aktywne i ważne,
informacje o błędnych logowaniach – ilu użytkowników się „myli”, o której, z jakich IP; to podpowiada, jak tolerancyjny jest system na pomyłki,
adresy IP i geolokalizacja – kraje, miasta, a nawet dostawcy internetu użytkowników,
user-agenty lub identyfikatory klientów – wskazują, jakiego oprogramowania i systemów używają pracownicy.
Niektóre wdrożenia logują także identyfikatory urządzeń, nazwy hostów (np. „DEV-MACBOOK-01”) czy grupy użytkowników. To dodatkowe puzzle, które atakujący układa w spójny obraz.
Szybkie profilowanie ofiar i identyfikacja „VIP-ów”
Napastnik nie będzie atakował w ciemno wszystkich kont. Z logów VPN wybiera te, które wydają się najbardziej opłacalne. Analiza może wyglądać następująco:
sortowanie po czasie trwania sesji i częstotliwości logowań – konta DevOps, adminów, senior developerów logują się często i długo,
szukanie loginów z wzorcami typu admin, devops, root, support, infra,
identyfikacja nietypowych godzin logowania (nocne, weekendowe sesje) – sugerują osoby z szerszymi uprawnieniami lub odpowiedzialnością za utrzymanie,
mapowanie IP do regionów – gdy większość użytkowników loguje się z Polski, a kilka kluczowych kont z adresów data center w innych krajach, łatwo wyłapać np. zdalnych adminów.
Dodatkowo, jeśli w dumpie znalazły się raporty lub wycinki konfiguracji z podpisami typu „VPN_Engineering”, „VPN_AdminOnly”, napastnik od razu wie, że dany zestaw logów dotyczy użytkowników technicznych, a nie wszystkich pracowników.
Korelacja logów VPN z innymi wyciekami i bazami
Logi VPN same w sobie zwykle nie zawierają haseł. Ale login i e-mail to klucze, które można wrzucić do hurtowni danych z innych wycieków. Atakujący korzysta z:
publicznych i prywatnych baz typu „have I been pwned” – do wyszukania, czy dany e-mail pojawił się w przeszłych wyciekach,
dumpów z innych serwisów (portale, stare fora, SaaS-y), gdzie ujawniono pary mail + hasło,
skryptów do automatycznego wyszukiwania wzorców haseł używanych przez danego użytkownika.
Jeśli dla pracownika jan.kowalski@startup.pl napastnik znajdzie w innych wyciekach hasło w stylu Janek2020!, bardzo prawdopodobne, że spróbuje wariacji tego hasła w dostępie do VPN: Janek2023!, Janek2024! itd. W połączeniu z informacją, że użytkownik loguje się do VPN głównie w godzinach 8–16 z IP z Warszawy, napastnik ma już całkiem wygodną bazę do ataku.
Odgadywanie architektury i opłacalności ataku
Z samych logów VPN można wyłuskać sporo informacji o architekturze:
przestrzeń adresową sieci wewnętrznej (np. 10.10.0.0/16; w logach widać adresy przydzielane klientom VPN),
nazwy hostów i serwerów (czasem pojawiają się w komunikatach systemowych lub raportach),
czy sieć wygląda na płaską (każdy klient dostaje IP z tej samej puli) czy segmentowaną,
czy serwer VPN jest w chmurze, on-premise czy w data center (na podstawie IP serwera i reverse DNS).
Na tej podstawie napastnik ocenia opłacalność ataku: czy mamy do czynienia z niewielkim środowiskiem, czy większą infrastrukturą z potencjalnie ciekawymi danymi (kody źródłowe, dane klientów, klucze do chmury). Jeśli w logach widać loginy typu „aws-admin”, „gcp-root” czy „db-admin”, szala przechyla się wyraźnie na „atakować”.
Gdy napastnik decyduje się wejść do gry, kolejnym krokiem jest przetestowanie tego, co już wie, na żywym systemie VPN.
Wejście do gry: pierwsze próby logowania i obejście zabezpieczeń VPN
Testowanie poświadczeń w praktyce – od teorii z logów do realnych prób
Uzbrojony w listę użytkowników, wzorce logowań i potencjalne hasła z innych wycieków, atakujący przechodzi do działań praktycznych. Zwykle zaczyna subtelnie, aby nie wzbudzić alarmu:
wybiera kilka kont o średnim poziomie podejrzeń (nie od razu CTO czy „root”),
wykorzystuje adresy IP z tego samego kraju / regionu co ofiary (VPN komercyjny, VPS, proxy),
próbuje 1–2 hasła na konto w odstępach czasowych, aby nie wywołać blokady.
Jeśli środowisko VPN ma słabe lub brakujące mechanizmy account lockout (blokowanie po X nieudanych próbach), napastnik stopniowo zwiększa liczbę prób. Gdy ma dane z kilku wycieków, może prowadzić sprytny password spraying, gdzie jedno hasło jest próbowane na wielu kontach, zamiast wielu haseł na jednym koncie – co jest trudniejsze do wykrycia.
Co zawiodło w konfiguracji VPN: brak blokad, alertów i poprawnego MFA
W analizowanym scenariuszu wystąpiło kilka klasycznych błędów konfiguracji serwera VPN:
brak rygorystycznych limitów nieudanych logowań – użytkownik mógł mylić się dziesiątki razy bez blokady konta czy dodatkowego uwierzytelnienia,
brak sensownych alertów – system SIEM albo nie istniał, albo nie miał zdefiniowanych reguł typu „X nieudanych logowań z nowych krajów”,
słaby MFA – tam, gdzie MFA był włączony, używano SMS lub maili, a do tego istniała opcja „zapamiętaj to urządzenie” na miesiące; wiele kont nie miało wymuszonego MFA w ogóle,
brak kontroli geolokalizacji i nietypowych godzin logowania – logowania z innych kontynentów o 3 nad ranem nie generowały ostrzeżeń.
Napastnik korzystał z VPS-ów w regionie, w którym normalnie łączą się pracownicy, więc ewentualny „geofencing” oparty tylko na kraju i tak by nie pomógł. Problemem była też niekonsekwencja organizacji: część krytycznych kont adminów działała nadal bez MFA „tymczasowo”, bo migracja była w toku, a stary mechanizm SSO nie współpracował dobrze z klientem VPN.
Użycie proxy i dostosowanie geolokalizacji do wzorców ofiary
Stopniowe „oswajanie” systemu i uczenie się reakcji obrony
Sam dostęp do ekranu logowania VPN to już źródło informacji. Zanim napastnik zacznie agresywnie testować hasła, bada, jak system reaguje na różne sytuacje:
sprawdza, czy błędne loginy (nieistniejące konta) zwracają inny komunikat niż błędne hasła dla istniejących użytkowników,
obserwuje opóźnienia odpowiedzi – czy po kilku błędnych próbach pojawia się dodatkowy „lag”, sugerujący mechanizmy ochronne,
testuje logowania o różnych porach dnia, aby zobaczyć, czy którykolwiek z nich wywołuje nienaturalne przerwy, np. restart serwera VPN czy chwilową niedostępność.
Do tego może dochodzić pasywna obserwacja: gdy serwer VPN udostępnia stronę statusową lub baner logowania z komunikatami typu „Planowane prace serwisowe”, napastnik odnotowuje sobie terminy. Okresy zmian konfiguracyjnych to zwykle momenty, w których monitoring generuje więcej szumu, co utrudnia wychwycenie anomalii.
Jeżeli kilka pierwszych, rozłożonych w czasie prób nie powoduje blokad ani dodatkowych kroków (np. wymuszenia resetu hasła), napastnik wie, że może pozwolić sobie na odrobinę większą śmiałość. Zaczyna delikatny taniec pomiędzy byciem „niewidzialnym” a skutecznym w zgadywaniu poświadczeń.
Specjalizacja ataku pod konkretnych pracowników
W tym momencie na scenę wchodzi OSINT. Mając już listę kont z logów VPN, napastnik prześwietla wybrane osoby w sieci:
LinkedIn, GitHub, Twitter/X, stare blogi techniczne,
przemówienia na konferencjach, nagrania z meet-upów,
profile na Stack Overflow i innych portalach branżowych.
Z tego składa się obraz: kto naprawdę ma wpływ na infrastrukturę, kto jest „gwiazdą DevOpsa”, a kto raczej juniorem od frontendu. Na liście priorytetów pojawiają się konta, które łączą częste logowania VPN, seniorność techniczną i ślady w sieci, że dana osoba „robi chmurę” lub „opiekuje się produkcją”.
To nie jest przypadkowe: im lepiej dobrany cel, tym mniejsza liczba koniecznych prób i tym mniejsze ryzyko wywołania alarmu. Jedno dobrze dobrane konto inżyniera infrastruktury zastępuje tuzin średnio przydatnych kont użytkowników biznesowych.
Źródło: Pexels | Autor: Stefan Coders
Od dostępu VPN do przyczółka w sieci wewnętrznej
Pierwsze udane logowanie: co widać po drugiej stronie tunelu
W końcu jedna z kombinacji login + hasło trafia. Brak wymuszonego MFA na danym koncie robi swoje. Klient VPN zestawia połączenie, przydzielany jest adres z puli, a napastnik po raz pierwszy znajduje się logicznie „w biurze”.
Dalsze działanie zależy od tego, jak zaprojektowano dostęp:
czy po VPN widać całe 10.10.0.0/16, czy tylko kilka podsieci,
czy istnieje segmentacja: osobna sieć dla pracowników, osobna dla serwerów, osobna dla CI/CD,
czy firewall wewnętrzny filtruje ruch od klientów VPN, czy traktuje ich jak „zaufane” stacje robocze.
W realnym incydencie napastnik często zaczyna bardzo ostrożnie: wykonuje kilka poleceń typu ping do najbardziej oczywistych hostów (gateway, DNS, adres serwera VPN), obserwuje wpisy w tablicy routingu, sprawdza konfigurację przydzielonego interfejsu. Celem jest rozpoznanie, jak daleko sięga jego wzrok, zanim zacznie aktywne skanowanie.
Ciche rozpoznanie: powolne skanowanie i enumeracja
Jeśli sieć jest niewielka, a monitoring niekoniecznie wyczulony na nietypowe ruchy, napastnik uruchamia powolne, rozproszone skanowanie. Zamiast jednego agresywnego nmap -p- 10.10.0.0/16, wykonuje serię małych, niepozornych kroków:
skanuje tylko kilka wybranych hostów sugerowanych przez trasy czy DNS,
korzysta z dużych interwałów i losowych odstępów między pakietami,
ogranicza się początkowo do kilku kluczowych portów (22, 80/443, 3389, 5432, 3306, 6379, 27017).
Bardzo szybko pojawia się lista „interesujących celów”: serwer Git, panel CI/CD, wewnętrzny panel admina, klastry baz danych, może jakiś stary Jenkins z webowym UI. W logach DNS widać czasem jeszcze więcej – nazwy hostów typu prod-db-01, k8s-master, vault potrafią powiedzieć więcej niż niejedno diagram w Confluence.
Na tym etapie napastnik nadal stara się wyglądać jak normalny użytkownik. Jeżeli konto „jan.kowalski” z reguły spędza w VPN 2–3 godziny dziennie, nie ma sensu nagle generować 12-godzinnej sesji z ruchem do kilkudziesięciu hostów naraz. Lepsza jest strategia „małych kroczków”: kilka krótkich sesji, każda z odrobiną rozpoznania.
Częsty błąd w startupach to zbyt szeroki, niekontrolowany dostęp do paneli wewnętrznych z sieci VPN. Zasada jest prosta: jak już „jesteś w środku”, to możesz prawie wszystko. Napastnik sprawdza więc, do jakich aplikacji ma dostęp przez przeglądarkę:
panele admina SaaS z dostępem po prywatnym IP lub przez reverse proxy,
wewnętrzne narzędzia „dla supportu” z możliwością podglądu danych klientów lub wykonywania akcji w ich imieniu,
panele administracyjne baz danych czy narzędzia typu pgAdmin, Adminer, phpMyAdmin.
Jeżeli zespół nie wdrożył dodatkowej autoryzacji po stronie tych aplikacji (np. osobnego SSO, kontroli ról, mocnego MFA), sam fakt bycia „na VPN” wystarcza, by zobaczyć znacznie więcej, niż przeciętny pracownik powinien. To typowy punkt, w którym atakujący może z „zwykłego” konta pracownika przejąć dostęp do systemów produkcyjnych, choć jeszcze formalnie nie ma żadnych uprawnień administratorskich w infrastrukturze.
Polowanie na poświadczenia i sekrety w środowisku użytkownika
Konto VPN zwykle odwzorowuje zwykłe konto w katalogu (AD, LDAP, Identity Provider). Z punktu widzenia stacji roboczej, na której instalowany jest klient VPN, oznacza to jeden login mniej więcej do wszystkiego. Napastnik, który ma już tunel, próbuje wycisnąć z niego jak najwięcej:
szuka skryptów automatyzujących, plików .env, config.yml, settings.json z wbudowanymi hasłami lub tokenami,
sprawdza dostęp do prywatnych rejestrów Docker/Container Registry, z których da się ściągnąć obrazy aplikacyjne.
Obrazy kontenerów to kopalnia złota: zmienne środowiskowe z hasłami do baz, klucze API do usług zewnętrznych, statyczne tokeny CI/CD. W wielu firmach zasada jest prosta: co ma działać automatycznie, to ma „jakoś” działać – i często tym „jakoś” jest wstrzyknięty gdzieś w środku sekret, który nikt nigdy porządnie nie obrotował.
Budowa trwałego przyczółka: przekierowania, tunelowanie, nowe konta
Nawet jeśli udane logowanie VPN jest jednorazowym „strzałem” (użytkownik za chwilę zmieni hasło lub konto zostanie zablokowane), napastnik próbuje zostawić po sobie trwały ślad w sieci, z którego będzie mógł wrócić:
instaluje na osiągalnych hostach lekkie narzędzia typu reverse shell lub agenta C2,
tworzy dodatkowe klucze SSH na serwerach, do których udało się zalogować,
zakłada nowe konta techniczne w aplikacjach, tam gdzie ma taką możliwość (np. nowy użytkownik w GitLabie z rolą „Developer”).
W startupach z rozproszonym zespołem i intensywnym developmentem nowe konta i klucze nie są niczym niezwykłym. Jeżeli nie ma twardego procesu zatwierdzania zmian dostępowych, „użytkownik techniczny do integracji X” może przejść kompletnie niezauważony.
Eskalacja: od zwykłego konta pracownika do uprawnień administracyjnych
Od Gita do chmury: wykorzystanie repozytoriów jako „instrukcji obsługi” ataku
Najczęstszy scenariusz awansu w hierarchii to przejęcie dostępu do repozytoriów kodu. W logach VPN konto wyglądało na zwykłego developera frontendu, ale w praktyce po zalogowaniu do Gitlaba okazuje się, że ma dostęp do monorepo z całą infrastrukturą jako kod (Terraform, Helm, Ansible). Dla napastnika to jak pełna dokumentacja techniczna:
pliki terraform.tfstate lub ich odpowiedniki wskazują identyfikatory zasobów w chmurze,
konfiguracje pipeline’ów CI/CD zdradzają, jak i gdzie wdrażana jest aplikacja,
skrypty deploy.sh czy bootstrap.py zawierają adresy endpointów, czasem też zakodowane na twardo tokeny.
Do tego dochodzą klucze API i pliki konfiguracyjne do CLI chmurowych (~/.aws/credentials, gcloud, az) w repozytoriach lub w załącznikach do ticketów. Nawet jeśli tokeny są częściowo zredagowane, nazwy ról IAM i użytkowników serwisowych podpowiadają strukturę uprawnień w chmurze.
Przejęcie CI/CD jako „centrum dowodzenia”
Jeżeli konto użytkownika ma uprawnienia do uruchamiania pipeline’ów, edycji jobów lub modyfikacji konfiguracji runnerów, droga do eskalacji staje się krótsza. Atakujący może:
dodać nowy job w istniejącym pipeline, który uruchamia komendy na runnerze z uprawnieniami do chmury,
zmodyfikować definicję joba tak, by wypisywał na logi tymczasowe tokeny dostępu (np. AWS_SESSION_TOKEN),
wykorzystać runnera zainstalowanego na maszynie w prywatnej sieci, aby skanować segmenty niedostępne bezpośrednio z VPN.
Runner CI/CD często działa z dużo szerszymi uprawnieniami niż przeciętny developer. Ma dostęp do środowisk produkcyjnych, może tworzyć i niszczyć zasoby, a do tego bywa zaufanym elementem w wielu innych procesach (deploy, migracje, rotacja kluczy). Przejęcie pipeline’ów może więc w praktyce oznaczać przejęcie całej chmury.
Łańcuchowa eskalacja w chmurze: od roli „ReadOnly” do pełnego admina
Nawet jeśli pierwsze zdobyte poświadczenia chmurowe wydają się mało atrakcyjne (rola typu „ReadOnly” czy „ViewLogs”), napastnik wyciąga z nich maksimum. Dzięki najskromniejszym uprawnieniom można:
zobaczyć listę instancji, baz danych, bucketów,
podejrzeć konfigurację ról IAM, polityk i trust policy,
analizować logi (CloudTrail, CloudWatch, Stackdriver) pod kątem wzorców działań administratorów.
Na tej podstawie budowany jest „atlas zaufania”: które role mogą kogo assume-role, gdzie istnieją błędnie skonfigurowane relacje zaufania (np. rola, która ufa wszystkim użytkownikom z danego konta), które funkcje serverless czy instancje mają za szerokie uprawnienia do KMS, S3, Secret Managera.
Kolejny krok to klasyczny privilige escalation in cloud: wykorzystanie misconfigów IAM i usług tożsamościowych do przeskakiwania z jednej roli do drugiej. Przykładowo:
rola służąca do czytania logów może mieć prawo PassRole do roli deploymentowej,
usługa CI/CD może mieć możliwość tworzenia nowych kluczy dostępowych dla użytkownika technicznego,
funkcja lambda z szerokim dostępem do KMS pozwala odszyfrować sekrety używane przez inne usługi.
Po kilku takich „skokach” napastnik ląduje na roli, która widzi już produkcyjne zasoby danych klientów albo może tworzyć dodatkowe poświadczenia – klucze, tokeny, użytkowników serwisowych – zapewniające utrzymanie się w środowisku nawet po częściowej reakcji obrony.
Atak na tożsamość: phishing wewnętrzny i przejęcie SSO
Z VPN i dostępem do wewnętrznych narzędzi łatwiej o skuteczny phishing. Mail od „działu IT” wysłany z wewnętrznego adresu, z linkiem do „odnowienia sesji SSO”, wygląda przekonująco, gdy link prowadzi do domeny dostępnej tylko z VPN i używanej na co dzień przez pracowników.
Napastnik buduje prostą stronę podszywającą się pod IdP (Okta, Azure AD, Keycloak). Scenariusz jest zwykle prosty:
pracownik dostaje maila lub wiadomość na wewnętrznym komunikatorze z prośbą o ponowne zalogowanie się ze względu na „prace modernizacyjne”,
loguje się na fałszywej stronie, wpisując login, hasło i potwierdzając MFA,
napastnik w czasie rzeczywistym proxy’uje to logowanie do prawdziwego IdP, przechwytując sesję lub token.
Przejmowanie sesji i obejście MFA w praktyce
Techniczny szczegół, który często ginie w dyskusjach o phishingu: napastnik nie potrzebuje znać hasła „na później”, jeśli celem jest aktualna sesja. Wystarczy mu ważny token, cookie SSO albo kod autoryzacyjny z flow OAuth/OIDC. Dlatego najbardziej skuteczne są ataki typu real-time phishing, w których fałszywa strona jedynie pośredniczy w komunikacji:
fałszywy front-end logowania wysyła dane ofiary do serwera atakującego,
serwer natychmiast odtwarza to logowanie przeciwko prawdziwemu IdP,
gdy IdP zwróci token / cookie sesyjne, napastnik zatrzymuje kopię i przekazuje użytkownikowi prawidłową odpowiedź, żeby niczego się nie domyślił.
Z punktu widzenia użytkownika „wszystko działa”: zobaczył znane logo, poprawną domenę (często subdomena sprytnie stylizowana na właściwą), potem standardowy ekran aplikacji. Tymczasem atakujący ma już:
aktywną sesję w SSO w swojej przeglądarce lub przeglądarce bezgłowej,
token ID/Access token, który może użyć z CLI lub narzędziem typu oidc-token,
czasowe okno kilku–kilkunastu godzin działania tej sesji, zanim wygaśnie.
MFA w takiej konfiguracji nie „zawiodło” – zostało poprawnie użyte, tylko na rzecz złej strony. Napastnik nie łamie kryptografii, jedynie podszywa się pod przeglądarkę ofiary i korzysta z jej zaufania do znanych ekranów logowania.
Rozszerzanie dostępu w IdP: od pojedynczej sesji do kontroli nad tożsamościami
Jeżeli przejęta sesja należy do zwykłego pracownika, pole manewru w IdP bywa ograniczone. Nadal jednak można je sensownie wykorzystać. W praktyce napastnik szuka kilku rzeczy:
aplikacji z automatycznym just-in-time provisioningiem (konto tworzy się samo przy pierwszym logowaniu),
aplikacji, w których rola użytkownika jest określana wyłącznie na podstawie grup w IdP,
paneli samoobsługowych, które pozwalają np. wygenerować dodatkowe kody recovery lub backup MFA.
Jednak prawdziwe złoto pojawia się, gdy ofiarą phishingu staje się ktoś z działu IT lub właściciel aplikacji w IdP. Taki użytkownik może:
dodawać inne aplikacje SAML/OIDC do katalogu i przypisywać im grupy,
modyfikować mapowanie atrybutów (np. role=admin dla określonych domen mailowych),
tymczasowo podnosić sobie uprawnienia do ról „break glass” / „super admin”.
Napastnik, mając taką sesję, jest w stanie utworzyć nową aplikację integrującą (np. „Nowe narzędzie do raportowania”), przypisać jej szeroką grupę użytkowników i skonfigurować trust w ten sposób, aby aplikacja dostawała tokeny z uprawnieniami administracyjnymi. Z zewnątrz będzie to wyglądało jak kolejny SaaS, który „ktoś z biznesu” dodał do SSO.
Przejęcie kont serwisowych i tokenów „systemowych”
Konta ludzkie można zablokować, wymusić zmianę hasła, unieważnić sesje. Bardziej kłopotliwe są konta serwisowe i integracyjne, często spięte z SSO lub IdP na dość luźnych zasadach. Typowe ścieżki eskalacji to:
uzyskanie dostępu do panelu administracyjnego aplikacji SaaS z uprawnieniami „Org Admin” i wygenerowanie nowych tokenów API,
przejęcie konta technicznego wykorzystywanego przez narzędzie integracyjne (np. synchronizacja HR–IdP),
wykorzystanie funkcji typu „SCIM provisioning” do dodania zupełnie nowych kont w zaufanych systemach.
W wielu startupach integracje HR–IdP sprowadzają się do jednego „magicznego” użytkownika, który ma prawo tworzyć i zmieniać profile pracowników oraz ich przynależności do grup. Jeżeli uda się wejść w jego buty (przez przejęcie sesji, tokenu SCIM czy klucza API), można:
dodać sobie nowe konto admina, prezentując je jako „kontraktora” z HRIS,
dołączyć istniejące konto napastnika do krytycznych grup (np. cloud-admins, okta-superadmins),
manipulować atrybutami odpowiedzialnymi za poziom dostępu w downstreamowych systemach.
Te zmiany często wyglądają jak zwykłe operacje HR: ktoś dołączył, ktoś odszedł, komuś zmienił się zespół. Dopiero dokładna korelacja logów z IdP, HRIS i chmury pokazuje, że za ruchem stoi nieco zbyt kreatywny „pracownik”.
Od kontroli do nadużyć: co napastnik robi z pełnymi uprawnieniami
Stabilizacja pozycji: ukryte kanały dostępu i „plan B”
Gdy uda się zdobyć najwyższe uprawnienia w chmurze, IdP czy krytycznych aplikacjach, pierwszym impulsem może być „zrobić wszystko naraz”. Doświadczony atakujący postępuje odwrotnie: uspokaja podejrzenia, utrwala dostęp i dopiero potem zaczyna ryzykowniejsze operacje. Typowo:
tworzy dodatkowe role w chmurze z niewinnie brzmiącymi nazwami (np. automation-helper, backup-sync),
konfiguruje nowe pary kluczy dla użytkowników serwisowych, które już istnieją w dokumentacji,
ustawia trust policy między kontami/chmurami, tak aby móc wskoczyć z innego środowiska, gdy główna ścieżka zostanie odcięta.
Równolegle powstają „ciche” kanały komunikacji:
tunelowanie ruchu przez funkcje serverless, joby w CI/CD lub zadania cron w clusterze Kubernetes,
wykorzystanie bezpiecznych kanałów do exfiltracji (np. komunikacja do zewnętrznego S3 / GCS podszytego pod backup),
instalacja agentów z funkcją sleep, które budzą się raz na dobę, by minimalizować szum w logach.
W fazie stabilizacji każda zmiana, którą wykonuje napastnik, jest możliwie podobna do typowego ruchu administratorów lub automatyki infrastruktury. Drobne zwiększenie uprawnień istniejącej roli wygląda subtelniej niż tworzenie nowego, agresywnie nazwanego super-admin-root.
Dostęp do danych: punkt, w którym incydent staje się kryzysem
Wcześniejsze etapy ataku często da się jeszcze zaklasyfikować jako „kompromitację środowiska technicznego”. Gdy dochodzi do hurtowego dostępu do danych klientów, robi się poważnie – zarówno z punktu widzenia ryzyka prawnego, jak i reputacyjnego. Typowe wektory:
bezpośrednie odpytywanie baz danych produkcyjnych (RDS, Cloud SQL, Mongo Atlas),
listowanie i pobieranie plików z bucketów (S3, GCS, Azure Blob),
wyciąganie danych z narzędzi analitycznych i segmentacyjnych (Snowflake, BigQuery, Redshift, Segment, Amplitude).
Wiele startupów trzyma „surowe” dane telemetryczne i eventy w hurtowniach analitycznych. Z punktu widzenia prywatności klienta nie ma większego znaczenia, czy jego dane wyciekły z bazy produkcyjnej, czy z tabeli events_raw – na końcu i tak można zrekonstruować bardzo dokładny profil użytkownika.
Napastnik zwykle nie ściąga wszystkiego naraz. Zaczyna od:
próbnych zapytań SELECT LIMIT 100, by zorientować się w schemacie,
małych eksportów, które nie wyróżniają się na tle regularnych jobów ETL,
wyszukiwania tabel z oczywistymi nazwami (users, payments, sessions, tokens).
Dopiero po rozpoznaniu struktury danych i ustaleniu, które tabele są naprawdę wrażliwe, przechodzi do bardziej zaplanowanej exfiltracji, często maskowanej jako dodatkowy pipeline analityczny.
Manipulacja środowiskiem: od drobnych zmian do sabotażu
Nie każdy atak kończy się na kradzieży danych. Część napastników, zwłaszcza tych mniej cierpliwych, wykorzystuje uprawnienia administracyjne do ingerencji w same systemy. Może to być:
podmiana obrazów kontenerów lub artefaktów deployowanych aplikacji,
dodanie dodatkowego kodu w krytycznych miejscach (np. middleware autoryzacji, moduł płatności),
zmiana konfiguracji mechanizmów bezpieczeństwa – wyłączenie alertów, ograniczenie logowania, „poluzowanie” reguł WAF.
Z zewnątrz wygląda to jak zwykły błąd konfiguracji albo „niedopatrzenie w deployu”. Przykład z życia: jeden z zespołów zorientował się, że ich logowanie audytowe przestało działać po aktualizacji modułu w mikrousłudze odpowiedzialnej za obsługę sesji. Później okazało się, że do obrazu kontenera został dorzucony niewielki sidecar, który wysyłał kopię ruchu HTTP do zewnętrznego endpointu. Sam kod zmieścił się spokojnie w jednym pliku.
Praktycznym celem takich zmian nie jest zawsze natychmiastowe zniszczenie systemu. Czasem chodzi po prostu o to, aby kolejne wejścia były możliwe nawet po „załataniu” pierwotnego wektora ataku. Gdy ktoś zauważy wyciek logów VPN i zablokuje konta, napastnik nadal może mieć furtkę w postaci zmodyfikowanego artefaktu CI/CD albo niepozornego webhooka w aplikacji.
Ataki łańcuchowe na klientów i partnerów
Startupy rzadko działają w próżni. Integracje z klientami enterprise, partnerami technologicznymi, marketplace’ami – to wszystko tworzy gęstą sieć zależności. Gdy napastnik przejmie panelem administracyjnym lub chmurą, szybko zauważa nowe możliwości:
dostęp do kluczy API i tokenów OAuth używanych do integracji z systemami klientów,
możliwość wysyłania „oficjalnych” webhooków z domeny zaufanej przez partnerów,
modyfikację konfiguracji federacji tożsamości (SAML, OIDC) z zewnętrznymi IdP.
Przykładowy scenariusz: startup jest dostawcą SaaS do zarządzania danymi sprzedażowymi dla kilku dużych firm. Każdy klient ma własną integrację opartą o OAuth i zaufanie do domeny startupu. Atakujący, mając roota w panelu, może:
wygenerować nowe tokeny dla aplikacji integracyjnej klienta,
skonfigurować dodatkowy endpoint webhooka i odbierać część eventów,
podmienić konfigurację SAML tak, aby logowania SSO przechodziły przez jego proxy.
W ten sposób pojedynczy incydent u małego dostawcy może stać się wektorem łańcuchowego ataku na wielu dużych klientów. W logach po stronie klienta wszystko będzie wyglądać jak działania „tej samej, zaufanej aplikacji SaaS”, tylko trochę bardziej aktywnej niż zwykle.
Rekonstrukcja śladu: jak atak wygląda z perspektywy logów i monitoringu
Widoczność po fakcie: fragmenty układanki
Gdy incydent wychodzi na jaw (czasem dopiero po publikacji danych na forum lub żądaniu okupu), zespół bezpieczeństwa dostaje w ręce mieszankę logów z różnych systemów. Typowy zestaw obejmuje:
logi VPN z nieudanym i udanym logowaniem oraz przydzielanymi adresami IP,
logi IdP/SSO pokazujące nietypowe logowania, zmiany grup, tworzenie aplikacji integracyjnych,
audit logi z chmury (CloudTrail, Activity Log),
logi aplikacyjne i CI/CD – pipeline’y, które nagle zaczęły robić coś nowego,
logi baz danych i hurtowni – nietypowe zapytania, masowe eksporty, nieplanowane joby ETL.
Na początku wygląda to jak kompletny chaos. Do tego dochodzi zwykły szum – błędy developerów, testowe środowiska, nietypowe zmiany wprowadzone w pośpiechu przed releasem. Dopiero po połączeniu kilku sygnałów zaczyna rysować się linia czasu:
w logach VPN widać pierwsze próby logowania na przejęte konto z nowych adresów IP,
tuż po udanym logowaniu pojawiają się logi z IdP z nowej lokalizacji, ale dla tego samego użytkownika,
kilka minut później w CloudTrail pojawiają się pierwsze próby ListBuckets czy DescribeInstances,
następnie uruchomione pipeline’y CI/CD, których nikt z zespołu „nie pamięta”, aby je modyfikował,
na końcu większe exporty danych i zmiany w konfiguracji ról.
Najbardziej frustrujące są momenty, w których logów brakuje. Albo z powodu oszczędności (krótkie retencje), albo dlatego, że ktoś zbyt entuzjastycznie wyłączył „zbyt głośne” reguły audytu. Napastnik chętnie wykorzystuje takie „ciemne strefy” – zarówno w czasie ataku, jak i podczas utrzymywania się w środowisku.
Charakterystyczne oznaki ataku na bazie kradzionych logów VPN
Mimo że każdy incydent ma swoje niuanse, ataki rozpoczęte od upublicznionych logów VPN mają kilka wspólnych cech. Z perspektywy monitoringu da się je rozpoznać po kombinacji zjawisk:
fala logowań z poprawnym loginem, ale błędnym hasłem, skupiona na niewielkiej liczbie kont,
