Kompromitacja infrastruktury chmurowej Brevo pokazała, jak pojedyncze skradzione poświadczenie API może zamienić zaufaną usługę podmiotu trzeciego w platformę ataku na łańcuch dostaw na dużą skalę.
14 września 2026 roku atakujący użyli skompromitowanego klucza API Cloudflare należącego do Brevo, aby wdrożyć złośliwy Cloudflare Worker. Worker zmieniał treści dostarczane przez infrastrukturę Brevo i wstrzykiwał złośliwy JavaScript do witryn korzystających z osadzonych usług Brevo.
Badacze bezpieczeństwa z Sansec szacują, że dotkniętych mogło zostać ponad 100 000 witryn.
Incydent ma szczególne znaczenie, ponieważ odwiedzający nie musieli bezpośrednio wchodzić w interakcję z Brevo. Zaufana przez nich witryna mogła załadować skompromitowany skrypt Brevo i stać się mechanizmem dostarczania ataku.
Co się stało?
Dochodzenie Brevo wykazało, że atakujący zdobył długotrwały klucz API Cloudflare z pełnymi uprawnieniami do konta.
Klucz był przechowywany w kodzie źródłowym aplikacji. Według Brevo atakujący mógł go użyć do tworzenia Cloudflare Workers, tras i rekordów DNS bez wywoływania alertu.
14 września atakujący wdrożył złośliwy Worker.
Zamiast modyfikować oryginalne pliki witryny Brevo, Worker zmieniał odpowiedzi HTTP na krawędzi Cloudflare (edge), co oznacza, że złośliwe treści mogły być wstawiane w trakcie dostarczania ruchu do odwiedzających.
Brevo podaje, że złośliwy Worker był aktywny przez około pięć i pół godziny, od 15:01 do 20:30 UTC, a modyfikowanie dotkniętych osadzonych zasobów JavaScript rozpoczęło się około 16:07 UTC.
To rozróżnienie jest ważne: systemy źródłowe (origin) i pliki źródłowe firmy niekoniecznie zostały zmienione. Złośliwe treści wstawiano w trakcie dostarczania.
Jak działał atak na łańcuch dostaw?
Atak opierał się na oprogramowaniu, któremu tysiące witryn już wcześniej postanowiły zaufać.
Brevo oferuje usługi, takie jak formularze, śledzenie i funkcje rozmów z klientami, za pośrednictwem komponentów JavaScript osadzonych w witrynach klientów.
Skompromitowany Worker zmodyfikował kilka z tych zasobów.
Badacze zaobserwowali dodanie złośliwego kodu do loadera SDK i komponentów Conversations Brevo, które są ładowane przez witryny klientów. Sansec zgłosił dowody na to, że wstrzyknięte skrypty były serwowane przez domeny kontrolowane przez Brevo i osadzone zasoby.
Stworzyło to klasyczny scenariusz ataku na łańcuch dostaw:
Infrastruktura Brevo → zaufany komponent JavaScript → witryna klienta → odwiedzający witrynę
Atakujący nie musiał kompromitować każdej witryny z osobna.
Kompromitacja współdzielonej usługi stworzyła potencjalną drogę do wielu witryn jednocześnie.
Atak ClickFix
Złośliwy JavaScript nie był zwykłym pobraniem złośliwego oprogramowania.
Zamiast tego wybranym odwiedzającym wyświetlano przekonującą fałszywą stronę Cloudflare „potwierdź, że jesteś człowiekiem”.
Strona instruowała użytkowników, aby:
- Nacisnęli Win + R
- Nacisnęli Ctrl + V
- Nacisnęli Enter
Schowek zawierał polecenie przygotowane przez złośliwy skrypt.
Jego uruchomienie mogło pobrać i wykonać złośliwe oprogramowanie na komputerze odwiedzającego z systemem Windows.
To technika socjotechniczna ClickFix, w której ofiary są namawiane do samodzielnego wykonania poleceń pod pretekstem przejścia weryfikacji bezpieczeństwa lub naprawy problemu z przeglądarką.
Brevo potwierdziło to zachowanie w dochodzeniu po incydencie.
Atak był również selektywny. Brevo podaje, że złośliwa strona była wyświetlana tylko wybranym odwiedzającym, co oznacza, że wiele osób odwiedzających dotkniętą stronę mogło nie zobaczyć fałszywego ekranu weryfikacji.
Witryny WordPress były narażone na dodatkowe ryzyko
Atak miał jeszcze jeden element, wymierzony w administratorów WordPressa.
Według Brevo, jeśli odwiedzający był zalogowany do witryny WordPress jako administrator, a witryna ładowała dotknięty widżet Brevo, wstrzyknięty kod próbował po cichu zainstalować i aktywować złośliwą wtyczkę WordPress.
Niezależna analiza BleepingComputer wykazała, że złośliwa wtyczka podawała się za wiarygodnie brzmiącą wtyczkę o nazwie „Web Media Optimizer”, ale działała jako trwały backdoor.
Znacząco zwiększa to potencjalny wpływ na witryny, których administratorzy odwiedzali własne strony w okresie ataku.
Dlaczego ponad 100 000 witryn?
Podana liczba nie oznacza, że 100 000 witryn zostało indywidualnie zhakowanych na swoich serwerach źródłowych.
Badacze stwierdzili natomiast, że skompromitowane skrypty Brevo były osadzone w bardzo dużej liczbie witryn.
Sansec oszacował, że ponad 100 000 witryn klientów było potencjalnie narażonych na złośliwy mechanizm dostarczania.
To jedna z cech charakterystycznych ataku na łańcuch dostaw.
Firma może mieć silne zabezpieczenia własnej witryny, a mimo to zależeć od dziesiątek lub setek zewnętrznych bibliotek JavaScript, platform SaaS, usług analitycznych i widżetów.
Jeśli zostanie skompromitowany jeden zaufany dostawca, jego klienci mogą odziedziczyć atak.
API Brevo i dane klientów nie zostały w tym incydencie naruszone
Ważne jest odróżnienie incydentu w łańcuchu dostaw od typowego wycieku danych klientów.
Brevo podaje, że:
- app.brevo.com nie został dotknięty
- API Brevo nie zostało dotknięte
- Wysyłanie e-maili nie zostało dotknięte
- Dane kont klientów przechowywane przez Brevo nie zostały dotknięte
- Złośliwe treści wstawiono na krawędzi CDN, a nie w systemach źródłowych Brevo
Oznacza to, że głównym ryzykiem incydentu z 14 września było dostarczanie złośliwych treści, a nie pobranie przez atakujących całej bazy klientów Brevo.
Wcześniej wystąpił odrębny incydent bezpieczeństwa Brevo
Warto zwrócić uwagę na dodatkowy kontekst.
10 września, cztery dni przed incydentem z Cloudflare Worker, Brevo ujawniło odrębny problem bezpieczeństwa dotyczący SAML SSO.
Brevo poinformowało, że atakujący wykorzystał błąd w implementacji SSO i uzyskał dostęp do 138 kont Brevo. Sześć kont użyto do wysyłania e-maili phishingowych, a dane kontaktów wyeksportowano z 43 kont. Brevo podało, że zamknęło ścieżkę dostępu i wylogowało użytkowników z platformy.
Incydent z Cloudflare z 14 września dotyczył innego mechanizmu dostępu: skompromitowanego klucza API Cloudflare.
Obu incydentów nie należy więc przedstawiać jako jednego technicznego exploita, choć wystąpiły w tym samym tygodniu i oba wpłynęły na poziom bezpieczeństwa Brevo.
Dlaczego klucz API miał tak duże znaczenie
Incydent podkreśla częsty problem bezpieczeństwa chmury: klucz API może być równie potężny jak hasło — a czasem znacznie bardziej niebezpieczny.
Skompromitowane poświadczenie miało podobno pełne uprawnienia do konta Cloudflare.
Pozwoliło to atakującemu:
- Tworzyć Cloudflare Workers
- Modyfikować routing
- Tworzyć rekordy DNS
- Kontrolować sposób dostarczania treści z domen Brevo
Poświadczenie było też długotrwałe i przechowywane w kodzie źródłowym.
Ta kombinacja stworzyła szczególnie niebezpieczną sytuację:
Długotrwałe poświadczenie + nadmierne uprawnienia + ujawnienie w kodzie źródłowym + niewystarczające monitorowanie = przejęcie infrastruktury
Dlaczego tradycyjne monitorowanie integralności mogło przeoczyć atak
Jednym z najciekawszych technicznych aspektów incydentu jest to, że atak działał na krawędzi (edge).
Brevo podaje, że złośliwy Worker przepisywał odpowiedzi, zanim dotarły do użytkowników, i usuwał nagłówki bezpieczeństwa, takie jak Content-Security-Policy.
Ponieważ oryginalne pliki na serwerach Brevo nie zostały zmodyfikowane, konwencjonalne monitorowanie integralności plików mogło nie wiedzieć o wstrzykniętych treściach.
To ważna lekcja dla nowoczesnych środowisk chmurowych.
Sprawdzanie, czy pliki na serwerze źródłowym uległy zmianie, niekoniecznie jest już wystarczające.
Firmy potrzebują też wglądu w:
- konfigurację CDN
- funkcje edge
- Cloudflare Workers
- zmiany DNS
- reguły routingu
- poświadczenia API
- JavaScript podmiotów trzecich
- zachowanie w czasie działania w przeglądarkach
Co zrobiło Brevo
Brevo podaje, że:
- Usunęło złośliwy Worker i trasy
- Usunęło utworzone przez atakującego nazwy hostów
- Unieważniło skompromitowany klucz API i poświadczenia utworzone za jego pomocą
- Wyczyściło pamięci podręczne edge
- Usunęło zaszyte na stałe poświadczenie z kodu źródłowego
- Zastąpiło je tokenami o wąskim zakresie i krótkim czasie życia
- Przejrzało poświadczenia konta Cloudflare i jego członków
- Dodało monitorowanie zdarzeń audytu Cloudflare
- Rozpoczęło przesyłanie logów Cloudflare do swojej platformy monitorowania bezpieczeństwa
- Rozpoczęło przegląd konfiguracji edge podmiotów trzecich
Brevo podaje też, że przyjmuje HashiCorp Vault jako centralne miejsce przechowywania kluczy i tokenów Cloudflare, z automatyczną rotacją.
Co powinni zrobić właściciele witryn
Firmy korzystające z osadzonych skryptów Brevo powinny traktować incydent jako potencjalne narażenie w łańcuchu dostaw.
✅ Przejrzyj aktywność administratorów WordPressa
Jeśli administrator WordPressa odwiedził witrynę 14 września, sprawdź, czy tego dnia nie zainstalowano lub nie aktywowano nieoczekiwanych wtyczek.
Brevo szczególnie zaleca przejrzenie instalacji WordPressa pod kątem takiej aktywności.
✅ Wyszukaj nieautoryzowane zmiany
Przejrzyj:
- Nowe wtyczki WordPressa
- Nowe konta administratorów
- Zmodyfikowane pliki PHP
- Zaplanowane zadania
- Nieznany JavaScript
- Nieoczekiwane przekierowania
- Zmiany w
.htaccess - Ostatnio zmodyfikowane pliki witryny
✅ Zmień ważne poświadczenia
Jeśli witryna mogła zostać skompromitowana, zmień:
- Hasła administratorów WordPressa
- Poświadczenia hostingu
- Poświadczenia SSH
- Hasła do baz danych
- Klucze API
- Poświadczenia chmurowe
- Inne sekrety dostępne z dotkniętej witryny
✅ Sprawdź odwiedzających, którzy mogli wykonać polecenia ClickFix
Jeśli pracownikowi lub klientowi wyświetlono fałszywą weryfikację Cloudflare i faktycznie wykonał on żądane polecenie, ten punkt końcowy należy traktować jako potencjalnie skompromitowany.
Brevo zaleca odłączenie komputera, wykonanie pełnego skanowania antywirusowego i zmianę haseł używanych na tej maszynie.
✅ Przejrzyj JavaScript podmiotów trzecich
Ten incydent przypomina o konieczności prowadzenia inwentarza zewnętrznych skryptów ładowanych przez witryny firmy.
Dla każdego komponentu podmiotu trzeciego firmy powinny wiedzieć:
- Kto go obsługuje
- Do jakich danych ma dostęp
- Skąd jest ładowany
- Jakie ma uprawnienia
- Jak szybko można go wyłączyć
- W jaki sposób monitorowane są zmiany w nim
Szersza lekcja dla cyberbezpieczeństwa
Incydent Brevo pokazuje, dlaczego bezpieczeństwo łańcucha dostaw oprogramowania nie ogranicza się już do bibliotek i repozytoriów pakietów.
Platformy chmurowe, dostawcy SaaS, konfiguracje CDN, osadzony JavaScript i widżety podmiotów trzecich mogą stać się częścią zaufanej ścieżki wykonania aplikacji.
Witryna może być w pełni załatana i nie mieć skompromitowanych plików, a mimo to dostarczać złośliwe oprogramowanie, ponieważ zaufany zewnętrzny skrypt został zmieniony.
Sprawia to, że zależności od podmiotów trzecich stają się granicą bezpieczeństwa.
Atak pokazuje też niebezpieczeństwo łączenia potężnych poświadczeń chmurowych z długim okresem ważności i szerokimi uprawnieniami. Pojedynczy klucz API wystarczył, by dać atakującym kontrolę nad warstwą dostarczania dużej usługi.
Podsumowanie
Incydent Brevo był szczególnie skuteczny, ponieważ wykorzystał zaufanie.
Odwiedzający ufali witrynom, które odwiedzali. Właściciele witryn ufali JavaScriptowi Brevo. Infrastruktura Brevo ufała potężnemu poświadczeniu API.
Atakujący ostatecznie próbowali zamienić ten łańcuch zaufania w sieć dystrybucji złośliwego oprogramowania.
Każdy skrypt podmiotu trzeciego, integracja SaaS i poświadczenie API chmury są częścią granicy bezpieczeństwa. Firmy potrzebują krótkotrwałych poświadczeń o najmniejszych uprawnieniach, silnego monitorowania zmian w chmurze i jasnego inwentarza każdego zewnętrznego komponentu, od którego zależą ich witryny.
