Dyrektywa NIS2 to największa od lat zmiana w podejściu do cyberbezpieczeństwa w Europie. Jej celem nie jest biurokracja, lecz wprowadzenie realnych, mierzalnych standardów bezpieczeństwa – organizacje muszą nie tylko wdrożyć środki ochrony, ale także wykazać ich skuteczność. Oznacza to konieczność stałego monitorowania systemów, regularnego mierzenia efektywności zabezpieczeń i przeprowadzania audytów, aby udowodnić przed regulatorami i interesariuszami, że cyberbezpieczeństwo jest utrzymywane na wysokim poziomie i podlega ciągłemu doskonaleniu.
Cisco Talos opisał szereg incydentów z 2025 r., które ujawniają aktualny łańcuch ataku Qilin (dawniej Agenda) – jednego z najbardziej „produktywnych” gangów ransomware. Zespół IR Talosa obserwuje ponad 40 publikacji ofiar miesięcznie na stronie wycieków Qilin, ze szczytami aktywności sięgającymi ~100 przypadków (czerwiec i sierpień 2025). Najmocniej cierpi produkcja, a dalej usługi profesjonalne i handel hurtowy.
W skrócie
Model RaaS: Qilin działa jako usługa, rozwijając platformę i udostępniając ją afilantom; podwójny szantaż (szyfrowanie + wyciek).
Początkowy dostęp: w badanych sprawach częste są nadużycia ważnych kont/VPN bez MFA, czasem zmiany GPO w AD w celu włączenia RDP; obserwowano także spear-phishing i wykorzystanie wycieków haseł.
Eksfiltracja: paczkowanie WinRAR, przesył przez legalne narzędzia (np. Cyberduck do Backblaze), „ręczne” przeglądanie danych nawet notatnikiem/mspaint.
Ruch boczny i utrzymanie: PsExec, modyfikacje zapory i RDP, instalacje wielu RMM (AnyDesk, ScreenConnect, Chrome Remote Desktop itd.).
Szyfrowanie: wariant Qilin.B (Rust) używa AES-256-CTR lub ChaCha20 + RSA-4096 (OAEP), terminacja usług backup/DB/AV, czyszczenie logów i niszczenie VSS.
Skala zagrożenia: w II kw. 2025 Qilin był najaktywniejszym ransomware wobec podmiotów SLTT w USA (MS-ISAC).
Kontekst / historia / powiązania
Qilin (wcześniej Agenda) działa od lipca 2022 r., oferując RaaS i prowadząc wycieki danych na własnym portalu. Z czasem ewoluował technicznie (m.in. przepisany na Rust; utrzymano też wersje Linux/ESXi) i organizacyjnie (aktywny rekrut na forach). W 2024 r. HHS/HC3 publikował profil zagrożenia wskazujący na spear-phishing i warianty Windows/Linux; w 2024/2025 Halcyon śledził wariant Qilin.B z usprawnioną kryptografią i ewakuacją kluczowych artefaktów.
W 2025 r. incydenty przypisywane Qilin odnotowano w różnych sektorach i krajach; przykładem jest głośny atak na japoński Asahi Group (zakłócenia produkcji i publikacja danych).
Analiza techniczna / szczegóły luki
Wejście / inicjalny dostęp
Nadużycie ważnych kont i brak MFA na VPN; wzmożone próby NTLM po pojawieniu się haseł w darknecie; możliwe zmiany GPO w celu ułatwienia RDP.
(Historycznie) spear-phishing, w tym złośliwe załączniki i kradzież poświadczeń.
Rozpoznanie i zbieranie
nltest, net user, whoami /priv, tasklist; narzędzia skanowania sieci; dedykowany pakiet do zrzutu haseł (NirSoft, Mimikatz). Modyfikacja WDigest (UseLogonCredential=1) ułatwiająca pozyskanie plaintextów. Dane agregowane skryptami i eksportowane (SMTP, pliki wynikowe z kodowaniem Windows-1251).
Eksfiltracja
Archiwizacja WinRAR, inspekcja dokumentów nawet przez notepad.exe/mspaint.exe/iexplore.exe; nadużycie Cyberduck do chmury (Backblaze) z podziałem na części.
Eskalacja uprawnień i ruch boczny
Dodawanie napastniczych kont do Local Administrators, wymuszanie RDP, tworzenie udziałów typu net share c=c:\ /grant: everyone,full; rozproszenie przez PsExec. Obserwacje wielu RMM (AnyDesk, ScreenConnect, Distant Desktop, QuickAssist, Chrome Remote Desktop).
Unikanie obrony
Silnie zaciemniony PowerShell z wyłączeniem AMSI, obejściem walidacji TLS oraz włączeniem Restricted Admin dla RDP (hash-based auth).
Przygotowanie środowiska i trwałość
Wyłączanie/ubijanie procesów AV/backup/DB, czyszczenie logów, tworzenie Scheduled Task („TVInstallRestore”) i wpisów Run podszywających się pod TeamViewer.
Szyfrowanie (Qilin.B)
Kombinacja AES-256-CTR (jeśli dostępne AES-NI) / ChaCha20 (fallback) + RSA-4096/OAEP do ochrony kluczy; noty okupu README-RECOVER-[company_id].txt; rozszerzenia plików wg unikalnego ID ofiary. Wykrywana enumeracja udziałów i dysków, ukierunkowanie na ClusterStorage/CSV (Hyper-V/VM/VHDX) przy jednoczesnym unikaniu pętli po symlinkach. Usuwanie VSS i autodestrukcja binarium.
IOCs i detekcje
Talos publikuje wykazy IOC (GitHub), Snort SID oraz ClamAV (np. Win.Ransomware.Qilin, SystemBC, Cobalt Strike).
Praktyczne konsekwencje / ryzyko
Czas przestoju: ataki celują w środowiska wirtualizacji i plików współdzielonych (CSV/Hyper-V), co zwiększa wpływ na produkcję i usługi krytyczne.
Ryzyko reputacyjne i prawne przez systematyczną ekfiltrację (Backblaze/Cyberduck) oraz publikację na stronie wycieków.
Trend rynkowy: Qilin był w Q2 2025 najaktywniejszą rodziną wobec SLTT w USA, co potwierdza jego dojrzałość operacyjną i tempo działania.
Incydenty głośne medialnie (np. Asahi) pokazują realny wpływ na produkcję i łańcuch dostaw.
Rekomendacje operacyjne / co zrobić teraz
Kontrole prewencyjne
MFA bez wyjątków na VPN, RDP, poczcie i aplikacjach krytycznych; wymuś klient-based MFA dla kont uprzywilejowanych.
Higiena tożsamości: rotacja haseł po wyciekach, blokady na „password spraying” (T1110.003), monitorowanie NTLM.
Twardnienie RDP: wyłącz zdalne logowanie tam, gdzie zbędne; kontrola fDenyTSConnections, ograniczenia sieciowe/Jump Host; Restricted Admin tylko jeśli świadomie zarządzany.
Egress/Exfil kontrola: DLP/CTI-driven blokady dla Backblaze i nietypowych klientów S3/WebDAV; monitoruj użycie Cyberduck, WinRAR w trybie archiwizacji masowej.
Backup i odzyskiwanie: izolowane kopie, testy odtwarzania, ochrona VSS przed usuwaniem; segmentacja Hyper-V/CSV.
Detekcja i reagowanie (SOC/SIEM/EDR)
Reguły: Snort/ClamAV zgodnie z publikacją Talos; korelacje dla PsExec, net share c=, WDigest UseLogonCredential=1, zaciemnionego PowerShell wyłączającego AMSI, nietypowego schtasks /Create /SC ONLOGON.
Kryptonotatki/rozszerzenia: alarmy na README-RECOVER-[company_id].txt oraz nowe rozszerzenia „.[company_id]”.
Procedury IR
Izolacja i triage hostów z aktywnością WinRAR/Cyberduck, ścieżkami Backblaze, masową terminacją usług bezpieczeństwa/backup.
Łańcuch dowodowy: zabezpieczenie logów przed czyszczeniem (wczesna centralizacja, forward-only, write-once).
Komunikacja kryzysowa i ocena ryzyka wycieku (PII, IP, dane produkcyjne).
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Qilin vs. „typowy” RaaS 2025: podobnie jak inne operacje, Qilin intensywnie eksfiltruje i używa RMM/LOLBINs; odróżnia go ukierunkowanie na CSV/Hyper-V i szerokie wykorzystanie legalnych narzędzi do eksfiltracji (Cyberduck).
Qilin.B (Rust) wyróżnia kombinowany wybór szyfru (AES-NI → AES-CTR, fallback → ChaCha20) i mocną ochronę kluczy RSA-4096/OAEP, co komplikuje odzysk bez kluczy.
Wieloplatformowość: raporty z 2025 r. pokazują nawet wdrażanie binarek Linux na systemach Windows przez RMM/BYOVD, co utrudnia detekcję.
Podsumowanie / kluczowe wnioski
Qilin utrzymuje wysokie tempo kampanii i dojrzały łańcuch ataku: kradzież poświadczeń (WDigest/Mimikatz/NirSoft), ruch boczny (PsExec/RDP/RMM), eksfiltracja przez chmurę (Cyberduck→Backblaze), a następnie szyfrowanie zoptymalizowane dla środowisk wirtualnych (CSV/Hyper-V) i agresywna ewakuacja artefaktów. Obrona wymaga dyscypliny IAM/MFA, twardnienia RDP/VPN, kontroli egress/exfil, oraz predefiniowanych detekcji TTP. Publikacje Cisco Talos i analizy branżowe (HHS/HC3, Halcyon, CIS, Trend Micro) dostarczają praktycznych wskaźników i reguł do natychmiastowego wdrożenia.
Źródła / bibliografia
Cisco Talos – Uncovering Qilin attack methods exposed through multiple cases, 26 października 2025 (TTP, IOCs, Snort/ClamAV). (Cisco Talos Blog)
Halcyon – New Qilin.B Ransomware Variant…, 24 października 2024 (kryptografia, mechanika szyfrowania). (Halcyon)
CIS (MS-ISAC) – Qilin: Top Ransomware Threat to SLTTs in Q2 2025, 11 września 2025 (trend aktywności). (CIS)
Trend Micro – Agenda Ransomware Deploys Linux Variant on Windows Systems…, 23 października 2025 (nietypowe wdrożenia Linux przez RMM/BYOVD). (www.trendmicro.com)
Dlaczego techniczne i organizacyjne środki bezpieczeństwa są kluczowe dla zgodności z NIS2?
Dyrektywa NIS2 stawia jasne wymagania: organizacje objęte jej zakresem muszą wdrożyć odpowiednie i proporcjonalne środki cyberbezpieczeństwa – zarówno techniczne, jak i organizacyjne. Nie chodzi tu o sztuczną biurokrację czy „odhaczanie” zgodności na papierze. NIS2 wymusza realne zabezpieczenia, które mają chronić krytyczne usługi i dane przed współczesnymi zagrożeniami.
22 października 2025 r. rosyjska państwowa służba nadzoru weterynaryjnego i fitosanitarnego (Rosselkhoznadzor) ogłosiła, że jej systemy informatyczne zostały objęte zakrojonym na szeroką skalę atakiem DDoS. Uderzenie dotknęło m.in. kluczowe platformy VetIS i Saturn, w tym komponent Mercury odpowiedzialny za elektroniczne wystawianie weterynaryjnych dokumentów towarzyszących (E-VSD), bez których legalny obrót mięsem, nabiałem, jajami i inną żywnością pochodzenia zwierzęcego jest w Rosji niemożliwy. Według doniesień branżowych skutkiem były opóźnienia i przestoje w wysyłkach produktów spożywczych.
W skrócie
Kiedy? Środa, 22 października 2025 r. (komunikaty i relacje z 22–24 października).
Co się stało? Skorelowane wolumetryczne ataki DDoS zakłóciły dostęp do VetIS/Saturn, w tym do Mercury.
Skutek biznesowy: Część producentów (m.in. mleczarskich i żywności dla dzieci) zgłaszała wstrzymanie/zwłoki w odczytach i wystawianiu E-VSD, co spowodowało czasowe zablokowanie wysyłek.
Stan oficjalny: Rosselkhoznadzor utrzymywał, że nie ma zagrożenia integralności/confidentiality danych, a Mercury „działa w trybie normalnym”, mimo możliwej okresowej niedostępności per region/łączność.
Powtarzalność: To co najmniej czwarty incydent wpływający na Mercury w 2025 r.; w czerwcu firmy przechodziły na tryb „papierowy”, co wywołało chaos logistyczny.
Kontekst / historia / powiązania
Mercury (część VetIS) jest centralnym rejestrem śledzenia łańcucha „od pola do półki” dla produktów pochodzenia zwierzęcego. Od 2018 r. wystawianie E-VSD w Mercury jest obowiązkowe dla podmiotów obracających m.in. mięsem, rybami, jajami, miodem, mlekiem i szeroką gamą przetworów — bez tych dokumentów detaliści i przetwórcy nie mogą prawnie przyjmować towaru.
W 2025 r. system był już kilkukrotnie zakłócany: w czerwcu odnotowano przerwę skutkującą przejściem części branży na obieg papierowy i specjalne procedury awaryjne. Obecny incydent z 22 października ponownie unaocznił krytyczność Mercury jako punktu pojedynczej awarii (SPOF) dla dostaw żywności.
Analiza techniczna / szczegóły incydentu
Z dostępnych komunikatów wynika, że:
Atak miał charakter wolumetrycznych DDoS (duży wolumen szkodliwego ruchu), z objawami niestabilności łączy i urządzeń brzegowych zapewniających dostęp do Internetu. Operatorzy (m.in. Megafon, Rostelecom, Intelsk) mieli filtrować ruch, co powodowało miejscowe/okresowe niedostępności.
Wpływ obejmował VetIS/Saturn i dostęp do usług Mercury. Z perspektywy części producentów oznaczało to praktyczną blokadę wystawiania E-VSD i brak możliwości legalnej wysyłki/odbioru towaru.
Rosselkhoznadzor podkreślał brak kompromitacji danych oraz deklarował działanie Mercury „w zwykłym trybie”, co stoi w napięciu z relacjami rynkowymi o przestojach trwających kilka godzin (m.in. u dwóch dużych mleczarni i producenta żywności dla dzieci).
Hipotezy techniczne (w oparciu o znane TTP dla DDoS):
Scenariusz ataku rozproszonym ruchem z botnetu (warstwa 3/4) z okresowymi falami, wymuszający filtrowanie/Blackholing przez operatorów i powodujący „efekt uboczny” w postaci utraty dostępności częściowo geograficznie.
Możliwe komponenty L7 (HTTP/S) na frontach aplikacyjnych Mercury/VetIS, zwiększające czas odpowiedzi, time-outy i błędy przy autoryzacji dokumentów.
Brak skutecznej, automatycznej procedury „graceful degradation” (np. przełączenia na podpisy wsadowe/offline albo tryb cache’owania tokenów dokumentów) — co tłumaczy różnicę między deklarowaną „pracą systemu” a realną dostępnością funkcji krytycznych po stronie użytkowników.
Praktyczne konsekwencje / ryzyko
Zakłócenia łańcucha dostaw żywności w skali kraju: brak E-VSD = brak możliwości przyjmowania towaru przez sieci handlowe i przetwórców; odnotowano wstrzymania wysyłek „przez pół dnia” u części producentów.
Ryzyko finansowe: przestój linii produkcyjnych, utrata świeżości produktów krótkoterminowych (nabiał), kary umowne za opóźnienia.
Ryzyko regulacyjne i reputacyjne: rozbieżność komunikatów urzędowych i obserwacji rynkowych; presja na formalizację trybów awaryjnych (wysyłka bez E-VSD z późniejszym uzupełnieniem).
Trend: wzrost częstotliwości ataków na systemy logistyczno-certyfikacyjne; analogiczne ostrzeżenia dla sektora logistyki publikowały instytucje rządowe na Zachodzie (choć dot. innych celów).
Rekomendacje operacyjne / co zrobić teraz
Dla właścicieli systemów krytycznych (gov/branża):
Anycast + wielowarstwowe scrubbing centers (L3/4 i L7) z automatycznym failoverem między dostawcami; testy grywalizowane TTX co kwartał.
Segmentacja usług Mercury-like: separacja krytycznych ścieżek wystawiania E-VSD od interfejsów publicznych; dynamiczne limitowanie żądań (rate-limiting, token-bucket) per AS/region/UA.
Procedury „degraded mode”: tryb awaryjny dopuszczający czasową legalną wysyłkę bez pełnego E-VSD z obowiązkowym dosłaniem w oknie 24–48 h; formalne, z góry uzgodnione z regulatorami i sieciami handlowymi. (Takie rozwiązania były już stosowane podczas wcześniejszych zakłóceń w 2025 r.).
Redundancja geograficzna i DNS: active-active z izolacją blast radius, niezależne łącza i dostawcy.
Telemetria anty-DDoS: BGP Flowspec/RTBH, automatyczna orkiestracja z SIEM/SOAR, reguły na podstawie profili ruchu.
Dla producentów i detalistów (odbiorców systemu):
Plany ciągłości działania (BCP) na wypadek niedostępności E-VSD: listy kontrolne wysyłki „warunkowej”, escrow dokumentów, uzgodnione z regulatorami SLA na dosłanie certyfikatów.
Bufory logistyczne dla produktów szybko psujących się; priorytetyzacja tras o mniejszym ryzyku opóźnień.
Monitoring statusu systemów centralnych i kanałów urzędowych (np. oficjalny kanał Telegram) oraz szybkie kanały kontaktu z sieciami handlowymi.
Wewnętrzne proxy/kolejki: w razie L7-DDoS — lokalne buforowanie żądań do czasu przywrócenia przepustowości.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Czerwiec 2025 (Rosja/ Mercury): brak dostępności skutkował przejściem na dokumenty papierowe; formalnie ogłoszono tryb awaryjny. Październikowy incydent miał profil DDoS i spór o realny poziom dostępności (rynek zgłaszał przestoje, urząd deklarował „pracę w normie”).
Logistyka na Zachodzie (ostrzeżenia 2025): akcent na kampanie APT przeciw łańcuchom dostaw i firmom TSL; choć inny kontekst, wnioski o konieczności redundancji i procedur „degraded mode” pozostają spójne.
Podsumowanie / kluczowe wnioski
Atak z 22 października potwierdza, że systemy certyfikacji i śledzenia pochodzenia żywności są celami o wysokiej wartości zakłóceniowej: nawet bez naruszenia danych sam brak dostępności generuje dotkliwe koszty biznesowe i ryzyka regulacyjne. Organizacje utrzymujące podobne rejestry powinny pilnie wdrażać wielowarstwową ochronę DDoS, tryby „graceful degradation” oraz uzgodnione prawnie procedury awaryjne umożliwiające kontynuację obrotu z późniejszym uzupełnieniem dokumentów.
Źródła / bibliografia
The Record (Recorded Future News): raport o ataku i wpływie na wysyłki, 24 października 2025. (The Record from Recorded Future)
Shopper’s (rosyjskie medium branżowe): relacje producentów o wstrzymaniu odgórkek i szczegóły dot. braku trybu awaryjnego, 22 października 2025. (shoppers.media)
RIA Nowosti / komunikaty Rosselkhoznadzoru: informacja o DDoS i braku zagrożeń dla danych; deklaracja „pracy w trybie zwykłym”. (РИА Новости)
ROSNG: zaprzeczenie problemom z Mercury po ataku, 23 października 2025. (rosng.ru)
The Record (czerwiec 2025): wcześniejsze zakłócenia Mercury i skutki dla branży mleczarskiej. (The Record from Recorded Future)
Dlaczego raportowanie incydentów stało się kluczowe w dyrektywie NIS2
Dyrektywa NIS2 (Network and Information Systems Directive 2) wprowadza jednolite wymogi w całej UE dotyczące cyberbezpieczeństwa, w tym obowiązek szybkiego zgłaszania poważnych incydentów bezpieczeństwa. Organizacje uznane za podmioty kluczowe lub istotne (ang. essential and important entities) muszą raportować incydenty o znaczącym wpływie na usługi zgodnie z zasadą 24h/72h.
Badacze ESET opisali nową odsłonę operacji szpiegowskiej Operation DreamJob przypisywanej grupie Lazarus powiązanej z Koreą Północną. Od końca marca 2025 r. atakujący sukcesywnie zaatakowali trzy firmy z branży obronnej w Europie Środkowej i Południowo-Wschodniej, z czego co najmniej dwie są silnie związane z technologiami UAV (drony). Cel: kradzież własności intelektualnej i know-how produkcyjnego. Główne narzędzie na etapie post-exploitation to RAT ScoringMathTea.
Informacje te potwierdzają także serwisy branżowe, które podkreślają związek kampanii z rozwojem programu dronowego w KRLD oraz wykorzystanie fałszywych ofert pracy jako wektora wejścia.
W skrócie
Cel: szpiegostwo przemysłowe dotyczące dronów (UAV), komponentów i oprogramowania.
Ofiary: 3 firmy obronne (metalurgia, producent części lotniczych, firma obronna).
Łańcuch infekcji: trojanizowane projekty OSS (np. MuPDF, wtyczki Notepad++/WinMerge, TightVNC, libpcre, DirectX), DLL sideloading, ładowanie w pamięci (MemoryModule-style).
Payload: ScoringMathTea RAT (~40 komend), C2 na skompromitowanych serwerach (często w katalogach WordPress).
Artefakt: dropppery z wewnętrzną nazwą DroneEXEHijackingLoader.dll (wskazówka na fokus „drone”).
Szerszy obraz: stała, ewolucyjna zmiana bibliotek do DLL proxying i dobór nowych projektów OSS do trojanizacji.
Kontekst / historia / powiązania
Operation DreamJob to długoletnia taktyka Lazarusa oparta na latach udanych kampanii z wabikami rekrutacyjnymi; nakłada się z wcześniej opisywanymi operacjami (np. North Star, DeathNote). Motywacja Lazarusa obejmuje szpiegostwo, sabotaż i zysk finansowy, ale w tej fali dominuje espionage na rzecz rozwoju zdolności wojskowych KRLD (m.in. drony). W artykule ESET wskazano również kontekst wojny Rosja–Ukraina i doniesień o przyspieszeniu programu UAV w KRLD.
Analiza techniczna / szczegóły kampanii
Wektor wejścia i initial access
Kontakt „rekrutera”, dokument z opisem stanowiska i trojanizowany czytnik PDF do jego otwarcia.
Alternatywnie – zachęta do pobrania „przydatnej” wtyczki/oprogramowania OSS z dołączonym loaderem.
Loader decrypts & reflectively loads payload w pamięci (MemoryModule-style).
Dostarczenie ScoringMathTea RAT lub BinMergeLoader (MISTPEN) – ten drugi potrafi nadużywać Microsoft Graph API i tokenów do pozyskiwania dalszych ładunków.
Wzorce DLL sideloading (nieoczekiwane biblioteki przy zaufanych EXE, anomalie w LoadLibrary),
Reflective loader artefakty w pamięci, nietypowe sekcje PE, brak na dysku,
Nienaturalne wywołania Graph API/tokeny z hostów użytkowników.
Network:
Wykrywanie C2 w katalogach WordPress (ścieżki /wp-content/themes/, /plugins/ używane nienormalnie),
Egress deny-by-default + TLS inspection dla ruchu do rzadkich hostów,
Blokada nietypowych TCP beacons z aplikacji biurowych.
EDR/OS hardening:
Windows Defender Application Control / WDAC lub AppLocker do whitelisting’u binarek i DLL,
PreferSecureLibraryLoading / Safe DLL Search Mode i blokady znanych ścieżek sideloadingu,
ASR rules (blokowanie ładowania DLL z katalogów użytkownika/temp). (Dobre praktyki branżowe w kontekście DLL sideloading).
OSS hygiene:
Mirror / hash-pinning dla MuPDF, Notepad++/WinMerge plugins, TightVNC, libpcre itp.; pobrania tylko z verified release z podpisem,
SBOM i skan integralności w CI/CD narzędzi inżynierskich,
Blokada uruchamiania niepodpisanych plug-inów.
Identity & SaaS:
MFA odporne na phishing (FIDO2),
Monitorowanie rzadkich grantów i uprawnień Microsoft Graph oraz tworzenia ukrytych rejestracji aplikacji.
User awareness / proces HR:
Procedura „oddzielne środowisko” do otwierania dokumentów rekrutacyjnych (sandbox/VDI),
Weryfikacja rekruterów (domena, DKIM/DMARC, kontakt przez oficjalny portal),
Zakaz instalacji „czytników” przysłanych przez osoby trzecie.
ESET opublikował IoC (domeny, skróty binarek) do tej fali – włącz je do SIEM/EDR i feedów blokujących.
Różnice / porównania z innymi przypadkami
Konsekwencja zamiast rewolucji: ScoringMathTea od 2022/2023 r. zmienił się nieznacznie – Lazarus stawia na stabilny, wystarczający zestaw funkcji, a polimorfizm przenosi do warstwy dropperów/loaderów.
Nowe biblioteki do proxy’owania DLL i dobór mniej popularnych projektów OSS do trojanizacji zwiększają evasiveness przy zachowaniu tego samego „silnika” C2.
Fokus sektorowy: wcześniejsze DreamJob częściej celowały w krypto/IT; obecnie nacisk na UAV i łańcuch dostaw obronności.
Podsumowanie / kluczowe wnioski
Lazarus nie musi przeprojektowywać narzędzi – wystarczy zmieniać nośniki (OSS, wtyczki) i utrzymywać presję socjotechniczną. Organizacje z sektora obronnego, szczególnie UAV, powinny przenieść kontrolę z samej detekcji plików na TTP-first detection & hardening (DLL sideloading, reflective loading, Graph API abuse) oraz uszczelnić procesy HR.
Źródła / bibliografia
ESET Research – „Gotta fly: Lazarus targets the UAV sector” (23.10.2025). Najpełniejsza analiza techniczna i kontekst. (welivesecurity.com)
ESET Newsroom – komunikat prasowy z kluczowymi tezami i timeline. (ESET)
BleepingComputer – omówienie łańcuchów ataku, OSS i IoC. (BleepingComputer)
CyberScoop – streszczenie z akcentem na motywację i artefakt „DroneEXEHijackingLoader.dll”. (CyberScoop)
Dark Reading – komentarz o stabilności ScoringMathTea i ewolucji DLL proxying. (Dark Reading)
Dlaczego zarządzanie ryzykiem stanowi fundament zgodności z NIS2
Dyrektywa NIS2 (Directive (EU) 2022/2555) nakłada na podmioty z sektorów krytycznych i ważnych obowiązek przyjęcia kompleksowego podejścia do zarządzania ryzykiem cyberbezpieczeństwa. Artykuł 21 tej dyrektywy wymaga wdrożenia adekwatnych i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych w celu zabezpieczenia sieci i systemów informatycznych oraz ograniczenia wpływu incydentów.
