Wprowadzenie do problemu / definicja
Atak łańcucha dostaw to incydent, w którym przestępcy nie uderzają bezpośrednio w każdą ofiarę z osobna, lecz kompromitują zaufanego dostawcę usług, komponentów lub skryptów. W przypadku Brevo celem stała się infrastruktura wykorzystywana przez dużą liczbę witryn, co umożliwiło masową dystrybucję złośliwego kodu przez legalne zasoby osadzane na stronach klientów.
Taki model ataku jest szczególnie niebezpieczny, ponieważ wykorzystuje zaufanie do renomowanego dostawcy. W efekcie nawet poprawnie zabezpieczone strony mogą stać się kanałem infekcji, jeśli ładują zewnętrzne skrypty z naruszonego źródła.
W skrócie
Brevo padło ofiarą ataku supply chain, w którym napastnicy przejęli klucz API Cloudflare i użyli go do wdrożenia złośliwej logiki na warstwie edge. Dzięki temu mogli wstrzykiwać malware do odpowiedzi HTTP bez modyfikowania plików na serwerach źródłowych.
Skala incydentu mogła objąć ponad 100 tysięcy stron internetowych korzystających ze skryptów Brevo. Kampania obejmowała zarówno fałszywe komunikaty typu ClickFix, jak i mechanizm wymierzony w administratorów WordPressa, wykorzystujący aktywną sesję do instalacji złośliwej wtyczki.
Kontekst / historia
Incydent należy rozpatrywać w kontekście wcześniejszego naruszenia, które Brevo ujawniło 10 września 2026 roku. Atakujący mieli wtedy wykorzystać lukę w systemie SAML SSO, uzyskując dostęp do 138 kont. Część przejętych kont posłużyła do phishingu, a z części środowisk wyeksportowano dane kontaktowe.
Kilka dni później doszło do eskalacji. Napastnicy wykorzystali długowieczny klucz API Cloudflare o szerokich uprawnieniach, przechowywany w kodzie aplikacji. To właśnie ten element umożliwił przejęcie kontroli nad mechanizmami przetwarzającymi ruch i przekształcił incydent z klasycznego naruszenia kont w pełnoskalowy atak łańcucha dostaw.
Analiza techniczna
Najważniejszą cechą techniczną ataku było osadzenie złośliwej logiki na poziomie CDN i edge, a nie na serwerze origin. Oznacza to, że tradycyjne mechanizmy wykrywania, takie jak monitoring integralności plików czy porównywanie hashy na backendzie, mogły nie zarejestrować żadnych zmian.
Napastnicy wdrożyli złośliwy Cloudflare Worker, który wstrzykiwał kod do stron Brevo oraz do co najmniej kilku plików JavaScript osadzanych przez klientów. W praktyce legalne komponenty, takie jak widgety czy skrypty śledzące, zaczęły pobierać dodatkowy kod z kontrolowanej przez atakujących ścieżki.
Kampania miała dwa główne wektory działania. Pierwszy opierał się na mechanizmie ClickFix, czyli fałszywym komunikacie mającym skłonić użytkownika do wykonania polecenia w systemie. Drugi był bardziej niebezpieczny dla administratorów WordPressa, ponieważ mógł wykorzystać aktywną sesję zalogowanego użytkownika do instalacji szkodliwej wtyczki bez ponownego logowania.
Złośliwy komponent posiadał również funkcje utrudniające wykrycie i analizę. Według opisu incydentu malware próbowało unikać ekspozycji wobec crawlerów, narzędzi deweloperskich i skanerów bezpieczeństwa, a także mogło maskować się jako pozornie legalna wtyczka oraz utrzymywać komunikację z serwerem C2.
- Złośliwy kod był dostarczany z legalnej infrastruktury dostawcy.
- Modyfikacja następowała na warstwie edge, a nie na serwerze źródłowym.
- Aktywni administratorzy WordPressa byli narażeni na cichą instalację malware.
- Nadmierne uprawnienia pojedynczego klucza API umożliwiły eskalację incydentu.
Konsekwencje / ryzyko
Ryzyko związane z tym incydentem było wysokie, ponieważ złośliwy kod był dostarczany z infrastruktury, której wiele organizacji ufa i nie blokuje. Taki model dystrybucji znacząco zwiększa skuteczność ataku i utrudnia jego szybkie wykrycie.
Dla zwykłych użytkowników zagrożeniem było uruchomienie poleceń systemowych lub wejście w interakcję z fałszywym komunikatem bezpieczeństwa. Dla organizacji korzystających z WordPressa konsekwencje mogły być poważniejsze, obejmując przejęcie witryny, utrzymanie trwałego dostępu, kradzież danych, a nawet dalszy ruch boczny w środowisku.
Szczególnie niepokojący pozostaje aspekt wykrywalności. Jeśli serwery origin nie wykazywały zmian, część zespołów mogła błędnie uznać środowisko za nienaruszone. To pokazuje, że ochrona backendu bez monitoringu usług pośredniczących nie jest już wystarczająca.
Rekomendacje
Organizacje korzystające ze skryptów Brevo powinny przeanalizować logi HTTP, zdarzenia administracyjne WordPressa i historię zmian z okresu ekspozycji. Należy zwrócić szczególną uwagę na nietypowe instalacje wtyczek, podejrzane żądania do panelu administracyjnego oraz nieoczekiwane połączenia wychodzące.
W środowiskach WordPress warto podjąć następujące działania:
- zweryfikować katalogi wtyczek, w tym lokalizacje niestandardowe i ukryte,
- porównać stan plików na dysku z listą rozszerzeń widoczną w panelu,
- sprawdzić, czy nie pojawiły się nietypowe lub zamaskowane pluginy,
- przeprowadzić rotację haseł administratorów i kluczy sesyjnych,
- przejrzeć konta uprzywilejowane oraz aktywne tokeny API.
Z perspektywy architektury bezpieczeństwa kluczowe pozostają także działania długofalowe:
- eliminacja długowiecznych kluczy API i zastępowanie ich poświadczeniami krótkoterminowymi,
- stosowanie zasady najmniejszych uprawnień,
- monitorowanie zmian w CDN, DNS i warstwie edge compute,
- wdrożenie alertów dla nowych Workerów, tras i rekordów DNS,
- segmentacja uprawnień do publikacji skryptów produkcyjnych,
- ograniczanie ryzyka zewnętrznych zależności przy użyciu polityk bezpieczeństwa treści i kontroli skryptów.
Jeżeli którykolwiek pracownik wykonał polecenie wyświetlone przez podejrzany komunikat, jego stację roboczą należy potraktować jako potencjalnie skompromitowaną. W takiej sytuacji wskazana jest pełna analiza hosta, przegląd artefaktów uruchomieniowych i ewentualna izolacja systemu.
Podsumowanie
Incydent Brevo pokazuje, jak groźne stały się nowoczesne ataki łańcucha dostaw oparte na kompromitacji zaufanej infrastruktury. Przejęcie jednego klucza API o zbyt szerokich uprawnieniach wystarczyło, by narazić ogromną liczbę stron internetowych na dystrybucję malware.
Najważniejszy wniosek jest prosty: bezpieczeństwo aplikacji nie kończy się na serwerze origin. Organizacje muszą monitorować również CDN, usługi edge, zewnętrzne skrypty i cały ekosystem zależności, ponieważ to właśnie tam coraz częściej pojawia się rzeczywisty punkt przełamania.
Źródła
- Brevo Supply-Chain Attack Infected Over 100,000 Websites — https://securityaffairs.com/199355/hacking/brevo-supply-chain-attack-infected-over-100000-websites.html
- Brevo notice of incident — https://status.brevo.com/
- Sansec report on the Brevo supply-chain attack — https://sansec.io/