Trezor: 347 149 adresów wyeksportowanych po incydencie Brevo

To ryzyko nie jest teoretyczne. W pierwszej fazie incydentu konto newsletterowe Trezor zostało wykorzystane do rozesłania fałszywego alarmu bezpieczeństwa. Wiadomość prowadziła do aplikacji, która próbowała nakłonić użytkownika do wpisania kopii zapasowej portfela. Trezor podał, że domenę związaną z atakiem wyłączono w ciągu około 20 minut, a wcześniej odsyłacz otworzyło około 2,5 tys. osób.

Dla organizacji to przykład dwóch następujących po sobie problemów: przejęty kanał komunikacji może posłużyć do pierwszej kampanii, a wyeksportowana lista odbiorców może później zwiększyć precyzję kolejnych prób podszywania się.

Co Trezor potwierdził 17 września

Trezor, producent sprzętowych portfeli do kryptowalut, opublikował komunikat o incydencie 10 września i później go zaktualizował. W aktualizacji z 17 września firma podała dokładną liczbę: 347 149 kontaktów marketingowych zostało wyeksportowanych z listy Trezor przez API.

Trezor zaznacza, że Brevo nie przechowywało w tej bazie haseł, danych portfeli ani innych danych osobowych poza informacjami związanymi z newsletterem opisanymi przez firmę. Nie ma podstaw, aby z samego eksportu listy wyciągać wniosek o przejęciu portfeli lub systemów Trezor.

Znaczenie ma jednak kontekst adresów. To nie jest przypadkowy zbiór skrzynek pocztowych: napastnik może wiedzieć, że należą do osób zapisanych na komunikację Trezor. Firma ostrzega, że adresy mogą zostać wykorzystane w kolejnych, bardziej ukierunkowanych próbach phishingu.

Pierwsza wiadomość przyszła przez prawdziwy kanał newslettera

9 września napastnik wykorzystał dostęp po stronie Brevo do wysłania wiadomości z konta newsletterowego Trezor. Temat fałszywego alarmu dotyczył rzekomej podatności mikrokontrolera STM32. Odsyłacz prowadził do pobrania aplikacji, która prosiła użytkownika o wpisanie kopii zapasowej portfela.

Według Trezor wiadomość wysłano do około 347 tys. odbiorców. Firma podała, że domenę używaną w kampanii wyłączyła na poziomie DNS w ciągu około 20 minut. Do tego czasu odsyłacz otworzyło około 2,5 tys. osób.

To ważne rozróżnienie: liczba kliknięć nie oznacza liczby osób, które podały kopię zapasową portfela, ani liczby utraconych środków. Trezor informuje, że samo otwarcie odsyłacza nie wystarczało do przejęcia środków; krytycznym krokiem było przekazanie kopii zapasowej portfela.

Eksport listy zmienia ryzyko po zakończeniu pierwszej kampanii

Wyłączenie domeny i zatrzymanie pierwszej wiadomości nie unieważnia informacji, które zostały wcześniej wyeksportowane. Jeżeli napastnik zachował listę adresów, może przygotować kolejną wiadomość poza infrastrukturą Brevo.

Nowa próba nie musi kopiować pierwszego scenariusza. Może odwoływać się do samego incydentu, rzekomej konieczności ponownej weryfikacji urządzenia, zwrotu środków, aktualizacji bezpieczeństwa albo pomocy technicznej. Te przykłady są scenariuszami ryzyka, a nie informacją, że Trezor zaobserwował wszystkie takie warianty.

Dla odbiorcy najważniejszy pozostaje punkt decyzji: wiadomość może znać właściwą markę i trafić do właściwej grupy, ale nie daje to nadawcy prawa do żądania sekretu, który powinien pozostać wyłącznie po stronie użytkownika.

Jak odróżnić potwierdzone fakty od możliwego kolejnego ataku

Potwierdzone są trzy elementy. Po pierwsze, konto newsletterowe Trezor zostało wykorzystane do wysyłki phishingu. Po drugie, Trezor podał eksport 347 149 kontaktów marketingowych. Po trzecie, firma ostrzegła, że te adresy mogą zostać ponownie użyte do bardziej ukierunkowanych wiadomości phishingowych.

Nie jest natomiast potwierdzone, że każdy wyeksportowany adres otrzyma kolejną wiadomość ani że istnieje jedna konkretna druga kampania wykorzystująca cały zbiór. W security awareness warto zachować tę granicę, ponieważ alarmistyczne rozszerzanie faktów utrudnia później ocenę rzeczywistych sygnałów zagrożenia.

Co powinien zrobić odbiorca kolejnej wiadomości

Trezor przypomina, że nie prosi użytkowników o przekazanie kopii zapasowej portfela. Jeżeli wiadomość prowadzi do formularza, aplikacji lub instrukcji wymagającej podania takiego sekretu, należy przerwać działanie.

Warto również wejść do usługi niezależną drogą zamiast korzystać z odsyłacza w wiadomości. Informację o incydencie można sprawdzić w oficjalnym serwisie lub aplikacji uruchomionej samodzielnie. Podejrzaną wiadomość należy zgłosić zgodnie z procedurą organizacji, jeśli dotyczy skrzynki służbowej.

W środowisku firmowym podobna zasada dotyczy nie tylko portfeli kryptowalutowych. Wiadomość, która zna właściwego dostawcę, projekt albo usługę, nadal powinna być oceniana przez pryzmat czynności, do której nakłania: podania hasła, kodu, zatwierdzenia logowania, uruchomienia pliku lub zmiany danych płatniczych.

Co organizacja powinna sprawdzić u dostawcy komunikacji

Incydent pokazuje, że platforma mailingowa jest częścią łańcucha zaufania. Jeżeli dostawca może wysyłać wiadomości w imieniu organizacji i przechowuje listy kontaktów, jego naruszenie może jednocześnie wpłynąć na wiarygodność kanału i na dane potrzebne do późniejszego profilowania odbiorców.

Po takim zdarzeniu warto ustalić co najmniej: jaki zakres kontaktów był dostępny, czy doszło do eksportu, jakie konta i klucze miały dostęp do list, czy można odtworzyć operacje z dzienników oraz jak szybko można odciąć wysyłkę i unieważnić dane dostępowe.

W szkoleniach pracowników warto też uwzględniać sytuację, w której wiadomość przychodzi przez wcześniej zaufany kanał. Sama zgodność nazwy nadawcy, wyglądu i kontekstu biznesowego nie powinna zastępować oceny żądanej czynności.

To odrębny incydent od ClickFix w Brevo

PHISHLY opisał już incydent Brevo z ClickFix, w którym przejęty klucz Cloudflare pozwolił 14 września zmieniać treść dostarczaną przez wybrane strony, widgety i skrypty. Tam problemem była warstwa dostarczania treści WWW.

Obecny materiał dotyczy wcześniejszego zdarzenia z 9–10 września: dostępu do kont Brevo, wykorzystania kanału newsletterowego Trezor oraz później potwierdzonego eksportu kontaktów. Łączy je dostawca, ale mechanizm, czas i pytanie czytelnika są inne.

To rozdzielenie ma znaczenie także operacyjnie. Organizacja może mieć u jednego dostawcy kilka niezależnych powierzchni ryzyka: uwierzytelnianie do panelu, wysyłkę wiadomości, API, przechowywanie kontaktów oraz komponenty osadzane na stronach.

Jak ćwiczyć taki scenariusz w security awareness

Dobre ćwiczenie nie powinno sprowadzać się do rozpoznania literówki lub dziwnej domeny. W tym przypadku pierwsza wiadomość została wysłana przez przejęty, legalny kanał. Kolejna może z kolei korzystać z wiedzy, że odbiorca jest związany z konkretną usługą.

Symulacja może więc sprawdzać, czy pracownik zatrzymuje się przy żądaniu wrażliwej czynności, niezależnie od tego, jak wiarygodny jest kontekst. Następny element to weryfikacja niezależnym kanałem i szybkie zgłoszenie.

PHISHLY pozwala ćwiczyć takie punkty decyzyjne w testach phishingowych dla firm. W szerszym programie security awareness warto łączyć symulacje z prostą zasadą: znajomość kontekstu przez nadawcę zwiększa wiarygodność wiadomości, ale nie zmienia reguł dotyczących sekretów, uwierzytelniania i nietypowych żądań.

Co wynika z incydentu Trezor i Brevo

Po zatrzymaniu pierwszej kampanii pozostaje drugie ryzyko: lista odbiorców może nadal istnieć poza kontrolą organizacji. Trezor wprost wiąże eksport 347 149 kontaktów z możliwością kolejnych, bardziej ukierunkowanych prób phishingu.

Dla użytkownika oznacza to konieczność oceny żądanej czynności, a nie tylko wyglądu wiadomości. Dla organizacji — potrzebę traktowania systemów komunikacji marketingowej jako elementu bezpieczeństwa dostawców, z kontrolą dostępu, eksportu danych, dzienników i planem szybkiego odcięcia kanału.

Incydent pokazuje też, dlaczego po naruszeniu nie wystarcza komunikat „kampania została zatrzymana”. Trzeba osobno ustalić, jakie dane opuściły system i jakie scenariusze mogą być wiarygodne dla odbiorców w kolejnych tygodniach.