Tag: DDoS

Wprowadzenie do problemu / definicja

Holenderskie organy ścigania przeprowadziły szeroko zakrojoną operację wymierzoną w infrastrukturę hostingową, która miała wspierać cyberataki, operacje zakłócające oraz kampanie dezinformacyjne. Sprawa pokazuje, że współczesny krajobraz zagrożeń obejmuje nie tylko samych sprawców incydentów, ale również zaplecze techniczne i organizacyjne umożliwiające prowadzenie takich działań na dużą skalę.

Z perspektywy bezpieczeństwa to ważny przykład działań przeciwko infrastrukturze pośredniej, czyli serwerom, operatorom i usługom sieciowym, które mogą pełnić funkcję zaplecza dla malware, botnetów, phishingu czy operacji wpływu.

W skrócie

W ramach operacji w Holandii zatrzymano dwóch podejrzanych oraz zabezpieczono około 800 serwerów powiązanych z firmą hostingową podejrzewaną o umożliwianie działań cyberprzestępczych i operacji wpływu. Dochodzenie dotyczyło infrastruktury łączonej z podmiotem Stark Industries, który wcześniej został objęty sankcjami Unii Europejskiej.

• Zatrzymano dwie osoby podejrzane o udział w procederze.
• Zajęto 800 serwerów oraz dokumentację administracyjną.
• Śledztwo objęło centra danych i podmioty zapewniające łączność.
• Badana infrastruktura miała wspierać cyberataki, DDoS i kampanie dezinformacyjne.

Kontekst / historia

Tło sprawy łączy kwestie cyberbezpieczeństwa z egzekwowaniem sankcji. Według ustaleń śledczych infrastruktura była związana z firmą Stark Industries, założoną 10 lutego 2022 roku, czyli tuż przed rozpoczęciem pełnoskalowej rosyjskiej inwazji na Ukrainę. Z czasem podmiot ten trafił na listę sankcyjną UE.

Po objęciu restrykcjami część zaplecza technicznego i operacyjnego miała zostać przeniesiona do nowej spółki zarejestrowanej w Holandii. Taki model działania jest dobrze znany w środowisku bezpieczeństwa: formalne wygaszenie działalności jednego podmiotu i kontynuowanie operacji przez nową strukturę, często pod inną nazwą lub marką.

Istotną rolę w całym ekosystemie miały odgrywać również firmy zapewniające kolokację i łączność internetową. To one odpowiadają za fizyczne utrzymanie sprzętu i dostęp do wysokoprzepustowej infrastruktury sieciowej, co ma kluczowe znaczenie dla podmiotów prowadzących rozproszone i odporne operacje.

Analiza techniczna

Z technicznego punktu widzenia nie chodzi tu o pojedynczą lukę bezpieczeństwa ani jeden incydent, lecz o rozbudowany ekosystem infrastrukturalny. Tego typu zaplecze może służyć do hostowania serwerów dowodzenia i kontroli, obsługi kampanii DDoS, utrzymywania reverse proxy, publikacji fałszywych serwisów czy szybkiego odtwarzania usług po zgłoszeniach abuse.

W praktyce taki model często przypomina tzw. bulletproof hosting, czyli środowisko o podwyższonej tolerancji na nadużycia. Nie musi to oznaczać jawnego wspierania cyberprzestępczości. Wystarczą opóźnione reakcje na zgłoszenia, utrzymywanie klientów wysokiego ryzyka, szybkie przenoszenie usług między serwerami i spółkami oraz zapewnianie odporności operacyjnej.

Skupienie śledczych nie tylko na samej firmie hostingowej, ale też na dostawcach łączności, wskazuje na dojrzałe podejście operacyjne. W nowoczesnych kampaniach cybernetycznych równie ważne jak serwery są przepustowość, stabilność połączeń, dostęp do punktów wymiany ruchu i możliwość omijania blokad.

Przejęcie 800 serwerów mogło jednocześnie przerwać aktywne kampanie, odciąć panele administracyjne, zakłócić infrastrukturę C2, utrudnić dystrybucję złośliwego oprogramowania oraz dostarczyć śledczym cennych artefaktów z logów, nośników i systemów zarządzania.

Konsekwencje / ryzyko

Dla zespołów SOC i analityków zagrożeń ta operacja ma kilka istotnych konsekwencji. Przede wszystkim potwierdza, że infrastruktura wspierająca cyberataki działa dziś jako rozproszona usługa, rozciągnięta między wieloma dostawcami, jurysdykcjami i warstwami technicznymi.

To oznacza, że analiza zagrożeń nie może kończyć się na pojedynczym adresie IP czy domenie. Konieczne staje się mapowanie zależności infrastrukturalnych, powiązań właścicielskich, numerów ASN, zakresów adresowych, certyfikatów, reverse DNS czy wzorców routingu.

Warto też pamiętać, że rozbicie jednego segmentu infrastruktury rzadko eliminuje zagrożenie natychmiast. Operatorzy cyberataków zwykle dysponują zapasowymi serwerami, alternatywnymi pulami adresowymi i procedurami szybkiej migracji do innych dostawców.

• Ryzyko dalszej aktywności z nowych lokalizacji pozostaje wysokie.
• Historyczne wskaźniki kompromitacji mogą nadal pojawiać się w telemetrii.
• Dostawcy infrastruktury narażają się na skutki regulacyjne, prawne i reputacyjne.

Rekomendacje

Organizacje odpowiedzialne za bezpieczeństwo powinny potraktować ten incydent jako impuls do przeglądu procesów detekcji i zarządzania ryzykiem infrastrukturalnym. W praktyce oznacza to rozszerzenie threat intelligence o dane dotyczące hostingu, centrów danych, ASN i relacji pomiędzy podmiotami technicznymi.

Warto rozwijać korelację alertów nie tylko na podstawie klasycznych IOC, ale również zależności infrastrukturalnych, takich jak wspólne certyfikaty, zakresy IP, reverse DNS, wzorce BGP czy schematy migracji usług. Kluczowe znaczenie ma też dłuższe przechowywanie logów sieciowych i DNS, aby możliwe było retrospektywne wykrywanie komunikacji z infrastrukturą rozbitą dopiero po czasie.

• Monitorować ruch do środowisk hostingowych wysokiego ryzyka.
• Wzmacniać ochronę przed DDoS poprzez filtrację upstream, rate limiting i plany awaryjne.
• Aktualizować listy reputacyjne i reguły blokujące o nowych operatorów oraz marki.
• Weryfikować ekspozycję na dostawców, którzy mogą być częścią większego ekosystemu nadużyć.
• U dostawców usług zaostrzyć procesy KYC, obsługi abuse i monitorowania klientów wysokiego ryzyka.

Podsumowanie

Przejęcie 800 serwerów w Holandii to przykład operacji, w której cyberbezpieczeństwo, analiza infrastruktury telekomunikacyjnej i egzekwowanie sankcji łączą się w jedno postępowanie. Najważniejszy wniosek dla rynku jest jasny: współczesne cyberzagrożenia opierają się nie tylko na złośliwym oprogramowaniu i aktorach zagrożeń, ale również na rozbudowanym zapleczu hostingowym, sieciowym i organizacyjnym.

Dla obrońców oznacza to konieczność patrzenia szerzej niż na pojedyncze IOC. Skuteczna ochrona wymaga rozumienia całego ekosystemu infrastruktury, który umożliwia atakującym skalowanie działań i szybkie odtwarzanie zdolności operacyjnych.

Źródła

1. BleepingComputer — https://www.bleepingcomputer.com/news/security/netherlands-seizes-800-servers-of-hosting-firm-enabling-cyberattacks/
2. FIOD — https://www.fiod.nl/
3. De Volkskrant — https://www.volkskrant.nl/
4. Rada Unii Europejskiej / EUR-Lex — https://eur-lex.europa.eu/

Wprowadzenie do problemu / definicja

W lipcu 2025 roku Luksemburg doświadczył poważnej, ogólnokrajowej awarii usług telekomunikacyjnych, która objęła telefonię stacjonarną, łączność mobilną 4G i 5G oraz część usług alarmowych. Z późniejszych ustaleń medialnych wynika, że źródłem incydentu mogło być wykorzystanie niepublicznie udokumentowanego błędu w oprogramowaniu routerów klasy operatorskiej Huawei.

Tego rodzaju przypadek wpisuje się w kategorię incydentów związanych z podatnością zero-day, czyli luką nieznaną publicznie i niedostępną do natychmiastowego załatania w chwili ataku. W praktyce oznacza to bardzo ograniczone możliwości obrony, szczególnie gdy zagrożenie dotyczy krytycznych elementów infrastruktury telekomunikacyjnej.

W skrócie

23 lipca 2025 roku doszło do zakłócenia działania infrastruktury POST Luxembourg, co przełożyło się na wielogodzinną niedostępność kluczowych usług łączności w całym kraju. Według dostępnych informacji problem miał zostać wywołany przez specjalnie spreparowany ruch sieciowy, który doprowadzał urządzenia brzegowe i rdzeniowe do ciągłych restartów.

Incydent nie przypominał klasycznego wolumetrycznego ataku DDoS. Bardziej prawdopodobny był scenariusz logicznego ataku na zachowanie urządzeń sieciowych, w którym niewielki, ale odpowiednio przygotowany ruch powodował destabilizację infrastruktury.

• Zakłócenia objęły telefonię, Internet mobilny i część usług krytycznych.
• Problem miał dotyczyć urządzeń Huawei wykorzystywanych w sieci operatora.
• Przez długi czas brakowało publicznego identyfikatora CVE oraz szczegółowego biuletynu technicznego.

Kontekst / historia

Pierwsze komunikaty po awarii wskazywały na poważny incydent techniczny wpływający na infrastrukturę telekomunikacyjną państwowego operatora. Ze względu na wpływ na komunikację alarmową oraz szeroki zasięg zakłóceń uruchomiono mechanizmy reagowania kryzysowego na poziomie krajowym.

W kolejnych etapach pojawiały się informacje sugerujące, że przyczyną nie była zwykła awaria sprzętowa ani tradycyjny rozproszony atak przeciążeniowy. Z czasem śledztwo zaczęło wskazywać na nietypowe zachowanie urządzeń Huawei działających w infrastrukturze operatora.

Według relacji opartych na źródłach zaznajomionych ze sprawą, atak miał wykorzystywać nieudokumentowane zachowanie oprogramowania, dla którego w momencie incydentu nie istniała poprawka. Jednocześnie brak jednoznacznych dowodów na wybór konkretnego celu może sugerować scenariusz oportunistyczny, testowy albo niezamierzone oddziaływanie złośliwego ruchu na podatną infrastrukturę tranzytową.

Analiza techniczna

Najbardziej prawdopodobny mechanizm incydentu polegał na dostarczeniu do podatnych urządzeń specjalnie skonstruowanych pakietów lub sekwencji ruchu, które aktywowały nieobsłużony stan błędny w oprogramowaniu routerów. W efekcie urządzenia nie realizowały standardowego forwardingu, lecz przechodziły w pętlę awarii i restartów.

Dla sieci operatorskiej jest to scenariusz szczególnie niebezpieczny, ponieważ nawet krótkotrwała niestabilność elementów warstwy kontrolnej lub routingu może wywołać efekt kaskadowy. Restart urządzeń powoduje utratę sesji routingu, ponowne zestawianie sąsiedztw protokołów dynamicznych oraz zaburzenia propagacji tras.

W praktyce skutki mogły obejmować kilka warstw jednocześnie:

• chwilowy blackholing ruchu i niestabilność ścieżek,
• przeciążenie alternatywnych segmentów infrastruktury,
• problemy z telefonią i transmisją danych mobilnych,
• zakłócenia usług krytycznych opartych na tej samej warstwie sieciowej.

Na podstawie ujawnionych informacji nie wygląda to na klasyczne zdalne wykonanie kodu, lecz raczej na błąd w logice obsługi pakietów, który umożliwiał wymuszenie trwałej degradacji dostępności. Tego typu podatności są trudniejsze do wykrycia niż typowe luki pamięciowe, ponieważ mogą być aktywowane wyłącznie przez specyficzne kombinacje parametrów ruchu i nie muszą pozostawiać oczywistych artefaktów związanych z malware.

Dodatkowym problemem jest ograniczona obserwowalność. Jeżeli urządzenie wpada w szybkie pętle restartów, analiza przyczynowa wymaga dostępu do logów niskiego poziomu, telemetrii control-plane, danych z systemów zarządzania siecią oraz szczegółowych informacji o stanie procesów systemowych.

Konsekwencje / ryzyko

Incydent pokazał, że pojedyncza, niejawna podatność w komponencie sieciowym może przełożyć się na zakłócenie usług o znaczeniu krajowym. Ryzyko nie ogranicza się wyłącznie do niedostępności Internetu czy telefonii komórkowej, ale obejmuje również wpływ na numery alarmowe, systemy powiadamiania kryzysowego, operacje biznesowe, logistykę, płatności oraz ciągłość działania administracji.

Z perspektywy cyberbezpieczeństwa szczególnie niepokojące są cztery elementy. Po pierwsze, podatność miała charakter niepubliczny, więc organizacje korzystające z podobnych urządzeń mogły nie mieć świadomości zagrożenia. Po drugie, atak nie musiał generować ogromnego wolumenu ruchu, co utrudnia jego odróżnienie od nietypowych anomalii protokołowych. Po trzecie, skutki były natychmiastowe i szerokie. Po czwarte, ograniczona komunikacja wokół procesu naprawczego utrudniała ocenę skali ekspozycji.

Dla operatorów telekomunikacyjnych oraz dużych przedsiębiorstw z własnymi sieciami WAN oznacza to konieczność traktowania urządzeń sieciowych jako obszaru wysokiego ryzyka. Błąd w routerze lub przełączniku może dziś wywołać skutki porównywalne z incydentem dotyczącym systemów serwerowych czy środowisk chmurowych.

Rekomendacje

Organizacje powinny rozpocząć od pełnej inwentaryzacji urządzeń sieciowych z podziałem na producenta, wersję firmware, rolę w architekturze oraz ekspozycję na ruch zewnętrzny. Szczególną uwagę należy poświęcić urządzeniom obsługującym warstwę brzegową, routowanie międzyoperatorskie, usługi mobilne i segmenty krytyczne dla ciągłości działania.

Konieczne jest także wdrożenie telemetrii umożliwiającej wykrywanie niestandardowych zjawisk w warstwie kontrolnej. Chodzi między innymi o wzrost liczby restartów, flapping sesji routingu, skoki wykorzystania CPU na control-plane, nietypowe zrzuty procesów oraz anomalie w kolejkach pakietów.

• wdrożenie reguł ochrony control-plane,
• filtrowanie ruchu do płaszczyzny zarządzania,
• mechanizmy rate limiting dla wrażliwych typów pakietów,
• dodatkowa redundancja geograficzna i technologiczna,
• testowanie scenariuszy failover również pod kątem błędów logicznych.

Ważne jest również doprecyzowanie współpracy między SOC, NOC i zespołami inżynierii sieci. W incydentach tego typu granica między awarią a atakiem bywa nieostra, dlatego szybka korelacja danych operacyjnych i bezpieczeństwa ma kluczowe znaczenie.

Na poziomie zarządczym warto wymagać od dostawców większej przejrzystości w zakresie podatności wpływających na dostępność usług krytycznych. Dotyczy to zarówno terminowego publikowania informacji o poprawkach, jak i jasnego określenia zakresu podatnych produktów, warunków wyzwolenia błędu oraz dostępnych mitigacji.

Podsumowanie

Awaria telekomunikacyjna w Luksemburgu z 23 lipca 2025 roku stanowi ważny przykład tego, jak niejawna podatność w infrastrukturze sieciowej może doprowadzić do zakłóceń o skali państwowej. Według dostępnych ustaleń incydent był związany z wykorzystaniem nieudokumentowanego zachowania w oprogramowaniu routerów Huawei, co prowadziło do pętli restartów i utraty dostępności usług.

Sprawa podkreśla znaczenie bezpieczeństwa warstwy sieciowej, konieczność budowania odporności na błędy logiczne w urządzeniach operatorskich oraz potrzebę większej transparentności producentów w procesie ujawniania i naprawy podatności.

Źródła

1. Security Affairs — https://securityaffairs.com/192431/hacking/alleged-huawei-zero-day-blamed-for-the-2025-luxembourg-telecom-crash.html
2. The Record — Huawei zero-day attack behind last year’s crash of Luxembourg’s entire telecoms network — https://therecord.media/huawei-zero-day-behind-last-year-luxembourg-telecom-outage
3. Infocrise Luxembourg — La cellule de crise s’est réunie, à la suite des perturbations des réseaux de communication de POST (23.07.2025) — https://infocrise.public.lu/fr/actualites/2025/cellule-de-crise-perturbations-post.html
4. Chronicle.lu — Major POST Luxembourg Outage Prompts National Crisis Response — https://chronicle.lu/category/telecomms/56017-major-post-luxembourg-outage-prompts-national-crisis-response
5. SDxCentral — Mystery Huawei flaw behind blanket Luxembourg outage — https://www.sdxcentral.com/news/mystery-huawei-flaw-behind-blanket-luxourg-outage/

Wprowadzenie do problemu / definicja

Wyciek kodu źródłowego złośliwego oprogramowania często prowadzi do szybkiego pojawienia się nowych wariantów i kampanii naśladowczych. Taki scenariusz obserwujemy obecnie w ekosystemie npm, gdzie po ujawnieniu kodu robaka Shai-Hulud zaczęły pojawiać się pakiety zawierające jego klony lub uproszczone wersje, ukierunkowane na przejęcie sekretów deweloperskich oraz dalszą propagację w łańcuchu dostaw oprogramowania.

Shai-Hulud to malware typu worm wykorzystywane w atakach supply chain przeciwko społeczności open source. Jego głównym celem jest kradzież poświadczeń, tokenów publikacyjnych, kluczy API i innych sekretów z maszyn deweloperskich, a następnie użycie przejętych kont do publikowania kolejnych zainfekowanych paczek.

W skrócie

• Po wycieku kodu źródłowego Shai-Hulud pojawiły się aktywne kopie malware w rejestrze npm.
• Atakujący publikowali złośliwe pakiety przeznaczone do kradzieży tokenów, kluczy API i innych sekretów.
• Część kampanii wykorzystywała typo-squatting, podszywając się pod znane biblioteki.
• Jeden z wariantów miał dodatkowo próbować wykorzystywać zainfekowane systemy do działań DDoS.
• Incydent zwiększa ryzyko kolejnych ataków supply chain wymierzonych w deweloperów i pipeline’y CI/CD.

Kontekst / historia

Pierwsze publiczne informacje o aktywności Shai-Hulud pojawiły się we wrześniu 2025 roku, kiedy zagrożenie powiązano z atakami na otwarty ekosystem pakietów. W kolejnych miesiącach malware był łączony z kompromitacją licznych pakietów npm, co mogło oddziaływać na szeroką grupę deweloperów oraz środowisk automatycznego budowania i wdrażania oprogramowania.

Istotnym momentem eskalacji było powiązanie kampanii z grupą TeamPCP. Następnie doszło do krótkotrwałego ujawnienia repozytoriów zawierających pełny kod źródłowy Shai-Hulud. Taki wyciek znacząco obniżył próg wejścia dla mniej zaawansowanych aktorów zagrożeń, którzy zamiast tworzyć własne narzędzia mogli po prostu zaadaptować gotowy kod do własnych operacji.

W efekcie zagrożenie przestało być problemem związanym wyłącznie z jedną grupą i zaczęło funkcjonować jako model ataku możliwy do łatwego powielania. To szczególnie niebezpieczne w ekosystemach opartych na automatycznym pobieraniu zależności, gdzie pojedyncza pomyłka w nazwie pakietu może doprowadzić do uruchomienia złośliwego kodu.

Analiza techniczna

Z technicznego punktu widzenia Shai-Hulud należy do klasy malware atakującego software supply chain poprzez przejęcie zaufanych kanałów dystrybucji. Po instalacji złośliwego pakietu robak koncentruje się na pozyskaniu wrażliwych danych z systemu ofiary, a następnie na ich eksfiltracji do infrastruktury kontrolowanej przez operatora kampanii.

Najczęściej celem są:

• tokeny publikacyjne npm,
• poświadczenia do repozytoriów kodu,
• klucze API,
• sekrety środowisk chmurowych,
• dane uwierzytelniające używane w CI/CD.

Według analiz jednym z wykrytych wariantów był pakiet „chalk-tempalte”, który zachowywał kluczowe elementy działania oryginalnego Shai-Hulud, w tym mechanizm przesyłania przejętych poświadczeń do nowej infrastruktury kontrolowanej przez atakującego. Oznacza to, że nawet uproszczone kopie malware mogą zachować najbardziej niebezpieczne funkcje pierwotnej kampanii.

Atakujący wykorzystywali także typo-squatting, publikując pakiety o nazwach łudząco podobnych do legalnych bibliotek. Wśród zidentyfikowanych nazw znalazły się między innymi:

• @deadcode09284814/axios-util,
• axois-utils,
• chalk-tempalte,
• color-style-utils.

Tego typu nazwy bazują na typowych literówkach, przestawieniu znaków lub zastosowaniu ogólnych członów brzmiących wiarygodnie. To technika szczególnie skuteczna w środowiskach deweloperskich, gdzie instalacja zależności bywa wykonywana szybko i bez pełnej weryfikacji autora, historii pakietu czy zawartości skryptów instalacyjnych.

Szczególnie niepokojący jest fakt, że jeden z wykrytych pakietów miał nie tylko kraść sekrety, ale również próbować włączać zainfekowane systemy do botnetu DDoS. Wskazuje to na testowanie różnych modeli monetyzacji — od przejmowania kont maintainerskich, przez kradzież dostępu do środowisk chmurowych, po wykorzystywanie zasobów ofiar do operacji zakłócających.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko związane z kopiami Shai-Hulud wynika ze skali i szybkości replikacji tego modelu ataku. Po upublicznieniu kodu źródłowego nie trzeba już dysponować dużym doświadczeniem w tworzeniu malware, aby uruchomić kampanię wymierzoną w deweloperów npm. Wystarczą podstawowe modyfikacje kodu, własna infrastruktura odbioru danych i odpowiednio dobrane nazwy pakietów.

Dla organizacji rozwijających oprogramowanie skutki mogą być bardzo poważne. Kompromitacja jednej stacji deweloperskiej może prowadzić do przejęcia tokenów publikacyjnych, naruszenia kont maintainerskich, modyfikacji legalnych pakietów, wycieku sekretów środowiskowych, naruszenia pipeline’ów CI/CD oraz dalszego rozprzestrzeniania incydentu na klientów i partnerów.

Z perspektywy bezpieczeństwa łańcucha dostaw jest to klasyczny przykład zagrożenia, w którym zaufanie do rejestru pakietów i automatyzacji buildów staje się wektorem wejścia. Ryzyko dodatkowo rośnie, gdy atakujący łączą kilka technik jednocześnie: typo-squatting, kradzież sekretów, publikację złośliwych aktualizacji i wtórne wykorzystanie przejętych zasobów.

Rekomendacje

Zespoły bezpieczeństwa i organizacje rozwijające oprogramowanie powinny potraktować ten incydent jako sygnał do zaostrzenia kontroli nad zależnościami oraz poświadczeniami używanymi w procesie wytwarzania oprogramowania.

• Weryfikować nowe pakiety przed instalacją, zwłaszcza pod kątem autora, historii publikacji i podobieństwa nazwy do popularnych bibliotek.
• Monitorować rejestry pakietów pod kątem typo-squattingu, podejrzanych skryptów instalacyjnych i nietypowych zmian maintainerów.
• Ograniczać użycie długowiecznych tokenów i tam, gdzie to możliwe, korzystać z mechanizmów trusted publishing.
• Wymuszać 2FA dla kont maintainerskich i administracyjnych odpowiedzialnych za publikację pakietów.
• Regularnie rotować i segmentować sekrety, w tym tokeny npm, klucze API i poświadczenia do repozytoriów.
• Prowadzić inspekcję stacji deweloperskich oraz runnerów buildów pod kątem oznak eksfiltracji danych i nietypowego ruchu sieciowego.
• Wdrożyć polityki dopuszczania zależności oraz listy zatwierdzonych źródeł i wersji pakietów.
• Analizować logi publikacji i zmian w pakietach, aby szybko wykrywać nieautoryzowane działania.

Podsumowanie

Pojawienie się kopii Shai-Hulud po wycieku kodu źródłowego potwierdza znany mechanizm eskalacji zagrożeń w cyberprzestrzeni: gdy skuteczne narzędzie trafia do szerszego obiegu, szybko zaczyna być adaptowane przez kolejnych aktorów. W tym przypadku celem pozostaje ekosystem npm oraz szeroko rozumiany software supply chain.

Największym problemem nie jest wyłącznie sam malware, lecz łatwość jego ponownego użycia, połączenie z typo-squattingiem oraz koncentracja na sekretach deweloperskich i kontach maintainerskich. Obrona przed podobnymi kampaniami wymaga jednoczesnego wzmacniania kontroli tożsamości, higieny sekretów, monitorowania zależności i szybkiego reagowania na anomalie w procesie publikacji oprogramowania.

Źródła

1. https://securityaffairs.com/192366/malware/shai-hulud-worm-copycats-emerge-after-source-code-leak.html
2. https://www.ox.security/blog/new-actors-deploy-shai-hulud-clones-teampcp-copycats-are-here/
3. https://docs.npmjs.com/trusted-publishers
4. https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification
5. https://blog.npmjs.org/post/163723642530/crossenv-malware-on-the-npm-registry