Faktura, karta podarunkowa i 22 komplety haseł

Kontekst

Cofnijmy się do tego, po co Klient się do nas zgłosił. Chciał sprawdzić nie serwery, tylko ludzi, i postawił dwa pytania. Czy da się przekonać pracownika do wykonania przelewu na podstawie samego maila. I czy MFA naprawdę broni kont, czy tylko sprawia wrażenie, że broni.

Odpowiedź na oba brzmiała: da się to obejść. Jedno z tych pytań rozstrzygnęła osoba z księgowości, która odpisała nam, że płatność na podmieniony rachunek pójdzie jeszcze tego samego dnia.

Poczta stała na Microsoft 365, część kont miała włączone MFA, a dział bezpieczeństwa spodziewał się, że ta konfiguracja wystarczy. Nie wystarczyła.

Wyzwanie

Na papierze konfiguracja poczty wyglądała rozsądnie. SPF domykał listę serwerów twardym -all, DMARC działał w trybie kwarantanny, a wbudowana ochrona poczty skanowała załączniki z zapałem, który później zobaczyliśmy w logach.

$ dig +short TXT klient.example
"v=spf1 include:spf.protection.outlook.com -all"

$ dig +short MX klient.example
0 klient-example.mail.protection.outlook.com.

$ dig +short TXT _dmarc.klient.example
"v=DMARC1; p=quarantine; rua=mailto:dmarc@klient.example; fo=1"

$ dig +short TXT selector1._domainkey.klient.example
# pusto -> DKIM po stronie nadawcy niepodpisany

Jedna dziura była od razu widoczna. Domena nie podpisywała poczty DKIM, co w tym środowisku pocztowym jest kwestią jednego przełącznika i wpisu w DNS. Sama w sobie nie otwiera drzwi, ale osłabia to, na czym opiera się DMARC.

Realny problem był gdzie indziej. MFA. Klasyczny phishing na hasło rozbija się o drugi składnik, bo złodziej ma login i hasło, a przy logowaniu i tak wyskakuje kod albo push w aplikacji. Żeby przejść przez to naprawdę, trzeba przejąć nie hasło, tylko sesję. Do tego dochodziła poczta, która czyta wszystko za użytkownika, zanim ten w ogóle kliknie. To akurat zamieniliśmy w źródło danych, o czym za chwilę.

Co zrobiliśmy

Kampanię rozbiliśmy na dwa etapy o różnym profilu ryzyka. Precyzyjny spear phishing na trzy osoby z finansów i szeroki phishing na całą załogę. Mapowanie na MITRE ATT&CK poniżej, bo to język, w którym najłatwiej się dogadać z blue teamem.

Etap 1: spear phishing na finanse. Trzy adresy, trzy osoby zajmujące się płatnościami. Zarejestrowaliśmy domenę różniącą się od prawdziwej domeny kontrahenta jednym dopiskiem, postawiliśmy na niej konto nadawcze i odtworzyliśmy fakturę partnera. Typografia, układ, logotypy, waga pliku, metadane. Do tego stopka mailowa skopiowana co do piksela. Na fakturze, za zgodą Klienta, podmieniliśmy IBAN, żeby pokazać pełną ścieżkę oszustwa płatniczego, a nie samo kliknięcie.

Do każdej wiadomości doczepiliśmy drugi plik PDF z canary tokenem. To cyfrowa pułapka, która wysyła sygnał w momencie otwarcia dokumentu i mówi, kto, kiedy i z jakiego adresu go otworzył. I tu robi się ciekawie dla każdego, kto kiedyś patrzył na statystyki otwarć maili i brał je za dobrą monetę.

open  src=<chmura dostawcy poczty>  org="Microsoft Corporation"  geo=SE  -> bot (skan załącznika)
open  src=<chmura dostawcy poczty>  org="Microsoft Corporation"  geo=PL  -> bot
open  src=<krajowy operator>        org="operator lokalny"        geo=PL  -> realny użytkownik

Rozkład był wymowny. Na jednym z tokenów naliczyliśmy dziesięć otwarć automatycznych i tylko jedno otwarcie przez prawdziwego użytkownika. Na innym w ogóle zero użytkowników, same skanery. Wniosek dla analityka jest prosty. Jeśli budujesz alert na „plik został otwarty”, to w takim środowisku alarmować cię będzie głównie infrastruktura chmury, nie napastnik. Filtr po ASN i geolokalizacji zamienia szum w sygnał.

Najważniejsze zdarzenie nie miało nic wspólnego z technologią. Jedna z osób przekazała maila dalej, a z łańcucha wróciła odpowiedź od pracownika zamykającego proces: płacimy dziś. Żaden exploit. Wiarygodna faktura, presja terminu płatności i zaufanie do znanej marki wystarczyły, żeby uruchomić przelew.

Etap 2: phishing masowy i obejście MFA. Pretekst był prosty i chwytliwy. Karta podarunkowa od znanego dostawcy, rzekomo przyznana w ramach firmowego programu. Nikt nie zagląda w zęby darowanej karcie, więc scenariusz sam się sprzedawał.

Zamiast kraść hasła wcieliliśmy się w rolę Adversary in the Middle. Na VPS u dostawcy chmurowego wystawiliśmy reverse proxy przechwytujące sesję, domeny zaparkowaliśmy na Cloudflare. Ofiara widziała prawdziwy formularz logowania, bo to był prawdziwy formularz, tylko przepuszczony przez nas.

Klucz jest w tym, co dzieje się za kulisami. Użytkownik przechodził normalne MFA, zatwierdzał push w aplikacji, logował się i widział swoją skrzynkę. My w tym czasie przechwytywaliśmy z ruchu ciasteczko sesji. Token sesyjny to nie hasło. Działa po zmianie hasła i przechodzi obok drugiego składnika, bo uwierzytelnienie już się odbyło. Dostęp do jednego z kont potwierdziliśmy manualnie, wchodząc do skrzynki bez ponownego logowania.

Doszła jeszcze jedna sztuczka pod detekcję. Przed frontem phishingowym postawiliśmy firewall z filtrem geo, przepuszczający tylko ruch z Polski. Automaty antyphishingowe, które odwiedzają podejrzane linki z całego świata, natrafiły na ścianę i nie miały czego zgłosić do czarnej listy.

Dwie rzeczy zwróciły naszą uwagę w tej wysyłce. Otwarcia i kliknięcia szły niemal w parze, co jest podpisem botów, bo skaner wchodzi na link za jednym zamachem. I przez cały czas trwania kampanii nikt nie użył przycisku „zgłoś phishing”. To była dla nas mocniejsza informacja niż same przejęte konta.

Rezultat

Pozyskaliśmy 22 komplety danych logowania do środowiska Klienta, z czego dla większości mieliśmy też tokeny sesji, czyli dostęp odporny na reset hasła i na MFA w dotychczasowej postaci. Po stronie finansów jeden łańcuch mailowy doprowadził do deklaracji wykonania przelewu na podmieniony rachunek. Google Safe Browsing wychwyciło jedną z domen dopiero po dobie, a Klient zauważył kwarantannę drugiej dnia po starcie, więc okno działania i tak było szerokie.

Interakcja użytkownika była wymagana, ale poza tym próg wejścia okazał się niski, a przejęcie tożsamości pozwalało wyjść poza konto, od którego się zaczęło.

Rekomendacje ułożyliśmy tak, żeby dało się je odhaczyć, a nie tylko przeczytać:

• Przejść na MFA odporne na phishing, czyli FIDO2 lub passkeys. AiTM działa, bo kod i push da się przekazać dalej w czasie rzeczywistym, a klucza sprzętowego związanego z origin już nie.
• Zacisnąć Conditional Access. Wymóg zgodnego urządzenia albo zaufanej lokalizacji psuje scenariusz, w którym token wypływa na maszynę napastnika. Punkt odniesienia jest u Microsoftu w opisie obrony przed AiTM.
• Skrócić żywotność sesji i włączyć ciągłą ewaluację dostępu (CAE), żeby skradziony token nie żył tygodniami.
• Dołożyć DKIM po stronie nadawcy i regularnie czytać raporty RUA z DMARC. Skrzynka rua istnieje po to, żeby do niej zaglądać.
• Wprowadzić dwuosobową autoryzację płatności i twardą weryfikację zmiany numeru IBAN innym kanałem niż mail. To zatrzymuje BEC nawet wtedy, gdy faktura wygląda idealnie.
• Postawić przycisk „zgłoś phishing” tam, gdzie ludzie patrzą, i policzyć, ile razy został użyty. Brak zgłoszeń mimo licznych kliknięć to nie wina użytkowników, to brak łatwej drogi zgłoszenia.

Jedno zastrzeżenie na koniec, bo nie chcemy sprzedawać pewności, której nie mamy. Nie wiemy, ile z tych 22 kont dałoby się rozwinąć w pełny ruch boczny, bo zakres kończył się na potwierdzeniu dostępu. Zakładamy, że sporo, biorąc pod uwagę, że wśród przejętych sesji były konta z dostępem do współdzielonych skrzynek.

A gdyby u Ciebie ktoś dostał dziś maila z fakturą na drobną kwotę od stałego kontrahenta, z poprawną stopką i lekką presją terminu, to na jakim etapie wykryjesz ten atak? Na człowieku, na Conditional Access, czy na procedurze płatności? Jeśli nie masz pewnej odpowiedzi na wszystkie trzy, chętnie to sprawdzimy.