Archiwa: Windows - Strona 29 z 68 - Security Bez Tabu

Tag: Windows

Nowy wariant ClickFix: nslookup i DNS jako kanał dostarczania ładunku PowerShell (ModeloRAT)

Wprowadzenie do problemu / definicja luki

ClickFix to technika socjotechniczna, w której ofiara — „naprawiając problem” (fałszywy błąd, weryfikację CAPTCHA, rzekomą aktualizację) — sama uruchamia polecenia prowadzące do infekcji. Nowość w opisywanej kampanii polega na tym, że kolejne etapy nie są pobierane klasycznym HTTP/HTTPS, lecz… przez DNS, z użyciem wbudowanego narzędzia nslookup.

W skrócie

  • Atakujący nakłaniają użytkownika do uruchomienia komendy w oknie Windows Run.
  • Komenda wykonuje niestandardowe zapytanie DNS do kontrolowanego przez napastnika serwera DNS i parsuje pole „Name:” z odpowiedzi, by uzyskać kolejny ładunek (PowerShell), który jest następnie wykonywany.
  • Łańcuch infekcji prowadzi finalnie do instalacji ModeloRAT (RAT napisany w Pythonie), z mechanizmami rozpoznania i utrzymania się w systemie.

Kontekst / historia / powiązania

ClickFix nie jest „jedną rodziną malware”, tylko powtarzalnym wzorcem nadużycia interakcji użytkownika: ofiara uruchamia polecenie, bo wierzy, że to element weryfikacji lub naprawy. Microsoft i inni dostawcy opisywali już wcześniej ClickFix jako łańcuch, który często kończy się infostealerami, RAT-ami lub loaderami i chętnie korzysta z LOLBins (np. PowerShell) w modelu „fileless”.

Proofpoint pokazywał, że ClickFix szybko rozlał się po ekosystemie zagrożeń (różni aktorzy, różne przynęty, wspólny mechanizm „skopiuj-wklej-uruchom”), a kampanie kończyły się m.in. AsyncRAT, DarkGate, Lumma Stealer czy NetSupport.

Analiza techniczna / szczegóły luki

1) „Dostarczenie” polecenia i uruchomienie nslookup

W opisywanym wariancie użytkownik dostaje instrukcję uruchomienia polecenia w Windows Run. Polecenie uruchamia nslookup tak, aby zapytać konkretny, zewnętrzny serwer DNS (zamiast systemowego resolvera). W materiale wskazano przykład infrastruktury DNS napastnika (adres IP serwera DNS) oraz mechanikę: odpowiedź DNS jest „spreparowana” tak, by zawierała kolejny etap w polu NAME:.

2) DNS jako „lekki staging”

Kluczowe jest to, że DNS służy tu jako kanał etapowania: ofiara najpierw wykonuje zapytanie DNS, a dopiero potem system uruchamia PowerShell pozyskany z odpowiedzi. To utrudnia pracę obronie opartej wyłącznie o filtrowanie web/URL i proxy HTTP.

3) Kolejne etapy: ZIP → Python → VBS → ModeloRAT

W dalszej części łańcucha (wg opisu bazującego na obserwacjach Microsoft) następuje pobranie archiwum ZIP z zewnętrznej infrastruktury, uruchomienie skryptu w Pythonie (rekonesans, discovery), a następnie zrzut/uruchomienie VBScript i finalnie ModeloRAT zapewniający zdalną kontrolę.

4) Co tu jest sprytne z perspektywy detekcji?

DNS zwykle jest dozwolony w egress, a nslookup.exe to narzędzie administracyjne. To tworzy „szarą strefę” — aktywność może wyglądać jak troubleshooting, dopóki nie spojrzymy na kontekst procesu (np. cmd.exe/Run → nslookup.exe → uruchomienie poleceń/PowerShell) i cechy zapytań (nietypowy serwer, nietypowe typy odpowiedzi, podejrzane payloady w danych odpowiedzi).

Praktyczne konsekwencje / ryzyko

  • Zwiększona szansa obejścia kontroli webowych: jeśli organizacja mocno filtruje HTTP/HTTPS, a DNS traktuje „po macoszemu”, kanał DNS może stać się skutecznym stagingiem.
  • RAT w sieci = ryzyko pełnej kompromitacji: ModeloRAT jako narzędzie zdalnego dostępu może posłużyć do kradzieży danych, rozpoznania, ruchu bocznego i dalszego dropowania ładunków.
  • Trudniejsze dochodzenie: część „pobrania” dzieje się w DNS, więc bez logów DNS (i korelacji z endpointem) analiza incydentu jest istotnie utrudniona.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  1. Wymuś DNS tylko przez zaufane resolvery
    • Blokuj bezpośredni DNS (UDP/TCP 53) do Internetu z sieci użytkowników, jeśli możesz; pozwól tylko na DNS do twoich resolverów / zabezpieczonego forwardera.
  2. Wykrywanie nslookup z parametrem serwera / nietypowym wzorcem użycia
    • Alarmuj na nslookup.exe wywołany przez cmd.exe/explorer.exe w kontekście Run + szybkie następstwo uruchomienia PowerShell.
    • Skorzystaj z gotowych reguł detekcji pod nadużycia DNS/nslookup (np. podejrzanie częste wywołania).
  3. Zbieraj i koreluj logi DNS + EDR
    • Bez telemetrii DNS możesz nie zobaczyć kluczowego elementu stagingu.

Wzmocnienie średnioterminowe (1–4 tygodnie)

  1. Ogranicz PowerShell tam, gdzie się da
    • Constrained Language Mode / polityki aplikacyjne (AppLocker/WDAC), ASR rules, wzmacnianie AMSI/Defender w środowiskach Windows — ClickFix często kończy się PowerShellem.
  2. Szkolenia i „bezpieczniki” UX
    • W ClickFix „security boundary” jest użytkownik. Ucz: „nie uruchamiam poleceń z okienek ‘naprawczych’, CAPTCHA i pseudo-aktualizacji”.

Różnice / porównania z innymi przypadkami

  • Klasyczne ClickFix: często kończy się poleceniem PowerShell, które pobiera payload po HTTP/HTTPS.
  • Ten wariant: DNS jest użyty jako kanał etapowania/„sygnalizacji” — a nslookup staje się narzędziem do pobrania kolejnego polecenia z odpowiedzi DNS. To zmienia priorytety obrony: same kontrole webowe nie wystarczą, jeśli DNS nie jest monitorowany i ograniczany.

Podsumowanie / kluczowe wnioski

  • ClickFix dalej ewoluuje: teraz nie tylko „uruchom PowerShell”, ale też „uruchom nslookup na zewnętrzny DNS i wykonaj to, co wróci”.
  • DNS jako staging jest groźny, bo zwykle jest dozwolony i słabiej inspekcjonowany.
  • Obrona wymaga połączenia: kontrola egress DNS + telemetria DNS + EDR na endpointach + edukacja użytkowników.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii DNS/nslookup i mechaniki „Name:” → PowerShell (BleepingComputer)
  2. Malwarebytes – omówienie łańcucha ZIP → Python → VBS → ModeloRAT (Malwarebytes)
  3. Microsoft Security Blog – tło i typowy łańcuch ClickFix (microsoft.com)
  4. Proofpoint – szerszy kontekst rozprzestrzenienia ClickFix i typowe przynęty/payloady (Proofpoint)
  5. Elastic – referencje i podejście detekcyjne dla nadużyć DNS/nslookup (Elastic)

Fałszywi rekruterzy ukrywają malware w „zadaniach rekrutacyjnych” dla programistów

Wprowadzenie do problemu / definicja luki

„Zadanie rekrutacyjne” w formie repozytorium na GitHubie, prośba o uruchomienie projektu i szybka weryfikacja umiejętności — to normalny element procesu hiringowego w IT. W 2025–2026 ten sam schemat stał się jednak skutecznym wektorem infekcji: podszywający się pod rekruterów napastnicy dostarczają projekt, który wygląda jak uczciwy challenge, ale zawiera złośliwą zależność (npm lub PyPI) pełniącą rolę downladera/loadera dla kolejnych etapów malware.

W opisywanym wariancie badacze powiązali aktywność z północnokoreańskimi aktorami (często klasyfikowanymi jako Lazarus/DPRK), a kampanię nazwano Graphalgo.

W skrócie

  • Ofiary: przede wszystkim programiści JavaScript i Python, zwłaszcza pracujący przy tematach krypto/blockchain.
  • Wektor: repozytoria z „coding challenge”, gdzie ukryto złośliwe zależności hostowane na npm i PyPI.
  • Skala: w samym klastrze Graphalgo zidentyfikowano 192 złośliwe paczki powiązane z kampanią.
  • Cel: zdalny dostęp (RAT) i monetyzacja — w praktyce kradzież danych/kluczy/portfeli oraz przejęcia kont (w zależności od wariantu).
  • Cecha wyróżniająca: modułowość i „warstwowanie” infrastruktury na publicznych serwisach (GitHub, rejestry paczek), co utrudnia szybkie wygaszenie kampanii.

Kontekst / historia / powiązania

To nie jest jednorazowa akcja, tylko kolejna iteracja dłuższej serii kampanii, w których proces rekrutacyjny staje się socjotechnicznym „pretekstem” do instalacji malware.

  • Contagious Interview (MITRE: G1052) to DPRK-aligned grupa aktywna od 2023 r., łącząca motywy finansowe (m.in. krypto) i szpiegowskie, z silnym fokusowaniem na osoby związane z developmentem.
  • Unit 42 opisywał, że w ramach Contagious Interview pojawiały się m.in. rodziny BeaverTail (JS w paczkach npm) i InvisibleFerret (pythonowy backdoor), działające cross-platform (Windows/Linux/macOS) i nastawione na kradzież danych oraz dalsze etapowanie infekcji.
  • ESET w 2025 r. wiązał aktywność „DeceptiveDevelopment / Contagious Interview” z kradzieżą kryptowalut i zaawansowaną socjotechniką (fałszywe oferty pracy, elementy ClickFix), wskazując na ewolucję narzędzi i profesjonalizację operacji.

Graphalgo wpisuje się w ten trend, ale wykorzystuje bardzo „developerski” łańcuch zaufania: repozytorium + zależność z publicznego rejestru + uruchomienie lokalnie.

Analiza techniczna / szczegóły luki

1. Łańcuch ataku (high-level)

W badaniach ReversingLabs łańcuch opisano jako wieloetapowy i oparty o publiczne usługi:

  1. Kontakt socjotechniczny (LinkedIn/Facebook, czasem inne kanały) i narracja o firmie związanej z krypto/blockchain.
  2. „Coding challenge” jako repozytorium (np. w organizacji podszywającej się pod firmę).
  3. W projekcie znajduje się „normalnie wyglądająca” zależność, ale prowadząca do złośliwych paczek na npm/PyPI, które działają jako downloadery/loader.
  4. Kolejne etapy pobierają finalny payload — RAT — w różnych wariantach językowych (Python/JavaScript/VBS).

2. „Warstwowanie” i utrudnianie detekcji

W praktyce najgroźniejsze nie jest jedno repozytorium, tylko sposób ukrycia złośliwości:

  • zależność wygląda jak standardowy element projektu,
  • payload bywa pobierany dopiero w runtime,
  • elementy są rozrzucone między GitHub a rejestry paczek (npm/PyPI) i dodatkową infrastrukturę.

3. Skala i artefakty

  • BleepingComputer (na podstawie ustaleń badaczy) podaje 192 paczki powiązane z Graphalgo, działające jako downloadery dla RAT.
  • ReversingLabs opisuje kampanię jako aktywną co najmniej od początku maja 2025 r. oraz wskazuje na modułowość, która pozwala napastnikom szybko odtwarzać infrastrukturę po częściowych „takedownach”.

Praktyczne konsekwencje / ryzyko

Dla programisty (endpoint)

  • trwały zdalny dostęp (RAT),
  • kradzież poświadczeń, tokenów, sesji,
  • ryzyko przejęcia kont deweloperskich (GitHub, npm, PyPI, CI/CD), a dalej ataków typu supply chain.

Dla firmy

Największym problemem jest „przeniesienie” infekcji z prywatnego kontekstu rekrutacyjnego na zasoby pracodawcy:

  • stacje dev często mają dostęp do repozytoriów, artefaktów, sekretów (SSH keys, API keys, env vars),
  • dostęp do pipeline’ów i rejestrów może umożliwić wstrzyknięcie złośliwego kodu do produktów.

Dodatkowo, część klastrów DPRK skupia się na kryptowalutach i aktywach: Unit 42 opisywał BeaverTail jako infostealera m.in. pod kątem portfeli krypto i danych płatniczych.

Rekomendacje operacyjne / co zrobić teraz

1. Zasady „bezpiecznej rekrutacji” dla devów

  • Nigdy nie uruchamiaj zadania rekrutacyjnego na maszynie firmowej ani na hoście z dostępem do VPN/SSO/sekretów.
  • Używaj izolacji: osobny laptop, VM, kontener lub „throwaway” środowisko (bez tokenów, bez kluczy).
  • Weryfikuj źródło zadania: domena firmy, obecność realnych osób, spójne ślady (kontakt, NIP/REGON, profile) — Graphalgo bazuje na „firmach-wydmuszkach”.

2. Kontrola zależności (npm/PyPI) i supply chain

  • Włącz polityki typu allowlist dla rejestrów i nazw paczek (tam, gdzie możliwe).
  • Skanuj zależności SCA i analizą behawioralną (install scripts, postinstall, nietypowe fetch’e).
  • Ustal wewnętrzny proces: każde nowe dependency w zadaniu „z zewnątrz” traktuj jak kod nieufny.

3. Detekcja i IR (dla SOC/Blue Team)

  • Monitoruj nietypowe połączenia wychodzące z hostów dev (zwłaszcza tuż po instalacji paczek i buildzie).
  • Zbieraj telemetrię dla procesów uruchamianych przez narzędzia dev (node/python) i ich child-processów.
  • Przeszkol HR i tech leadów: „coding challenge” to dziś pełnoprawny wektor ataku, nie „tylko plik z zadaniem”.

Różnice / porównania z innymi przypadkami

  • Graphalgo (ReversingLabs/BleepingComputer) mocno eksponuje modułowość i „klockowanie” kampanii z wielu publicznych usług oraz duży wolumen paczek w rejestrach.
  • Wcześniejsze klastry (np. opisywane przez Unit 42) pokazywały bardziej „nazwane” rodziny i rolę infostealer → loader → backdoor (BeaverTail → InvisibleFerret). To podobna filozofia etapowania, ale różne implementacje i branding analityczny.
  • MITRE klasyfikuje Contagious Interview jako grupę ukierunkowaną na developerów i krypto, co spina te historie w powtarzalny wzorzec TTP.

Podsumowanie / kluczowe wnioski

Graphalgo to kolejny dowód, że workflow programistyczny (repozytoria + zależności + szybkie uruchomienie) jest dziś atrakcyjniejszym celem niż klasyczne phishingowe „kliknij w link”. Kampania wygrywa nie „0-dayami”, tylko psychologią (marzenie o lepszej pracy) i inżynierią zaufania (GitHub/npm/PyPI).

Jeśli w Twojej organizacji pracują devowie, którzy rekrutują się aktywnie (albo dorabiają jako freelancerzy), potraktuj to jak realne ryzyko biznesowe: minimalna izolacja środowiska i higiena zależności potrafią zablokować większość tego typu ataków.

Źródła / bibliografia

  1. BleepingComputer — „Fake job recruiters hide malware in developer coding challenges” (13 lutego 2026). (BleepingComputer)
  2. ReversingLabs — „Fake recruiter campaign targets crypto developers with RAT” (szczegóły kampanii Graphalgo, od maja 2025). (ReversingLabs)
  3. Unit 42 (Palo Alto Networks) — „Two Job-Related Campaigns Bear Hallmarks of North Korean Threat Actors” (Contagious Interview, BeaverTail, InvisibleFerret). (Unit 42)
  4. ESET — „Deep dive into DeceptiveDevelopment / Contagious Interview” (25 września 2025). (ESET)
  5. MITRE ATT&CK — Group G1052: Contagious Interview. (attack.mitre.org)

UAT-9921 i VoidLink: „cloud-native” malware w Zig, które celuje w Linuxa i środowiska chmurowe

Wprowadzenie do problemu / definicja luki

VoidLink to rozbudowany, modułowy framework implantów i C2 ukierunkowany na systemy Linux — ze szczególnym naciskiem na nowoczesną infrastrukturę (chmura, Kubernetes, Docker). W kampaniach zaobserwowanych przez Cisco Talos narzędzie jest używane przez nowo nazwany klaster aktywności UAT-9921, który po uzyskaniu dostępu instaluje elementy C2 na przejętych hostach i wykorzystuje je m.in. do skanowania oraz rekonesansu wewnątrz i na zewnątrz sieci.

W praktyce nie mówimy o „pojedynczym backdoorze”, tylko o ekosystemie: implant + system pluginów + mechanizmy ukrywania (w tym kernel-level) + zaplecze zarządzania, które przypomina komercyjne platformy red-teamowe, ale jest obserwowane w realnych włamaniach.

W skrócie

  • Aktor: UAT-9921 (Talos: aktywność co najmniej od 2019 r.).
  • Cele: przede wszystkim technologia, ale też finanse; zachowanie wskazuje na skanowanie i oportunizm (np. całe sieci klasy C).
  • Initial access (Talos): pre-pozyskane poświadczenia lub RCE przez Java serialization, m.in. w kontekście Apache Dubbo; sygnały o możliwym użyciu złośliwych dokumentów, ale bez próbek.
  • Post-compromise: implant VoidLink + SOCKS proxy + narzędzie FSCAN do rekonesansu i ruchu bocznego.
  • Technologia: Zig (implant), C (pluginy), Go (backend); kompilacja pluginów „na żądanie” pod różne dystrybucje Linuksa.
  • Chmura/kontenery: rozpoznawanie dostawców chmury, pobieranie poświadczeń (m.in. z env/config/metadata), scenariusze eskalacji w Kubernetes i ucieczki z kontenerów.
  • Stealth: rootkitowe mechanizmy (m.in. LD_PRELOAD/LKM/eBPF), adaptacja do środowiska i wykrytych zabezpieczeń.
  • C2: Ontinue opisuje AES-256-GCM po HTTPS, maskowane jako zwykły ruch web; zbieżności „w stylu” beaconów znanych z Cobalt Strike.
  • Zarządzanie: RBAC (SuperAdmin/Operator/Viewer), audytowalność akcji — nietypowe dla czysto „przestępczych” frameworków.

Kontekst / historia / powiązania

VoidLink został szeroko opisany wcześniej przez Check Point Research jako „cloud-first” framework malware dla Linuksa, rozwijany dynamicznie i wyposażony w bogaty zestaw funkcji (od user-mode po kernel-level), z elementami sugerującymi chińskojęzyczne środowisko wytwórcze (bez jednoznacznego przypisania afiliacji).

Kluczowe jest to, że obrazy sytuacji różnią się w czasie:

  • Check Point podkreślał, że w momencie publikacji nie widział dowodów realnych infekcji (bardziej „widać rozwój narzędzia” niż kampanię).
  • Talos raportuje natomiast ofiary powiązane z VoidLink od okolic września (aktywność do stycznia 2026) i wskazuje na konkretne TTP UAT-9921 w intruzjach.

W tle pojawia się jeszcze jeden trend: przyspieszenie cyklu tworzenia implantów. Talos wiąże rozwój VoidLink z użyciem AI-wspomaganego środowiska wytwórczego i ostrzega, że „kompilacja na żądanie” to fundament pod coraz bardziej automatyzowane (a w przyszłości także autonomiczne) łańcuchy ataku.

Analiza techniczna / szczegóły luki

1) Łańcuch ataku (w ujęciu Talos)

  1. Wejście: użycie pozyskanych wcześniej poświadczeń lub eksploatacja podatności typu Java serialization prowadzącej do RCE (Talos wskazuje m.in. Apache Dubbo).
  2. Utrwalenie i ukrycie: wdrożenie implantu VoidLink na przejętym serwerze.
  3. Rekonesans / lateral movement: uruchomienie SOCKS na skompromitowanych hostach i wykorzystanie FSCAN do rekonesansu wewnętrznego.
  4. Skalowanie: skanowanie zasobów także „na zewnątrz” (Talos wspomina o skanowaniu całych sieci klasy C), co sugeruje bardziej szerokie poszukiwanie okazji niż ręcznie dobierane cele.

2) Architektura: implant + pluginy + backend

VoidLink jest zbudowany jak platforma:

  • Zig jako język implantu,
  • C jako język pluginów,
  • Go jako backend,
  • oraz mechanizm kompilacji pluginów na żądanie, co ułatwia dopasowanie do dystrybucji/środowiska ofiary (i utrudnia obronę sygnaturową).

Check Point dodaje, że framework ma plugin system in-memory i obsługuje różne kanały C2 (w tym bardziej „nietypowe” jak ICMP czy DNS tunneling, obok HTTP/HTTPS).

3) Chmura i DevOps jako „naturalne” środowisko działania

Ontinue opisuje implant jako nastawiony na:

  • fingerprinting środowisk AWS/GCP/Azure/Alibaba/Tencent,
  • pozyskiwanie poświadczeń z env/config oraz API metadanych instancji,
  • wykrywanie runtime kontenerów,
  • oraz posiadanie pluginów pod container escape i eskalację w Kubernetes.

To spina się z obserwacjami Check Point, że VoidLink potrafi rozpoznać, czy działa w Kubernetes/Docker i dostosować zachowanie.

4) Stealth i komponent „rootkitowy”

Check Point wskazuje na wachlarz mechanizmów OPSEC i ukrywania: m.in. szyfrowanie kodu w runtime, reakcje na manipulację/tampering oraz rootkitowe podejście (LD_PRELOAD, LKM, eBPF).

Talos dodaje warstwę praktyczną: wykrywanie rozwiązań EDR i dobór strategii uniku, a także funkcje typu eBPF/LKM oraz scenariusze eskalacji/ucieczki z sandboxa.

5) C2, kryptografia i „pozory normalności”

Ontinue opisuje AES-256-GCM po HTTPS, maskowane tak, by wyglądało jak normalny ruch web. Wskazuje też podobieństwa wzorców komunikacji do architektury beaconów znanych z Cobalt Strike.

6) Zarządzanie kampanią: RBAC, audyt i „defense-contractor grade”

Jedna z najbardziej nietypowych cech VoidLink (w porównaniu do wielu narzędzi stricte przestępczych) to:

  • audytowalność akcji
  • i RBAC z rolami SuperAdmin / Operator / Viewer.

Talos zaznacza wprost, że to może pasować do środowisk, gdzie potrzebny jest nadzór prawny/korporacyjny — oraz że z tego powodu nie da się całkowicie wykluczyć scenariusza „red team”, mimo iż w obserwowanych działaniach pojawiają się też exploity i użycie cudzych poświadczeń.

7) Wątek Windows i DLL side-loading

Talos widzi przesłanki, że istnieje także implant dla Windows, ładujący pluginy przez DLL side-loading (bez pozyskanego próbki do pełnego potwierdzenia).
W terminologii MITRE ATT&CK jest to jedna z odmian Hijack Execution Flow (DLL Sideloading).

Praktyczne konsekwencje / ryzyko

Dlaczego to jest istotne operacyjnie (a nie tylko „kolejny malware”)?

  • Cloud-native post-exploitation: jeśli implant realnie umie „czytać” chmurę, kontenery i API dostawców, to kompromitacja pojedynczego hosta może szybciej przełożyć się na dostęp do sekretów, repozytoriów i tożsamości workloadów.
  • Stealth na poziomie kernela + adaptacja do EDR: rośnie ryzyko długiej obecności (dwell time), a klasyczne artefakty user-mode mogą w ogóle się nie pojawić albo być niewiarygodne.
  • „Kompilacja na żądanie”: obrona oparta wyłącznie na statycznych sygnaturach/IOC ma krótszą „przydatność”, bo funkcje mogą być dogrywane w locie, pod konkretną ofiarę.
  • Skalowanie przez skanowanie i proxy: obserwowane SOCKS+FSCAN oraz skanowanie sieci klasy C zwiększa ryzyko „rozlania się” incydentu na kolejne segmenty i usługi.

Rekomendacje operacyjne / co zrobić teraz

1) Ogranicz wektory wejścia

  • Zweryfikuj ekspozycję usług JVM/Java, a szczególnie komponentów, gdzie realnie występuje ryzyko Java serialization → RCE (Talos wskazuje Apache Dubbo jako przykład kontekstu).
  • Wymuś MFA, ogranicz logowanie administracyjne z Internetu, zredukuj „credential sprawl”, rotuj hasła/tokeny w systemach, gdzie podejrzewasz wyciek.

2) Utwardź chmurę i kontenery „pod kradzież sekretów”

  • Ogranicz dostęp do instance metadata (tam gdzie to możliwe), stosuj polityki minimalnych uprawnień dla ról/identity workloadów.
  • Przejrzyj miejsca, z których zwykle „wyciekają” sekrety: zmienne środowiskowe, pliki konfiguracyjne, katalogi narzędzi CI/CD, integracje Git/registry.

(Uzasadnienie: Ontinue opisuje pozyskiwanie poświadczeń właśnie z env/config/metadata i scenariusze ataku na kontenery/Kubernetes.)

3) Poluj na TTP po kompromitacji

  • Monitoruj anomalie: SOCKS proxy na serwerach aplikacyjnych, skanowanie portów i ruch narzędzi typu FSCAN.
  • Wdróż sensowne egress filtering (zwłaszcza z workloadów, które „nie powinny” rozmawiać z Internetem) oraz alerty na nietypowe beacony HTTPS.

4) Detekcja na hostach Linux: kernel, eBPF, LKM

  • Zwiększ telemetrię wokół ładowania modułów jądra (LKM) i nietypowych aktywności eBPF; szukaj sygnałów „rootkitowych” oraz zachowań anty-analizowych.
  • Tam, gdzie to realne: ogranicz możliwość ładowania niepodpisanych modułów, rozważ twardsze profile (np. lockdown mode, odpowiednie polityki w środowiskach produkcyjnych).

5) Jeśli masz komponenty Windows: kontroluj DLL side-loading

  • W audytach aplikacji i EDR uwzględnij scenariusze DLL side-loading (MITRE: DLL Sideloading), szczególnie przy binarkach uruchamianych z katalogów, gdzie atakujący może dopisać pliki.

6) Wykorzystaj sygnatury i coverage od dostawców

Talos podaje konkretne elementy coverage (m.in. zakresy reguł Snort oraz sygnaturę ClamAV dla VoidLink). Jeśli korzystasz z tych technologii lub integracji Cisco, to szybki „health check” pokrycia ma sens.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W porównaniu do klasycznych frameworków C2 używanych powszechnie w kampaniach (np. „rodziny” podejścia Cobalt-Strike-like), VoidLink wyróżnia się kilkoma rzeczami:

  • Linux-first i cloud-first zamiast „Windows jako domyślny target”.
  • Kompilacja pluginów na żądanie (bardziej dynamiczny dobór funkcji pod ofiarę).
  • RBAC + audytowalność, co wygląda jak projektowanie z myślą o „nadzorze” i procesie.
  • Głębokie mechanizmy stealth (kernel/eBPF/LKM/LD_PRELOAD) oraz adaptacja do narzędzi obronnych.

Podsumowanie / kluczowe wnioski

UAT-9921 to nowo nazwany klaster, który — według Talos — używa VoidLink jako platformy post-exploitation do ukrywania się, skanowania i poruszania po sieciach ofiar, zwłaszcza w kontekście Linuksa i środowisk chmurowych.

VoidLink jest istotny nie tylko przez „feature listę”, ale przez kierunek: cloud-native, modularnie rozbudowywany implant z elementami kernel-stealth i automatyzacją wytwarzania, który może skracać czas od kompromitacji do skutecznego ruchu bocznego i eksfiltracji.

Źródła / bibliografia

  1. Cisco Talos: New threat actor, UAT-9921, leverages VoidLink framework in campaigns (Cisco Talos Blog)
  2. Check Point Research: VoidLink – The Cloud-Native Malware Framework (Check Point Research)
  3. Ontinue: VoidLink: Dissecting an AI-Generated C2 Implant (Ontinue)
  4. MITRE ATT&CK: Hijack Execution Flow: DLL (DLL Sideloading) (attack.mitre.org)
  5. The Hacker News: UAT-9921 Deploys VoidLink Malware to Target Technology and Financial Sectors (The Hacker News)

Claude „Artifacts” nadużywane do dystrybucji macOS infostealerów w ataku ClickFix

Wprowadzenie do problemu / definicja luki

Atakujący zaczęli wykorzystywać publicznie udostępniane „Artifacts” w Claude (Anthropic) jako element łańcucha infekcji w kampaniach ClickFix, kierując ofiary (macOS) do uruchomienia poleceń w Terminalu. To nie jest „luka” typu CVE w samym Claude, tylko nadużycie funkcji publikowania treści i wysokiej wiarygodności, jaką użytkownicy przypisują materiałom „wyglądającym na wygenerowane przez AI / poradnik”.

W skrócie

  • Kampania jest promowana m.in. przez reklamy Google i pozycjonowanie pod konkretne zapytania (np. narzędzia sieciowe lub macOS CLI).
  • Użytkownik trafia na publiczny Artifact Claude lub stronę podszywającą się pod Apple Support (np. artykuł na platformie blogowej), gdzie dostaje instrukcję wklejenia komendy do Terminala.
  • Wykonanie polecenia pobiera i uruchamia loader, który finalnie instaluje infostealera (w opisywanym przypadku: MacSync).
  • Skala: badacze raportują dziesiątki tysięcy wyświetleń złośliwych instrukcji (wskaźnik ekspozycji, niekoniecznie liczba skutecznych infekcji).

Kontekst / historia / powiązania

ClickFix to technika socjotechniczna, w której kluczowym „bypassem” jest wciągnięcie użytkownika w wykonanie komendy samodzielnie (np. Run/PowerShell na Windows albo Terminal na macOS). Z perspektywy obrony to istotne, bo część kontroli bezpieczeństwa widzi aktywność jako inicjowaną przez użytkownika, a nie klasyczny dropper.

W 2025–2026 obserwowano rozwój ClickFix w różnych wariantach: od prostych fałszywych CAPTCHA po bardziej wyrafinowane łańcuchy, np. z użyciem zaufanych komponentów systemu (LotL) na Windows.
Jednocześnie ekosystem macOS infostealerów rośnie — popularne rodziny (Atomic/AMOS, Poseidon, Cthulhu) są często dystrybuowane przez malvertising i „trojanizowane instalatory”, co dobrze pasuje do mechaniki ClickFix (reklama → landing → instrukcja → uruchomienie).

Analiza techniczna / szczegóły ataku

1) Wejście: reklamy i SEO pod „techniczne” zapytania

Badacze opisali scenariusz, w którym użytkownik szuka narzędzi lub porad dla macOS (np. resolver DNS, analizator miejsca na dysku, Homebrew), a w wynikach pojawia się promowany link prowadzący do:

  • publicznego Artifact Claude, albo
  • strony udającej wsparcie Apple.

2) Rdzeń ClickFix: komenda „naprawcza”

W obu wariantach użytkownik jest zachęcany do uruchomienia w Terminalu polecenia, którego efekt jest typowy dla downloaderów:

  • dekodowanie zakodowanej treści i wykonanie w powłoce (np. schemat „base64 → shell”), lub
  • pobranie treści przez narzędzie sieciowe i bezpośrednie przekazanie do interpretera (np. „curl → shell”).

Nie przytaczam pełnych komend 1:1, bo są to instrukcje wykonawcze dla złośliwego łańcucha — ale ważne jest, że oba wzorce są klasycznymi „red flagami” w środowiskach macOS/Unix.

3) Payload: MacSync infostealer i AppleScript jako „silnik kradzieży”

Po uruchomieniu, łańcuch pobiera loader dla MacSync. Według opisu kampanii:

  • komunikacja z C2 ma być realizowana z użyciem osadzonych tokenów/kluczy oraz z podszywaniem się user-agentem przeglądarki,
  • a właściwe kradzieże danych mają być realizowane przez osascript (AppleScript), obejmując m.in. keychain, dane przeglądarek i portfele krypto,
  • dane są pakowane do archiwum w /tmp/…zip, a następnie wysyłane do C2 metodą HTTP POST, z mechanizmem retry i „sprzątaniem” po udanej eksfiltracji.

4) Wspólna infrastruktura

Badacze wskazują, że oba warianty pobierają drugi etap z tego samego adresu C2, co sugeruje jednego operatora/kampanię (lub przynajmniej współdzieloną infrastrukturę).

Praktyczne konsekwencje / ryzyko

  1. Ryzyko kradzieży tożsamości i przejęć kont – infostealery celują w hasła/cookies/sesje przeglądarkowe, dane w pęku kluczy, komunikatory i portfele.
  2. Ryzyko wtórnej eskalacji – skradzione sesje (SSO/VPN), tokeny i klucze API często stają się wejściem do sieci firmowej lub chmury. (To wprost wynika z typowych następstw incydentów infostealerowych; sama kampania opisuje komponent C2 i eksfiltrację danych).
  3. Nowy „wektor wiarygodności” – publiczne treści hostowane na rozpoznawalnej domenie usługi AI mogą wyglądać „bezpieczniej” niż przypadkowy landing, a jednocześnie zawierają gotowe instrukcje do samodzielnego uruchomienia.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i helpdesku (macOS)

  • Zasada zero-trustu dla komend: nie uruchamiaj w Terminalu poleceń z reklamy/wyników wyszukiwania/poradnika, jeśli nie rozumiesz dokładnie każdego fragmentu (zwłaszcza wzorców „pobierz i wykonaj”, „base64 → shell”).
  • Weryfikuj źródło narzędzi: Homebrew i narzędzia systemowe pobieraj z oficjalnych stron/projektów, nie z „poradników” z reklam.
  • W razie podejrzenia wykonania komendy: odłącz urządzenie od sieci, zabezpiecz logi (Unified Logs), sprawdź nietypowe procesy/uruchomienia osascript, przeanalizuj ruch wychodzący i rozważ reset tokenów/sesji oraz zmianę haseł na czystym urządzeniu.

Dla SOC/Blue Team

  • Detekcja zachowań: reguły/alerty na nietypowe uruchomienia osascript w kontekście pobierania treści z sieci i dostępu do artefaktów przeglądarek/keychain.
  • Kontrola egress: monitorowanie POST/egress do świeżych domen, korelacja z procesami powłoki i osascript.
  • Higiena reklam i wyszukiwania: w środowiskach firmowych ogranicz/filtruj malvertising, rozważ polityki przeglądarkowe i DNS security. (To spójne z obserwacją, że kampania startuje z wyników Google i reklam).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • ClickFix na Windows vs macOS: na Windows coraz częściej pojawiają się warianty „living-off-the-land”, gdzie wykonanie jest proxy’owane przez zaufany komponent (np. skrypty/komponenty Microsoft), aby ominąć proste detekcje „PowerShell.exe”. Na macOS nacisk bywa kładziony na shell + AppleScript (osascript) jako warstwę kradzieży.
  • Rola malvertising: Unit 42 zwraca uwagę, że macOS infostealery są często dystrybuowane przez reklamy i fałszywe instalatory — tutaj malvertising jest połączony z „poradnikiem” w Artifact, co zwiększa perswazyjność.
  • „Hosted trust”: to kolejny przykład, że atakujący testują różne platformy (AI, blogi, serwisy udostępniania treści) jako „nośniki” instrukcji ClickFix, bo łatwo skalują zasięg i utrudniają blokowanie.

Podsumowanie / kluczowe wnioski

  • To kampania ClickFix, w której „payloadem” jest instrukcja — a nie exploit: użytkownik sam uruchamia łańcuch w Terminalu.
  • „Claude Artifacts” działają tu jako wiarygodnie wyglądający hosting treści (publiczny link na domenie usługi AI), wzmacniany przez reklamy i SEO.
  • Na macOS w centrum technicznym stoi kombinacja shell → pobranie loadera → osascript do kradzieży danych i eksfiltracji do C2.
  • Obrona powinna łączyć edukację (nie uruchamiaj niezweryfikowanych komend), kontrolę reklam/wyszukiwania oraz detekcję zachowań osascript/shell + egress.

Źródła / bibliografia

  1. BleepingComputer — opis kampanii: Claude Artifacts + Google Ads → ClickFix → MacSync infostealer (13 lutego 2026). (BleepingComputer)
  2. Microsoft Security Blog — analiza techniki ClickFix i jej łańcucha ataku (21 sierpnia 2025). (Microsoft)
  3. Unit 42 (Palo Alto Networks) — przegląd rosnącego zagrożenia macOS infostealerami i typowych TTP (4 lutego 2025). (Unit 42)
  4. InfoQ — kontekst funkcji Claude Artifacts i ich roli jako przestrzeni do udostępniania/organizacji „wytworów” AI (30 czerwca 2025). (InfoQ)
  5. The Hacker News — przykład ewolucji ClickFix (fałszywe CAPTCHA + zaufane komponenty Windows/App-V) (27 stycznia 2026). (The Hacker News)

Google Chrome: aktualizacja Stable (12 lutego 2026) – co oznacza skok do 145.0.7632.68 i dlaczego warto dopiąć rollout

Wprowadzenie do problemu / definicja luki

Przeglądarka to dziś „runtime” dla aplikacji webowych, a więc realna powierzchnia ataku – szczególnie gdy w grę wchodzą błędy pamięci (use-after-free, buffer overflow, type confusion) w komponentach renderujących, multimedialnych czy akcelerowanych GPU. Dlatego nawet pozornie „rutynowe” aktualizacje Stable Chrome mają znaczenie operacyjne: zamykają wektory prowadzące do RCE, eskalacji uprawnień w sandboxie lub obejść polityk bezpieczeństwa.

12 lutego 2026 Google wypuściło kolejną aktualizację kanału Stable dla desktopów: 145.0.7632.68 (Windows/Mac) oraz 144.0.7559.67 (Linux). Aktualizacja ma być rolowana stopniowo w kolejnych dniach/tygodniach.

W skrócie

  • Nowe wersje Stable: 145.0.7632.68 dla Windows/Mac oraz 144.0.7559.67 dla Linux.
  • To kolejny krok w rollout po wydaniu z 10 lutego 2026, w którym Chrome 145 trafiło na Stable i zawierało 11 poprawek bezpieczeństwa (w tym luki o randze High).
  • W praktyce taki „mały bump” (np. z .45/.46 do .68) bywa wykorzystywany do stabilizacji, poprawek regresji lub dopięcia rollout, ale organizacyjnie warto traktować go jako element łańcucha aktualizacji bezpieczeństwa.

Kontekst / historia / powiązania

Dwa dni wcześniej, 10 lutego 2026, Google ogłosiło promocję Chrome 145 do Stable dla Windows/Mac/Linux i wskazało, że wydanie zawiera 11 security fixes (z listą CVE i komponentów).

Co ważne dla zespołów IT/SOC: ekosystem Chrome ma też równoległe zmiany „enterprise’owe” i bezpieczeństwa platformy (np. mechanizmy ograniczające kradzież sesji czy zmiany w WebGPU w określonych trybach ochrony). W release notes dla środowisk zarządzanych widać m.in. wątki dotyczące bezpieczeństwa sesji i twardnienia przeglądarki w Chrome 145.

Analiza techniczna / szczegóły luki

Sam wpis z 12 lutego 2026 nie wymienia wprost CVE ani listy poprawek bezpieczeństwa – podaje tylko numery buildów i odsyła do changeloga.
Jednak patrząc na kontekst z 10 lutego, wiemy, że gałąź 145 w Stable obejmuje szereg napraw klasycznych podatności przeglądarkowych, m.in.:

  • Use-after-free w CSS (High)
  • Heap buffer overflow w Codecs (High)
  • Błędna implementacja w WebGPU (High)
    oraz inne luki Medium/Low w obszarach takich jak Frames, DevTools, File input czy Downloads.

Żeby pokazać „typ” ryzyka na konkretnym przykładzie z tej serii: CVE-2026-2315 (WebGPU, High) została opisana jako błąd implementacyjny umożliwiający potencjalnie out-of-bounds memory access po stronie Chrome (scenariusz: spreparowana strona HTML).

Wniosek operacyjny: nawet jeśli 12 lutego to „maintenance build”, to w praktyce jest on częścią bezpiecznego dowiezienia linii 145 na endpointy (oraz ograniczania okna ekspozycji na podatności opisane w wydaniu 145).

Praktyczne konsekwencje / ryzyko

  1. Ryzyko dla użytkowników końcowych: podatności pamięciowe w przeglądarce zwykle są atrakcyjne dla atakujących, bo mogą prowadzić do kompromitacji przez samo wejście na stronę (lub wykonanie akcji w UI), a potem do dalszych etapów łańcucha ataku (np. ucieczka z sandboxa, dropper). W tej serii poprawek mamy kilka luk High.
  2. Ryzyko dla organizacji: opóźnienia w rollout powodują, że część floty pozostaje na buildach sprzed poprawek. Wpisy Google wprost mówią o stopniowym wdrażaniu „over the coming days/weeks”.
  3. Wersje różne per OS: 12 lutego widać asymetrię numeracji (Windows/Mac: 145.x, Linux: 144.x). To istotne dla inwentaryzacji i compliance – progi wersji w politykach (np. w MDM/EDR) powinny uwzględniać platformę, a nie tylko „jedną docelową liczbę”.

Rekomendacje operacyjne / co zrobić teraz

  • Wymuś/monitoruj aktualizację do najnowszego Stable na każdej platformie: dla Windows/Mac celuj w 145.0.7632.68, a dla Linux co najmniej 144.0.7559.67 (zgodnie z komunikatem z 12 lutego).
  • Zamknij okno ekspozycji: potraktuj rollout jako pilny, bo gałąź 145 zawiera liczne poprawki bezpieczeństwa, w tym High.
  • Zadbaj o „relaunch compliance”: w praktyce wiele organizacji ma poprawnie pobrane aktualizacje, ale użytkownicy nie restartują Chrome. Mierz wskaźniki „pending relaunch” i komunikuj wymuszenia (np. grace period).
  • SOC/IR: jeśli widzisz kampanie webowe/drive-by lub anomalia związane z GPU/codec, potraktuj endpointy bez 145 jako podwyższone ryzyko (priorytet do aktualizacji i dodatkowy monitoring).
  • Enterprise/zmiany funkcji: jeżeli zarządzasz flotą, śledź również zmiany w release notes (np. mechanizmy bezpieczeństwa sesji i inne twardnienia), bo mogą wpływać na aplikacje webowe i polityki.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • 10 lutego 2026: wydanie „duże” – wejście Chrome 145 na Stable i jawnie wymienione CVE (11 pozycji).
  • 12 lutego 2026: wydanie „małe/utrwalające” – komunikat skupia się na numerach buildów i odsyła do logu zmian, bez listy CVE.
    Taki układ jest typowy: najpierw publikacja z listą CVE, a później szybkie „dot release” poprawiające jakość/stabilność rollout i ewentualne regresje.

Podsumowanie / kluczowe wnioski

  • Aktualizacja z 12 lutego 2026 podnosi Stable do 145.0.7632.68 (Windows/Mac) oraz 144.0.7559.67 (Linux) i jest rolowana stopniowo.
  • Warto ją traktować jako element łańcucha bezpieczeństwa po wydaniu z 10 lutego, które zawierało 11 poprawek security (w tym High w obszarach CSS/Codecs/WebGPU).
  • Dla organizacji kluczowe jest: aktualizacja + wymuszenie restartu + poprawna walidacja wersji per OS.

Źródła / bibliografia

  1. Google Chrome Releases – Stable Channel Update for Desktop (12 lutego 2026). (Chrome Releases)
  2. Google Chrome Releases – Stable Channel Update for Desktop (10 lutego 2026) + lista poprawek bezpieczeństwa (CVE). (Chrome Releases)
  3. NVD – CVE-2026-2315 (WebGPU, High) – opis i zakres wersji. (nvd.nist.gov)
  4. Chrome Enterprise & Education release notes – wybrane zmiany w Chrome 145 (kontekst funkcji i bezpieczeństwa). (Google Help)
  5. Zewnętrzny advisory (CERT/CIRT) odnoszący się do wydań Chrome z lutego 2026 (kontekst operacyjny). (cirt.gy)

Fortinet łata podatności wysokiej wagi: RCE w FortiSandbox i bypass uwierzytelniania w FortiOS

Wprowadzenie do problemu / definicja luki

Fortinet opublikował pakiet poprawek obejmujący wiele produktów (m.in. FortiOS, FortiGate, FortiAuthenticator, FortiClient dla Windows i FortiSandbox), usuwając luki, z których część da się wykorzystać bez uwierzytelnienia. Wśród nich znalazły się m.in. podatność XSS prowadząca do wykonania poleceń oraz obejście mechanizmu uwierzytelniania w scenariuszach opartych o LDAP.

W skrócie

  • Fortinet opublikował 8 advisory i naprawił łącznie 9 podatności, w tym dwie o wysokiej wadze.
  • Najpoważniejsze kwestie z tej paczki:
    • CVE-2025-52436 (FortiSandbox): XSS, które może skutkować uruchomieniem poleceń bez logowania (przy odpowiednim łańcuchu wykonania).
    • CVE-2026-22153 (FortiOS): bypass uwierzytelniania LDAP dla Agentless VPN lub polityk FSSO w specyficznej konfiguracji zdalnego serwera LDAP.
  • Wśród luk średniej wagi wyróżnia się CVE-2025-68686 dotycząca FortiOS SSL-VPN – istotna, bo jest opisywana jako obejście poprawek wdrażanych po wcześniejszych incydentach post-exploit.

Kontekst / historia / powiązania

Szczególnie ciekawy (i operacyjnie ważny) jest wątek CVE-2025-68686: Fortinet wskazuje, że ta luka wiąże się ze scenariuszami „post-exploit” po wcześniejszym przełamaniu urządzenia inną podatnością i dotyczy obejścia mechanizmu związanego z utrzymywaniem „symlink persistence”. W komunikacji padają też odniesienia do historycznie intensywnie atakowanych błędów Fortinet, m.in. CVE-2022-42475, CVE-2023-27997 oraz CVE-2024-21762.

Dodatkowo, zaledwie kilka dni wcześniej Fortinet załatał krytyczne SQLi w FortiClientEMS (CVE-2026-21643), co pokazuje, że luty 2026 to okres „gęsty” w aktualizacje bezpieczeństwa dla ich portfolio.

Analiza techniczna / szczegóły luki

CVE-2025-52436 (FortiSandbox) – XSS → wykonanie poleceń

  • Klasa: XSS (CWE-79) w interfejsie web.
  • Istota ryzyka: w określonych warunkach atakujący może doprowadzić do wykonania nieautoryzowanych poleceń/komend bez uwierzytelnienia poprzez spreparowane żądania.
  • Co warto podkreślić: XSS bywa traktowany „webowo”, ale w appliance’ach bezpieczeństwa konsekwencją potrafi być przejęcie funkcji administracyjnych lub eskalacja do wykonania poleceń, jeśli komponenty backendu nie izolują kontekstu/akcji.

CVE-2026-22153 (FortiOS) – bypass uwierzytelniania LDAP dla Agentless VPN / FSSO

  • Klasa: Authentication Bypass (CWE-305).
  • Warunek konieczny: podatność jest opisywana jako zależna od konkretnej konfiguracji zdalnego serwera LDAP (czyli nie zawsze „włącz i podatne”, tylko „włącz + określony układ”).
  • Skutek: możliwość obejścia uwierzytelnienia LDAP w kontekście Agentless VPN albo polityk FSSO, co jest szczególnie groźne, jeśli te mechanizmy wystawione są do sieci i stanowią bramę do zasobów wewnętrznych.

CVE-2025-68686 (FortiOS SSL-VPN) – obejście poprawek post-exploit / ujawnienie informacji

  • Klasa: Exposure of Sensitive Information (CWE-200).
  • Co wyróżnia tę lukę: Fortinet opisuje ją jako możliwość obejścia poprawki opracowanej przeciw mechanizmowi „symlink persistency” obserwowanemu w pewnych przypadkach po udanym ataku, poprzez spreparowane żądania HTTP.
  • Ważne ograniczenie z perspektywy triage: Fortinet wskazuje, że środowiska, które nigdy nie miały włączonego SSL-VPN, nie są dotknięte tym problemem.

Praktyczne konsekwencje / ryzyko

  • Internet-facing urządzenia Fortinet (zwłaszcza tam, gdzie używany jest SSL-VPN, Agentless VPN, FSSO, integracja z LDAP) są w naturalny sposób bardziej narażone na próby wykorzystania błędów.
  • Scenariusz obronny nie powinien zakładać wyłącznie „czy luka jest aktywnie exploitowana dziś”, bo część wektorów bywa wykorzystywana w kampaniach z opóźnieniem (gdy pojawiają się PoC / moduły w frameworkach).
  • Szczególnie CVE-2025-68686 jest sygnałem, że warto myśleć o „czyszczeniu po włamaniu” i twardym przeglądzie urządzeń, bo luka dotyczy mechaniki znanej z przypadków post-exploit.

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję
    • Które instancje FortiOS/FortiGate mają wystawione: SSL-VPN, Agentless VPN, FSSO, panele zarządzania, integracje LDAP.
  2. Priorytetyzuj patching
    • Najpierw systemy internet-facing i krytyczne ścieżki dostępu (VPN/SSO/LDAP, portale administracyjne).
  3. Ogranicz powierzchnię ataku natychmiast (gdy patch nie jest „na już”)
    • Odetnij dostęp do interfejsów zarządzania z Internetu (ACL, VPN admin-only, allowlisty).
    • Jeśli SSL-VPN nie jest potrzebny – wyłącz (wątek CVE-2025-68686).
  4. Hunting i detekcja
    • Przejrzyj logi i konfiguracje pod kątem nietypowych zmian (nowi admini, zmiany reguł, nieznane integracje LDAP/FSSO, nietypowe żądania HTTP do komponentów VPN).
  5. Hardening po aktualizacji
    • Rotacja haseł adminów, przegląd kont lokalnych, MFA tam gdzie możliwe, segmentacja zarządzania (oddzielne VRF/VLAN dla mgmt).

Różnice / porównania z innymi przypadkami

  • XSS vs. bypass uwierzytelniania: XSS (CVE-2025-52436) bywa „lekceważony” jako web-bug, ale w appliance’ach bezpieczeństwa często stanowi krok do przejęcia funkcji administracyjnych. Z kolei bypass LDAP (CVE-2026-22153) uderza bezpośrednio w mechanizm kontroli dostępu – i to w kontekście VPN/FSSO, czyli strefy o wysokiej wartości dla atakujących.
  • CVE-2025-68686 wyróżnia się tym, że jest opisywane jako obejście poprawek związanych z zachowaniem napastników po wcześniejszych kompromitacjach – to bardziej „ciąg dalszy historii” niż klasyczna „nowa dziura”.

Podsumowanie / kluczowe wnioski

  • Fortinet załatał pakiet podatności w kilku produktach; dwie z nich mają wysoki priorytet, bo dotyczą komend/RCE bez uwierzytelnienia (FortiSandbox) oraz obejścia uwierzytelniania (FortiOS + LDAP).
  • Dla zespołów SOC/NetSec kluczowe jest szybkie ustalenie, czy organizacja używa SSL-VPN, Agentless VPN, FSSO i LDAP na urządzeniach Fortinet oraz czy te usługi są wystawione na zewnątrz.
  • Nawet jeśli vendor nie potwierdza aktywnej eksploatacji w momencie publikacji, praktyka pokazuje, że „okno ryzyka” rośnie gwałtownie po nagłośnieniu i udostępnieniu analiz/PoC – dlatego patching i redukcja ekspozycji powinny być traktowane jako pilne.

Źródła / bibliografia

  1. SecurityWeek – opis paczki poprawek i kontekst (11 lutego 2026). (SecurityWeek)
  2. FortiGuard PSIRT – FG-IR-25-093 (CVE-2025-52436). (fortiguard.fortinet.com)
  3. FortiGuard PSIRT – FG-IR-25-1052 (CVE-2026-22153). (fortiguard.fortinet.com)
  4. FortiGuard PSIRT – FG-IR-25-934 (CVE-2025-68686). (fortiguard.fortinet.com)
  5. NVD – karta podatności CVE-2026-22153 (szczegóły i klasyfikacja). (NVD)

Luka w Notatniku Windows 11: kliknięcie linku Markdown mogło uruchamiać pliki „po cichu” (CVE-2026-20841)

Wprowadzenie do problemu / definicja luki

Microsoft załatał podatność typu Remote Code Execution (RCE) w nowoczesnym Notatniku Windows 11, związaną z obsługą Markdown. Luka polegała na tym, że po otwarciu pliku .md w trybie Markdown i kliknięciu spreparowanego odnośnika, Notatnik mógł uruchomić wskazany program lub zasób bez typowych ostrzeżeń bezpieczeństwa Windows.

W skrócie

  • Identyfikator: CVE-2026-20841 (Windows Notepad App).
  • Klasa błędu: Microsoft/NVD opisują to jako command injection / niewłaściwe neutralizowanie elementów specjalnych w poleceniu (CWE-77).
  • Wektor ataku wg NVD: AV:N/AC:L/PR:N/UI:R — wymagane jest działanie użytkownika (kliknięcie).
  • Praktyka ataku: linki Markdown mogły wskazywać m.in. na file:// (lokalne pliki wykonywalne) lub nietypowe URI (np. ms-appinstaller://).
  • Microsoft wdrożył poprawkę w ramach aktualizacji z lutego 2026 (Patch Tuesday).

Kontekst / historia / powiązania

Źródłem problemu była „modernizacja” Notatnika w Windows 11: aplikacja przestała być wyłącznie prostym edytorem tekstu i zyskała m.in. renderowanie Markdown oraz klikalne linki.
W szerszym obrazie to kolejny przykład, jak „pozornie niewinne” funkcje (renderowanie, podgląd, linki, protokoły) potrafią stworzyć nowe ścieżki ataku w aplikacjach, które użytkownicy traktują jako „bezpieczne z definicji”.

Analiza techniczna / szczegóły luki

Jak działał scenariusz nadużycia

  1. Atakujący dostarczał ofierze plik .md (np. przez phishing, załącznik, komunikator, repozytorium, share).
  2. Ofiara otwierała plik w Notatniku i przełączała/korzystała z widoku Markdown, gdzie link stawał się interaktywny.
  3. Po Ctrl+klik w link (tak opisały testy), Notatnik wywoływał obsługę „niezweryfikowanych” protokołów/URI i mógł doprowadzić do uruchomienia programu lub pobrania/wykonania zasobu zdalnego — bez oczekiwanego ostrzeżenia.

Co było szczególnie niebezpieczne

  • Możliwość wskazania plików wykonywalnych przez file:// lub użycia protokołów systemowych/instalacyjnych.
  • Potencjalny wariant z zdalnymi udziałami SMB, gdzie kliknięcie prowadziłoby do wykonania pliku z zasobu sieciowego bez typowego „tarcia” po stronie systemu.
  • Wykonanie następowało w kontekście uprawnień użytkownika (czyli dokładnie tyle, ile ma ofiara).

Co zmieniła poprawka

Według testów opisywanych przez BleepingComputer, Notatnik po poprawce zaczął wyświetlać ostrzeżenia dla linków niebędących http:// lub https://. Dotyczy to m.in. file:, ms-settings:, ms-appinstaller:, mailto:, ms-search:.

Praktyczne konsekwencje / ryzyko

To nie jest klasyczny „drive-by exploit” — nadal potrzebna jest interakcja użytkownika. Ale w praktyce:

  • Plik tekstowy/Markdown ma niski „próg podejrzaności” (ludzie chętnie go otwierają, żeby sprawdzić co jest w środku).
  • Link może wyglądać jak niewinny odnośnik typu „Otwórz logi” / „Instrukcja” / „Kliknij, aby naprawić”.
  • W środowiskach firmowych taka luka pasuje do łańcuchów ataku: phishing → dropper → kliknięcie → uruchomienie payloadu (zwłaszcza gdy atakujący ma już coś na dysku lub na udziale SMB).

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj Notatnik (Windows 11) — aplikacja zwykle aktualizuje się przez Microsoft Store, ale w organizacjach bywa to kontrolowane politykami. Upewnij się, że urządzenia nie są „zatrzymane” na starszych wersjach.
  2. Zablokuj/ogranicz nietypowe protokoły tam, gdzie to możliwe (np. politykami aplikacyjnymi/ASR, kontrolą protokołów, hardeningiem środowiska).
  3. Traktuj pliki .md jak dokumenty aktywne, jeśli pochodzą z zewnątrz: sandbox, podgląd bez klikania, skan AV/EDR, izolacja.
  4. Edukacja użytkowników: „Nie klikaj linków w plikach tekstowych/Markdown z maila/Teams/Slack, jeśli nie znasz źródła”.
  5. Monitoring: poluj na anomalie typu uruchomienia procesu pochodzące z Notatnika (np. notepad.exe → cmd.exe, powershell.exe, instalatory, binarki z udziałów sieciowych).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • To nie jest błąd w stylu „makr Office” — mechanizm jest prostszy, ale bazuje na podobnym założeniu: użytkownik ufa formatowi pliku i klika element interaktywny.
  • Warto też odróżnić „Notepad” od „Notepad++”: The Register zwraca uwagę na bliskość czasową dyskusji o problemach bezpieczeństwa w ekosystemie edytorów tekstu, ale są to różne produkty i różne wektory.

Podsumowanie / kluczowe wnioski

CVE-2026-20841 pokazuje klasyczny problem „rozszerzania prostych narzędzi”: gdy aplikacja do czytania tekstu zaczyna renderować treści i obsługiwać wiele protokołów, rośnie powierzchnia ataku. Luka w Notatniku Windows 11 umożliwiała uruchamianie plików (lokalnych lub zdalnych) po kliknięciu linku Markdown bez oczekiwanych ostrzeżeń, a poprawka dodaje dodatkowe monity dla nie-HTTP(S) URI. Najważniejsze działania to: aktualizacja, hardening protokołów/URI, procedury dla plików Markdown z zewnątrz i telemetria procesów potomnych z Notatnika.

Źródła / bibliografia

  • BleepingComputer — opis podatności i zachowania „bez ostrzeżeń”, przykłady URI oraz informacja o poprawce (ostrzeżenia dla nie-HTTP/S). (BleepingComputer)
  • NVD (NIST) — klasyfikacja, CVSS v3.1 vector oraz powiązanie z CWE-77 i odnośnik do MSRC. (NVD)
  • Rapid7 — kontekst Patch Tuesday (luty 2026) i przegląd podatności z tego wydania. (Rapid7)
  • The Register — szerszy kontekst i komentarz do „Markdown w Notatniku” oraz dyskusji o ryzykach w edytorach. (The Register)