Wprowadzenie do problemu / definicja
Atak na łańcuch dostaw to incydent, w którym cyberprzestępcy kompromitują dostawcę usług, oprogramowania lub komponentów osadzanych na wielu stronach, aby pośrednio dotrzeć do szerokiej grupy ofiar. W przypadku Brevo celem była infrastruktura odpowiedzialna za dostarczanie treści i skryptów JavaScript, co umożliwiło wstrzyknięcie złośliwego kodu zarówno do własnych serwisów firmy, jak i do widgetów wykorzystywanych przez klientów.
Skutek takiego scenariusza jest szczególnie groźny, ponieważ zaufane elementy marketingowe i komunikacyjne mogą nagle stać się nośnikiem złośliwych technik socjotechnicznych oraz potencjalnego malware. Dla organizacji korzystających z zewnętrznych skryptów oznacza to ryzyko, które nie wynika z błędu we własnym kodzie, lecz z kompromitacji partnera technologicznego.
W skrócie
Brevo potwierdziło, że atakujący uzyskali dostęp do klucza API Cloudflare o bardzo szerokich uprawnieniach. Posłużył on do wdrożenia złośliwego Workera, który modyfikował odpowiedzi HTTP na brzegu sieci CDN i wstrzykiwał szkodliwy kod do stron oraz osadzanych komponentów.
Incydent miał miejsce 14 września 2026 roku i trwał kilka godzin. Według badaczy skutki mogły objąć ponad 100 tysięcy witryn korzystających z podatnych komponentów, a użytkownikom prezentowano fałszywe ekrany weryfikacyjne charakterystyczne dla techniki ClickFix. W części przypadków atak próbował także instalować złośliwą wtyczkę na stronach WordPress odwiedzanych przez zalogowanych administratorów.
- Kompromitacja objęła skrypty i widgety Brevo osadzane na stronach klientów.
- Napastnicy wykorzystali przejęty klucz API Cloudflare.
- Atak bazował na technice ClickFix i modyfikacji odpowiedzi na warstwie edge.
- W bardziej zaawansowanym wariancie zagrożone były również instalacje WordPress.
Kontekst / historia
Sprawa została nagłośniona po analizie badaczy bezpieczeństwa, którzy zauważyli nietypowe zachowanie skryptów dostarczanych przez Brevo. Firma potwierdziła następnie, że źródłem incydentu był przejęty klucz API Cloudflare, prawdopodobnie zapisany na stałe w kodzie aplikacji. Taki sekret dawał możliwość tworzenia Workerów, zarządzania routingiem oraz modyfikacji konfiguracji w wielu strefach.
Istotnym elementem tego ataku był fakt, że manipulacja odbywała się poza serwerami origin, na poziomie infrastruktury edge. Oznacza to, że klasyczne mechanizmy monitorowania integralności plików po stronie źródłowej mogły nie wykryć problemu, ponieważ podstawowe zasoby pozostawały niezmienione.
Z perspektywy zarządzania ryzykiem incydent wpisuje się w szerszy obraz podwyższonej ekspozycji organizacji. Kilka dni wcześniej Brevo informowało również o odrębnym incydencie związanym z SSO i przejęciami kont klientów. Nie ma publicznego potwierdzenia powiązania obu zdarzeń, ale zestawienie tych faktów wzmacnia ocenę, że firma znalazła się w okresie zwiększonej presji bezpieczeństwa.
Analiza techniczna
Technicznie atak polegał na wykorzystaniu skompromitowanego klucza API do wdrożenia złośliwego Cloudflare Workera. Komponent ten przechwytywał odpowiedzi HTTP i dynamicznie modyfikował treści dostarczane użytkownikom końcowym. Według dostępnych informacji usuwano również wybrane nagłówki bezpieczeństwa, co ułatwiało wykonanie wstrzykniętego kodu.
Kompromitacja objęła kilka kluczowych obszarów infrastruktury i usług:
- strony internetowe należące do Brevo,
- formularze osadzane na witrynach klientów,
- widgety rozmów i komunikacji,
- mechanizmy ładowania SDK używane w zewnętrznych serwisach.
To właśnie masowe dziedziczenie złośliwego zachowania przez klientów czyni ten incydent klasycznym przykładem kompromitacji łańcucha dostaw. Organizacje korzystające z oficjalnych skryptów Brevo mogły stać się nieświadomym nośnikiem ataku, mimo braku zmian w lokalnym kodzie czy błędów administracyjnych po swojej stronie.
Łańcuch infekcji wykorzystywał technikę ClickFix. Użytkownik odwiedzający zainfekowaną stronę mógł zobaczyć fałszywy ekran przypominający mechanizm weryfikacji bezpieczeństwa. Następnie był nakłaniany do ręcznego uruchomienia polecenia w systemie Windows. To podejście przenosi część działania na ofiarę, dzięki czemu atak może ominąć część tradycyjnych zabezpieczeń opartych wyłącznie na blokowaniu plików wykonywalnych.
W bardziej zaawansowanym wariancie skrypt analizował, czy odwiedzający stronę WordPress jest zalogowany jako administrator. Jeśli tak, podejmowana była próba wgrania złośliwej wtyczki. Taki komponent miał działać jak backdoor, ukrywać się z listy wtyczek, utrzymywać trwałość dzięki mechanizmom must-use plugins i pobierać dalszy kod z infrastruktury kontrolowanej przez napastników.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją incydentu jest podważenie zaufania do skryptów stron trzecich ładowanych bezpośrednio w przeglądarce użytkownika. Nawet organizacje stosujące poprawną higienę bezpieczeństwa mogły stać się kanałem dystrybucji złośliwego kodu wobec własnych klientów i partnerów.
Ryzyko można rozpatrywać na kilku poziomach:
- dla użytkowników końcowych oznaczało to możliwość nakłonienia do uruchomienia szkodliwego polecenia i infekcji stacji roboczej,
- dla właścicieli witryn pojawiło się ryzyko kompromitacji WordPressa przez ukrytą wtyczkę backdoor,
- dla zespołów bezpieczeństwa problemem były ograniczone możliwości detekcji, ponieważ pliki źródłowe mogły pozostać nienaruszone,
- dla biznesu skutkiem mogły być straty reputacyjne, zgłoszenia od klientów i konieczność pilnego przeglądu integracji.
Szczególnie niebezpieczny jest efekt skali. Nawet kilka godzin kompromitacji po stronie jednego dostawcy może przełożyć się na tysiące odsłon, interakcji i potencjalnych infekcji w wielu organizacjach jednocześnie. Tego rodzaju zdarzenia pokazują, że ryzyko związane z zależnościami front-endowymi jest często niedoszacowane.
Rekomendacje
Organizacje korzystające z komponentów Brevo powinny potraktować ten incydent jako sygnał do pełnego przeglądu zależności zewnętrznych i polityk bezpieczeństwa dla skryptów stron trzecich. Reakcja nie powinna ograniczać się wyłącznie do sprawdzenia kodu aplikacji, ale objąć również analizę zachowania zasobów ładowanych po stronie klienta.
- Zidentyfikować wszystkie strony i aplikacje korzystające z formularzy, widgetów i loaderów Brevo.
- Przeanalizować logi z 14 września 2026 roku pod kątem anomalii w odpowiedziach HTTP i zmian po stronie przeglądarki.
- Sprawdzić środowiska WordPress pod kątem nowych, ukrytych lub nietypowych wtyczek.
- Zweryfikować katalogi must-use plugins, harmonogramy zadań oraz niestandardowe pliki PHP.
- Wymusić rotację haseł administratorów, zwłaszcza jeśli byli zalogowani w czasie okna ekspozycji.
- Odświeżyć sekrety, tokeny i dane uwierzytelniające powiązane z panelami administracyjnymi.
- Wdrożyć monitoring integralności odpowiedzi renderowanych po stronie klienta, a nie tylko plików origin.
- Ograniczyć stosowanie długowiecznych kluczy API i usunąć sekrety zapisane na stałe w kodzie.
- Stosować zasadę najmniejszych uprawnień dla kont API oraz osobne zakresy dostępu dla operacji CDN, DNS i routingu.
- Wzmocnić polityki bezpieczeństwa dla skryptów zewnętrznych, w tym kontrolę ich zachowania i segmentację funkcji.
Z perspektywy SOC i DFIR warto także opracować reguły wykrywające nietypowe uploady wtyczek do WordPressa, nagłe zmiany w zależnościach JavaScript oraz wzorce charakterystyczne dla ClickFix, takie jak pełnoekranowe nakładki zachęcające do uruchomienia komendy.
Podsumowanie
Atak na Brevo stanowi ważny przykład nowoczesnej kompromitacji łańcucha dostaw, w której pojedynczy przejęty sekret infrastrukturalny umożliwił masowe wstrzyknięcie złośliwego kodu do zaufanych komponentów webowych. Szczególnie groźne było wykorzystanie mechanizmu modyfikacji odpowiedzi na warstwie edge, co znacząco utrudniało wykrycie incydentu tradycyjnymi metodami.
Dla obrońców płyną z tego trzy kluczowe wnioski: konieczność ścisłego zarządzania sekretami, rygorystyczne ograniczanie uprawnień API oraz pełna obserwowalność zachowania skryptów stron trzecich w przeglądarce. Organizacje korzystające z zewnętrznych widgetów i loaderów powinny uznać ten przypadek za praktyczne przypomnienie, że bezpieczeństwo aplikacji nie kończy się na własnym kodzie.
Źródła
- Brevo supply-chain attack injected ClickFix scripts on customer sites — https://www.bleepingcomputer.com/news/security/brevo-supply-chain-attack-injected-clickfix-scripts-on-customer-sites/
- Brevo supply chain attack hits 100k+ sites with WordPress backdoors and Clickfix malware — https://sansec.io/research/brevo-supply-chain-attack
- Brevo Status — https://status.brevo.com/history