Logowanie przez VPN, a potem ransomware: co potwierdzają dowody
Logowanie o 02:14 i zaszyfrowane pliki o 03:02 to sekwencja warta zbadania, nie punkt wejścia. Trzymaj osobno dowody uwierzytelnienia, sesji i hosta.
Wszystko poniżej opiera się na hipotetycznym zapisie, złożonym, by pokazać kształt, a nie opisać rzeczywisty przypadek. Czyta się jak łańcuch: uwierzytelnienie na bramie o 02:14, sesja pulpitu o 02:19, zmiana konta uprzywilejowanego o 02:41 i zaszyfrowane pliki znalezione o 03:02. Pierwszy wiersz wygląda jak odpowiedź i raport często jest pisany tak, jakby nią był. Logowanie to zdarzenie zarejestrowane przez bramę, a nie ustalenie, jak ktoś wszedł, i ta różnica decyduje, co zrobisz dalej.
Objaw: logowanie, które wygląda jak odpowiedź
Zapisy uwierzytelnienia są najłatwiejszym do zdobycia dowodem i najłatwiejszym do nadinterpretacji. Pokazują, że usługa przyjęła dane logowania o pewnym czasie, z pewnego adresu, dla pewnego konta. Nie pokazują, kto kontrolował te dane, czy brama została wykorzystana, ani czy urządzenie właściciela konta było już przejęte.
Trzy wyjaśnienia pasują do tej samej linii logowania. Ktoś użył skradzionego hasła, a brama zrobiła dokładnie to, do czego jest zbudowana. Wcześniej przejęty laptop po prostu zalogował się jak zwykle. Niezwiązana ujawniona usługa zapewniła prawdziwe wejście, a sesja VPN jest późniejszym, odrębnym działaniem tego samego aktora.
Każde wyjaśnienie przewiduje inne dowody gdzie indziej w środowisku, dlatego śledztwo musi szukać tych przewidywań, a nie potwierdzenia pierwszego pasującego wyjaśnienia. Skradzione hasło przewiduje nietypową geografię lub porę uwierzytelnienia. Przejęty laptop przewiduje artefakty hosta przed logowaniem. Niezwiązany punkt wejścia przewiduje aktywność, która nie ma nic wspólnego z bramą.
Trzymaj zdarzenia osobno, zanim je opowiesz
Zapisz zdarzenia osobno, zanim powstanie jakakolwiek narracja, ponieważ narracja zaprasza do ułożenia osi czasu wokół podejrzanego. Każdy wiersz powinien mówić, co ten zapis ustala, i osobno, czego sam nie może ustalić. W chwili, gdy dwa wiersze zlewają się w jedno zdanie, interpretacja już wygrała.
Zauważ, że ostatnie zdarzenie dotyczy wykrycia, a nie atakującego. Czas odkrycia i czas przejęcia zwykle dzieli kilka godzin lub tygodni, a raport, który je zrównuje, wprowadzi w błąd każdego czytelnika po tobie.
Zapisz, skąd pochodzi każdy znacznik czasu, a nie tylko, co mówi. Czas odbioru przez kolektor, czas zdarzenia i czas wykrycia to trzy różne liczby, a ciche znormalizowanie ich do jednej kolumny to sposób, w jaki oś czasu zyskuje kształt, którego dowody nigdy nie miały.
Łącz zapisy tylko tam, gdzie identyfikatory się zgadzają
Łączenie zapisów to hipoteza, a nie krok formatowania. Nazwa konta, przypisany adres VPN, host docelowy i identyfikator sesji muszą się zgadzać, zanim dwa wiersze staną się jedną historią. Wspólny publiczny adres nie wystarcza, bo jest wspólny z założenia.
| Record source | Join key that must match | What breaks when the key is missing |
|---|---|---|
| File-share or backup record | file path and modification time | impact cannot be ordered against any session |
| Host process record, EDR or audit log | host name and process start time | the process cannot be placed inside a session |
| Session broker or remote-desktop log | session identifier and target host | the session cannot be traced back to a gateway login |
| Gateway authentication log | account name and assigned VPN address | the session cannot be followed past the gateway |
Czytaj tabelę od dołu do góry, gdy śledzisz wejście, i od góry do dołu, gdy określasz zakres wpływu, bo oba pytania wymagają przeciwnych kierunków. Tam, gdzie identyfikatory naprawdę się zgadzają, powiedz to i wskaż oba zapisy. Tam, gdzie się nie zgadzają, pozostaw lukę widoczną, zamiast zamykać ją założeniem.
Tu również myli znana nazwa użytkownika. To samo konto może rano używać prawowity właściciel, a nocą ktoś inny, i sama nazwa konta nie potrafi ich rozróżnić. Przypisz konto, potem osobno przypisz osobę, i tylko wtedy, gdy coś to popiera. Większość osi czasu, które rozpadają się w przeglądzie, wykonała dokładnie ten krok zbyt szybko.
Brakujące logi to luka, a nie dowód negatywny
Brak zdarzeń z nieudanym hasłem nie dowodzi, że udane logowanie było legalne. Ważne skradzione dane logowania dają udany zapis uwierzytelnienia i zupełnie żadnych niepowodzeń, i właśnie to czyni kradzież danych logowania atrakcyjną.
Podobnie port zamknięty dziś mówi coś o dniu dzisiejszym. Nie mówi nic o tym, czy ta usługa była wtedy ujawniona, czy była wtedy podatna, ani czy niosła atak. Historyczna konfiguracja i dowody z usługi to jedyny sposób, by tę lukę zamknąć.
Wskaż lukę wprost w raporcie. „Nie mamy logów z tego przedziału” to zdanie do obrony; „nic innego się nie stało” nie jest, i zostanie ci to zacytowane. Luki mają też właścicieli: nazwij system, który powinien był wytworzyć zapis, i dlaczego tego nie zrobił. Ten wiersz zamienia pominięcie w punkt naprawczy.
Pisz ustalenia na poziomie, który potwierdzają dowody
Koordynuj zabezpieczenie, izolację i odtworzenie przez właściciela incydentu, a nie obok niego. Wytyczne techniczne CISA podkreślają zbieranie odpowiednich artefaktów i logów, zanim naprawa zmieni to, co pozostaje dostępne, i ta kolejność jest ważniejsza niż jakiekolwiek pojedyncze narzędzie.
Ponowne uruchomienie domniemanego exploita na działającym sprzęcie, by zamknąć lukę, nie jest warte dodawanego ryzyka. Test pokazujący, że atak mógł zadziałać, nie jest dowodem, że zadziałał, a różnica między tymi dwoma zdaniami to cała dyscyplina ćwiczenia.
Zakończ czterema listami: co zaobserwowano, jakie relacje potwierdzają zapisy, co pozostaje hipotezą i których zapisów brakuje. „Podczas incydentu użyto konta VPN” należy do drugiej listy, gdy zapisy to potwierdzają. „VPN spowodował ransomware” nie należy nigdzie, dopóki coś nie ustali związku przyczynowego.