Większość poradników o bezpieczeństwie kont zaczyna się od założenia, że wiesz kiedy zostałeś zaatakowany. Dostajesz powiadomienie o logowaniu z nieznanego urządzenia. Widzisz wiadomości, których nie wysyłałeś. Nie możesz zalogować się na własne konto. Sygnał jest głośny i oczywisty — pytanie brzmi tylko co teraz.
Ale istnieje osobna klasa incydentów, w których tego sygnału po prostu nie ma.
Incydent z 9 i 10 kwietnia, gdy strona cpuid.com przez niecałe dziewiętnaście godzin serwowała złośliwe wersje popularnych narzędzi diagnostycznych CPU-Z i HWMonitor, jest tego przykładem. Aplikacja działała normalnie. Podpisy cyfrowe plików wykonywalnych były prawidłowe. Złośliwy kod uruchamiał się w pamięci, bez zapisywania plików pośrednich na dysku. Głównym celem była jedna rzecz: dane uwierzytelniające przechowywane w przeglądarkach — hasła, tokeny sesji, zapisane dane logowania.
Ofiara mogła o tym nie wiedzieć przez kilka dni. Do momentu, gdy ktoś zaczął logować się na jej konta.
Problem z "pierwszymi minutami"
Kiedy już wiesz, że coś się stało — czy to alert o podejrzanym logowaniu, czy niemożność zalogowania się na własne konto, czy telefon od znajomego pytającego o dziwne wiadomości od ciebie — zegar jest nastawiony. Każda minuta ma znaczenie.
Ale jeśli infekcja była cicha, ten zegar nastawia się bez twojej wiedzy. Dane już trafiły do atakującego. Atakujący czeka — może kilka godzin, może kilka dni — zanim z nich skorzysta. I właśnie wtedy, gdy postanowi zadziałać, nagle dostajesz ten alert.
Problem polega na tym, że w tym momencie nie działasz z pełną informacją. Nie wiesz co dokładnie zostało skradzione. Nie wiesz od jak dawna atakujący ma dostęp. Nie wiesz ile kont jest zagrożonych, bo złośliwy kod zbierał wszystkie zapisane w przeglądarce dane — nie tylko jedno konkretne hasło.
To zmienia schemat reakcji. Nie chodzi już o jedno zhakowane konto. Chodzi o potencjalnie wszystkie konta, do których hasło było zapisane w przeglądarce na zainfekowanej maszynie.
Co się dzieje po cichu, zanim odkryjesz
Żeby zrozumieć dlaczego reakcja musi być szersza niż zmiana jednego hasła, warto zobaczyć co faktycznie zbiera złośliwy kod tego rodzaju.
Zapisane hasła to tylko część. Ważniejsze są często tokeny sesji — dane, które pozwalają pozostać zalogowanym bez wpisywania hasła. Jeśli atakujący ma token aktywnej sesji, może być zalogowany na twoje konto nawet po tym jak zmienisz hasło. Token obowiązuje dalej, dopóki ktoś go nie unieważni przez wylogowanie wszystkich aktywnych sesji.
Drugi nieoczywisty cel to dane odzyskiwania kont — pomocniczy adres e-mail i numer telefonu w ustawieniach bezpieczeństwa. Jeśli atakujący zdąży je zmienić na swoje, odzyska dostęp natychmiast po tym jak ty zmienisz hasło. Zmiana hasła bez sprawdzenia danych odzyskiwania to nieszczelna reakcja.
Trzeci: reguły przekazywania poczty. Po przejęciu skrzynki e-mail to jeden z pierwszych kroków atakującego — ustawienie cichego kopiowania całej przychodzącej korespondencji na inny adres. Możesz odzyskać pełną kontrolę nad kontem, a atakujący i tak będzie nadal czytał twoje wiadomości.
Schemat działania gdy już wiesz
ESET przygotował poradnik opisujący dokładnie ten schemat — od pierwszej diagnozy przez zabezpieczenie dostępu, weryfikację innych kont, sprzątanie po ataku, aż po powiadamianie bliskich i zgłaszanie incydentu: Zhakowane konto? Kluczowe pierwsze minuty po ataku.
Warto go przeczytać zanim coś się stanie, nie dopiero gdy już się stało. Nie dlatego że jest skomplikowany — właśnie dlatego że jest prosty i konkretny, a w chwili gdy naprawdę dostajesz alert o podejrzanym logowaniu, twoja zdolność do spokojnego myślenia jest znacznie mniejsza niż teraz.
Kilka elementów z tego schematu, które warto zapamiętać jako pierwsza reakcja niezależnie od okoliczności:
Wyloguj wszystkie aktywne sesje — nie tylko zmień hasło. W ustawieniach bezpieczeństwa każdego serwisu znajdziesz opcję zakończenia wszystkich sesji na wszystkich urządzeniach. To unieważnia tokeny, które mógł mieć atakujący.
Sprawdź dane odzyskiwania konta przed jakimkolwiek innym krokiem. Pomocniczy adres e-mail i numer telefonu w ustawieniach bezpieczeństwa — jeśli są tam dane, których nie rozpoznajesz, to jest pierwszy priorytet.
Sprawdź reguły przekazywania w skrzynce e-mail. Szczególnie jeśli konto e-mail mogło być skompromitowane — skrzynka to klucz do resetu hasła w każdym innym serwisie.
Traktuj wszystkie hasła z przeglądarki na zainfekowanej maszynie jako ujawnione. Nie tylko konto, na którym zauważyłeś problem. Wszystkie.
Cisza jako sygnał
Jest jeszcze jeden wniosek z incydentu CPUID, który wychodzi poza sam przypadek złośliwego oprogramowania.
Jeśli przez kilka dni po 9-10 kwietnia pobierałeś oprogramowanie z cpuid.com i nic się nie stało — nie masz żadnego alertu, konta działają normalnie, komputer chodzi jak zawsze — to nie jest dowód że jesteś bezpieczny. To jest brak dowodu w obie strony. Złośliwy kod tego rodzaju jest zaprojektowany żeby nie dawać sygnałów. Cisza jest wbudowana w mechanizm działania.
W takiej sytuacji jedynym rozsądnym krokiem jest proaktywna weryfikacja: sprawdzenie historii logowań na ważnych kontach, rotacja haseł do najważniejszych usług i weryfikacja danych odzyskiwania. Nie dlatego że wiesz że coś się stało. Dlatego że nie wiesz że się nie stało.
To jest też szersza zasada, którą incydent CPUID dobrze ilustruje: brak alertu nie jest potwierdzeniem bezpieczeństwa. Jest tylko brakiem alertu.
