Archiwa: APT - Strona 30 z 45 - Security Bez Tabu

Rosyjski APT28 (BlueDelta) poluje na konta: kampania credential-harvesting wymierzona w sektor energii, badania i współpracę obronną

Wprowadzenie do problemu / definicja luki

APT28 (znany też jako BlueDelta, Fancy Bear, Forest Blizzard) to rosyjska grupa APT powiązana z GRU i aktywna co najmniej od 2004 roku.
W opisywanej operacji nie chodzi o „lukę” w sensie CVE, lecz o kampanię kradzieży poświadczeń (credential harvesting): atakujący podszywają się pod znane portale logowania (webmail/VPN), aby przejąć hasła i potencjalnie kolejne składniki uwierzytelniania, a następnie wykorzystać je do dostępu do poczty, dokumentów i środowisk zdalnego dostępu.

Najnowsze ustalenia wskazują, że APT28 celował w osoby i organizacje powiązane m.in. z badaniami energetycznymi i nuklearnymi, współpracą obronną oraz kanałami komunikacji instytucji rządowych.

W skrócie

Kampanie trwały między lutym a wrześniem 2025, a ich opis opublikowano w styczniu 2026.
Atakujący używali stron logowania stylizowanych na Microsoft Outlook Web Access (OWA), Google oraz Sophos VPN.
Widoczne jest silne nadużycie „legalnej” infrastruktury: free hosting i tunele/reverse proxy (m.in. Webhook[.]site, InfinityFree, Byet, ngrok) do hostowania phishingu i eksfiltracji danych.
Dla uwiarygodnienia stosowano prawdziwe dokumenty PDF (przynęty), wyświetlane krótko przed przekierowaniem na fałszywe logowanie.

Kontekst / historia / powiązania

Recorded Future (Insikt Group) wiąże BlueDelta/APT28 z długotrwałą strategią GRU opartą na niskokosztowej, wysokozwrotnej kradzieży poświadczeń, która następnie umożliwia rozpoznanie, dostęp do korespondencji, pivot do kolejnych systemów i operacje wpływu/wywiadu.

Ta aktywność pasuje do szerszego profilu APT28 opisywanego w MITRE ATT&CK (m.in. ukierunkowane phishingi, operacje wywiadowcze, rozbudowane łańcuchy dostępu).
Wcześniejsze publikacje Recorded Future wskazywały także na działania BlueDelta przeciwko ukraińskim instytucjom (np. wątki związane z infrastrukturą pocztową), co podkreśla ciągłość priorytetów w regionie.

Analiza techniczna / szczegóły luki

1. Mechanika ataku: od linku do kradzieży hasła

W badanych kampaniach dominował schemat:

Spearphishing / wiadomość z linkiem (często przez skracacze URL),
wielostopniowe przekierowania przez usługi pośredniczące,
krótka prezentacja legalnej przynęty PDF w przeglądarce (element „uśpienia czujności”),
przekierowanie na fałszywy portal logowania,
po wpisaniu danych – redirect do prawdziwej strony, by zminimalizować podejrzenia.

Recorded Future opisuje m.in. użycie ShortURL jako pierwszego etapu i Webhook[.]site do obsługi kolejnych kroków, w tym wyświetlenia PDF i finalnego przekierowania na phishing OWA.

2. Podszywanie się pod OWA, Google i Sophos VPN

Najczęściej emulowane były:

Microsoft OWA (zarówno klasyczne „logowanie”, jak i motywy typu „expired password”),
Google (scenariusz „password reset”),
Sophos VPN (bramki zdalnego dostępu, atrakcyjne dla środowisk korporacyjnych).

Istotny detal: Insikt Group zwraca uwagę na customowe skrypty JavaScript do przechwytywania danych, śledzenia aktywności ofiary i automatyzacji przekierowań, co upraszcza „wdrożenie” kolejnych fal kampanii.

3. Infrastruktura: „legalne” usługi jako parasol

Silnym wyróżnikiem jest konsekwentne oparcie się na usługach, które:

są tanie/darmowe,
łatwo rotować,
trudniej jednoznacznie blokować bez skutków ubocznych,
często omijają proste listy reputacyjne.

Wprost wskazywane są m.in. Webhook[.]site, InfinityFree, Byet Internet Services oraz ngrok – jako elementy hostowania stron, obsługi przekierowań i kanałów eksfiltracji.

4. Profil ofiar (co wiemy)

Insikt Group opisuje „niewielki, ale wyraźnie dobrany” zestaw celów: m.in. osoby powiązane z turecką agencją badań energetycznych i nuklearnych, pracowników europejskiego think tanku oraz organizacje w Macedonii Północnej i Uzbekistanie. Dobór przynęt (język, tematyka) miał wspierać wiarygodność regionalną.

Praktyczne konsekwencje / ryzyko

Przejęcie poczty i dokumentów: w realiach M365/Google Workspace nawet krótkie okno dostępu do skrzynki może ujawnić wątki projektowe, listy kontaktów, harmonogramy i załączniki.
Dalsza eskalacja: skradzione dane logowania bywają wykorzystywane do resetów haseł w innych usługach, ataków na VPN, aplikacje biznesowe i systemy współdzielenia plików.
Ryzyko dla łańcucha współpracy: sektor badań energii/nukleariów i współpracy obronnej działa sieciowo (partnerstwa, konsorcja, granty) – jedno przejęte konto może posłużyć jako „zaufany nadawca” do kolejnych spearphishingów.
Trudniejsze wykrycie: przekierowanie na prawdziwe strony po kradzieży danych i użycie legalnej infrastruktury obniża „szum” alarmowy i wydłuża czas do wykrycia.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

Wymuś MFA odporne na phishing (FIDO2/WebAuthn, passkeys, klucze sprzętowe) dla OWA/VPN i kont uprzywilejowanych; ogranicz SMS/voice tam, gdzie to możliwe. (Insikt Group wprost rekomenduje priorytetyzację metod odpornych na phishing).
Zablokuj/ogranicz skracacze linków oraz ryzykowne kategorie domen w secure web gateway / DNS (tam, gdzie nie są biznesowo potrzebne).
Wzmocnij Conditional Access: geofencing, „impossible travel”, wymóg zgodnego urządzenia, ryzyka logowania, blokady legacy auth.

Uporządkowanie obrony (1–4 tygodnie)

Denylist usług nadużywanych w kampanii (jeśli nie są wymagane biznesowo): Webhook[.]site, InfinityFree, Byet, ngrok i podobne klasy usług „free hosting/tunneling”.
Detekcje w SIEM/EDR:
- kliknięcia w linki prowadzące do kaskad przekierowań,
- nietypowe logowania do OWA/VPN po kliknięciu w e-mail,
- anomalie sesji (nagłe zmiany IP/ASN, nowe urządzenia, brak historii).
Ochrona przed typosquattingiem: alerty na domeny łudząco podobne do brandów (OWA/Google/Sophos) + monitoring nowych rejestracji.

Higiena użytkownika (ciągłe)

Szkolenia „microlearning”: jak rozpoznać fałszywe logowanie, dlaczego PDF-przynęta nie oznacza bezpieczeństwa, czemu „wróciło na prawdziwą stronę” to klasyczny trik.

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

BlueDelta/OWA/VPN vs. klasyczne exploity: ta kampania stawia na socjotechnikę i kradzież poświadczeń, ale APT28 nie ogranicza się do phishingu. Dla kontrastu, CISA opisywała wcześniej przypadki, w których APT28 wykorzystywał podatności i słabe utrzymanie urządzeń brzegowych (np. routery Cisco) do rozpoznania i wdrażania złośliwego oprogramowania.
Ewolucja „realizmu”: w materiałach Insikt Group mocno wybrzmiewa rosnąca jakość łańcuchów przekierowań i użycie prawdziwych PDF-ów jako elementu antydetekcyjnego (krótkie wyświetlenie dokumentu przed phishingiem).
Stałe priorytety geopolityczne: wcześniejsze analizy działań BlueDelta wobec ukraińskich celów pokazują ciągłość zainteresowania regionem i infrastrukturą informacyjną, a obecne cele (energia, współpraca obronna, think tanki) naturalnie wpisują się w potrzeby wywiadowcze.

Podsumowanie / kluczowe wnioski

To kampania credential-harvesting, nie „jedna luka”: jej siłą jest skala automatyzacji, wiarygodne przynęty i infrastruktura trudna do blokowania bez skutków ubocznych.
Największe ryzyko ponoszą organizacje, w których OWA/VPN są krytyczne, a MFA wciąż bywa podatne na phishing lub źle egzekwowane.
Najlepsza odpowiedź defensywna to połączenie: phishing-resistant MFA + conditional access + blokowanie ryzykownej infrastruktury + szybkie detekcje anomalii logowania.

Źródła / bibliografia

SecurityWeek — opis kampanii i kontekstu (styczeń 2026). (SecurityWeek)
Recorded Future, Insikt Group — „GRU-Linked BlueDelta Evolves Credential Harvesting” (cut-off: 11 września 2025; publikacja styczeń 2026). (Recorded Future)
MITRE ATT&CK — profil grupy APT28 (G0007). (MITRE ATT&CK)
CISA — advisory dot. aktywności APT28 (routery Cisco; kwiecień 2023). (CISA)
Recorded Future — wcześniejszy kontekst działań BlueDelta wobec ukraińskich celów (czerwiec 2023). (Recorded Future)

Pig Butchering-as-a-Service: jak „dostawcy usług” industrializują oszustwa inwestycyjne i romance baiting

Wprowadzenie do problemu / definicja luki

„Pig butchering” (chiń. sha zhu pan) to klasa oszustw, w których przestępcy budują relację (romantyczną lub „biznesową”), a potem przekonują ofiarę do inwestycji na fałszywej platformie (często pseudo-krypto/forex). Coraz częściej to już nie „pojedynczy scammerzy”, tylko zorganizowana gospodarka usługowa: Pig Butchering-as-a-Service (PBaaS) — zestaw gotowych narzędzi, szablonów, danych i infrastruktury, które można po prostu kupić i wdrożyć jak SaaS.

To ważna zmiana: bariera wejścia spada, a skala rośnie, bo „obsługa” oszustwa rozkłada się na wyspecjalizowanych dostawców (dane, konta, SIM, płatności, CRM, fałszywe platformy inwestycyjne, aplikacje mobilne, spółki-wydmuszki).

W skrócie

Badacze opisali dwie kluczowe kategorie dostawców PBaaS: (1) „marketplace” z danymi, kontami i materiałami do socjotechniki oraz (2) platformy CRM do zarządzania agentami i ofiarami (w tym panele admina, KYC, metryki „rentowności”).
Przykładowy „stack” PBaaS obejmuje m.in. skradzione dane PII, konta w serwisach społecznościowych, SIM-y, routery 4G/5G, IMSI catchery, zestawy zdjęć person („character sets”), a nawet moduły płatności P2P.
Infoblox wskazuje, że szablon strony z hostingiem może kosztować ok. 50 USD, a „pełny pakiet” (www + admin + VPS + aplikacja mobilna + dostęp do platformy tradingowej + rejestracja spółki w raju podatkowym + „rejestracja” u regulatora) startuje od ok. 20 000 juanów (~2 500 USD).
Równolegle widzimy „infrastrukturę-akcelerator” dla cyberprzestępczości: parkowane domeny i mechanizmy reklamowe/redirectów (direct search/zero-click), które w eksperymentach >90% czasu prowadzą do scamów, scareware lub malware.

Kontekst / historia / powiązania

Industrializacja i geografia

Według analiz Infoblox, w Azji Południowo-Wschodniej powstały setki „centrów scamowych” wspieranych praniem pieniędzy i handlem ludźmi; PBaaS jest jednym z motorów, który pozwala takim operacjom szybko się skalować bez dużego zaplecza technicznego po stronie „operatorów linii”.

„Words matter”: pig butchering vs romance baiting

INTERPOL zwraca uwagę, że sama nazwa „pig butchering” może stygmatyzować ofiary i zniechęcać do zgłaszania. Organizacja promuje termin „romance baiting”, który przenosi ciężar z „etykietowania” poszkodowanych na opis taktyk sprawców.

Analiza techniczna / szczegóły „luki” (PBaaS jako łańcuch dostaw)

Warto patrzeć na PBaaS jak na łańcuch dostaw cyberoszustwa: od pozyskania danych i tożsamości, przez kanały dotarcia, po platformę „inwestycyjną” i wypłatę/transfer środków.

1. „Penguin Account Store” — hurtownia zasobów do socjotechniki

Infoblox opisuje aktora działającego pod nazwami m.in. Heavenly Alliance / Overseas Alliance / Penguin Account Store, który sprzedaje „fraud kity”, szablony i komponenty potrzebne do uruchomienia oszustwa.

Kluczowe elementy oferty:

shè gōng kù — bazy PII (m.in. dane finansowe, historia podróży, informacje o rodzinie), wykorzystywane do selekcji „wartościowych” ofiar i budowania wiarygodności w rozmowie („znam ostatnie transakcje”).
skradzione konta (np. serwisy społecznościowe, komunikatory, konta deweloperskie) — tanie wejście w „zaufane” kanały kontaktu; Infoblox wskazuje, że konta mogą zaczynać się od ok. 0,10 USD.
sprzęt i telekom-enablers: pre-rejestrowane SIM-y, routery 4G/5G, IMSI catchery, a także „character sets” — paczki zdjęć (kradzione z social mediów) do spójnego budowania persony.
SCRM AI — platforma typu Social CRM do automatyzacji interakcji i „obsługi” ofiar w social mediach (Infoblox zastrzega, że nie wiadomo, ile tam faktycznie AI).
BCD Pay / Bochuang Guarantee — komponent płatności P2P powiązany (wg badaczy) z ekosystemem nielegalnego hazardu, co jest typowym „mostem” do prania i rozproszenia przepływów.

Wniosek obronny: Penguin działa jak „hurtownia części zamiennych” dla scamu — zasoby, które kiedyś wymagały kradzieży/operacji własnych, są dostępne w modelu marketplace.

2. „UWORK CRM” — panel dowodzenia operacją i skalowanie „agentów”

Drugą klasą dostawców są platformy CRM do zarządzania treścią, agentami i ofiarami. Infoblox opisuje sprzedawcę UWORK, od którego badacze pozyskali dostęp do CRM i przeanalizowali workflow.

Co jest istotne technicznie:

Panel admina oferuje szablony dla różnych narracji (krypto/forex/złoto), wielojęzyczność, integracje z e-mailem/Telegramem, a nawet geofencing (ograniczanie dostępu po IP, by utrudnić działania organów ścigania w „ryzykownych” jurysdykcjach).
„Legal-look” przez KYC: ofiara wgrywa dokumenty „weryfikacyjne”, co zwiększa zaufanie — i jednocześnie tworzy wtórne ryzyko nadużyć tożsamości.
Role i kontrola finansów: „pierwsza linia” agentów ma ograniczenia, a system może automatycznie eskalować depozyty i przenosić środki do kont poza zasięgiem agentów (ochrona „organizacji” przed defraudacją wewnętrzną).
Infoblox opisuje też element „udawanej wiarygodności” poprzez integracje z rozpoznawalnymi platformami tradingowymi (np. MetaTrader) i prezentację danych „w czasie rzeczywistym”.

3. Ekonomia PBaaS: dlaczego to rośnie?

PBaaS ma logikę klasycznego „crimeware-as-a-service”: niskie koszty startu, modułowość, szybkie kopiowanie kampanii.

Infoblox podaje twarde liczby:

~50 USD za prosty szablon strony z hostingiem,
~2 500 USD za „pełny pakiet” (www+admin, VPS, aplikacja, platforma tradingowa, spółka-wydmuszkowa, „rejestracja”).

Praktyczne konsekwencje / ryzyko

Dla osób prywatnych

Wiarygodność „na sterydach”: oszuści dysponują PII, spójnymi personami (zdjęcia/filmy), oraz dopracowanymi platformami „inwestycyjnymi”.
Wtórne szkody: przekazane dokumenty KYC, selfie, skany — mogą być odsprzedane i użyte w kolejnych oszustwach, przejęciach kont lub do „otwierania” rachunków-słupów.

Dla firm (w tym fintech, telekom, e-commerce)

Nadużycia tożsamości / fraud rosną, bo PBaaS dostarcza masowo konta, SIM-y i treści.
Ryzyko domenowe i reklamy: parkowane domeny + „direct search/zero-click” stają się kanałem dystrybucji scamów i malware. Infoblox pokazuje scenariusze, gdzie ta sama domena „dla skanera” wygląda niewinnie, a użytkownika mobilnego kieruje wprost na oszustwo; w ich eksperymentach to >90% przypadków.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/Blue Team (organizacje)

DNS i domeny
- Włącz monitoring typosquattingu/look-alike domen dla brandu oraz domen krytycznych (logowanie, SSO, płatności).
- Zasil polityki blokowania (Secure DNS / RPZ / SWG) o feedy scam/malvertising; traktuj parkowane domeny jako „domyślnie podejrzane” w ruchu użytkowników.
Ochrona kanałów dotarcia
- Zaostrz polityki przeciw przejęciom kont (MFA phishing-resistant gdzie to możliwe, anomalia logowań, kontrola nowych urządzeń).
- Uważaj na „zaufane” kanały: WhatsApp/Telegram/IG/FB — PBaaS sprzedaje gotowe konta i persony.
Procedury antyfraud / KYC
- Traktuj „KYC-like” prośby poza zaufanym procesem jako sygnał incydentu (zwłaszcza gdy pojawiają się w kampaniach phishing/social).
- Edukuj helpdesk i zespoły biznesowe: „platforma inwestycyjna + nacisk na szybki depozyt + kontakt relacyjny” to typowy wzorzec.

Dla użytkowników (praktyka)

Weryfikuj platformy inwestycyjne: domena, podmiot, licencja, opinie regulatorów — i pamiętaj, że PBaaS potrafi „udawać” rejestrację/wiarygodność.
Nie instaluj APK „z linku” ani profili/prowizjonowania na iOS z nieznanych źródeł — PBaaS aktywnie używa aplikacji mobilnych jako części scamu.
Jeśli relacja online szybko przechodzi w „wspólne inwestowanie”, a druga strona ma gotowy „panel” i presję czasu — traktuj to jako wysokie ryzyko. (To sedno romance baiting/pig butchering.)

Różnice / porównania z innymi przypadkami

PBaaS to ten sam kierunek, co MaaS/PhaaS, ale z innym „produktem końcowym”:

w MaaS sprzedaje się malware i dostęp,
w PBaaS sprzedaje się kompletną fabrykę oszustwa: dane + persony + kanały + platforma + płatności + operacyjny CRM.

Dodatkowo, infrastruktura reklamowo-domenowa (parkowanie + direct search) pełni rolę „ruchu na żądanie” dla scamów, analogicznie do botnetów-as-a-service w innych ekosystemach cyberprzestępczych.

Podsumowanie / kluczowe wnioski

Najgroźniejsza cecha PBaaS to industrializacja: gotowe komponenty sprawiają, że oszustwo staje się powtarzalnym procesem biznesowym, a nie „sztuką” pojedynczych sprawców.
„Dostawcy” jak Penguin (dane/konta/persony/płatności) oraz UWORK (CRM i panele operacyjne) pokazują, że obrona nie może skupiać się wyłącznie na „końcowych domenach” scamu — trzeba uderzać w enablers: infrastrukturę, płatności, domeny, dystrybucję.
Równolegle rośnie rola „szarej” infrastruktury internetowej (parkowane domeny i łańcuchy reklamowe), która utrudnia atrybucję i zwiększa zasięg kampanii.

Źródła / bibliografia

The Hacker News (12 stycznia 2026): opis dostawców PBaaS i kontekstu ekosystemu (The Hacker News)
Infoblox Threat Intel (8 stycznia 2026): „Scaling the Fraud Economy: Pig Butchering as a Service” — Penguin, UWORK, kosztorys, mechanika CRM (Infoblox)
Infoblox Threat Intel (16 grudnia 2025): „Parked Domains Become Weapons with Direct Search Advertising” — >90% przekierowań do złośliwych treści, profilowanie odwiedzających (Infoblox)
INTERPOL (17 grudnia 2024): „romance baiting” jako termin i wpływ języka na zgłaszalność (interpol.int)
Malanta (3 grudnia 2025): analiza infrastruktury „na poziomie APT” w ekosystemie domen/malware/hijackingu (kontekst przemysłowej skali) (malanta.ai)

Nowa chińsko-powiązana grupa UAT-7290 atakuje operatorów telekomunikacyjnych przez exploity na urządzenia brzegowe (edge) i buduje sieć ORB

Wprowadzenie do problemu / definicja luki

Telekomy (oraz dostawcy usług sieciowych) są dziś jednym z najbardziej atrakcyjnych celów dla aktorów APT: dostęp do infrastruktury szkieletowej i węzłów brzegowych daje możliwość długotrwałej obserwacji ruchu, pivotowania do sieci klientów i budowania „strategicznej” przewagi wywiadowczej.

Najświeższy przykład to ujawniona przez Cisco Talos aktywność klastra śledzonego jako UAT-7290: grupa ma wykorzystywać publicznie dostępne exploity (tzw. one-day) na urządzenia brzegowe oraz specyficzny dla celu brute force po SSH, by uzyskać dostęp początkowy i eskalować uprawnienia. Następnie wdraża linuksowe implanty oraz tworzy infrastrukturę Operational Relay Box (ORB) wykorzystywaną także przez inne chińsko-powiązane podmioty.

W skrócie

Kto? UAT-7290 – aktor o silnych wskaźnikach „China-nexus”, aktywny co najmniej od 2022 r.
Kogo atakuje? Głównie operatorów telekomunikacyjnych w Azji Południowej, a w ostatnich miesiącach także organizacje w Europie Południowo-Wschodniej.
Jak wchodzi? One-day exploity na popularne edge urządzenia + targetowany brute force SSH.
Co instaluje? Linuxowy łańcuch: RushDrop → DriveSwitch → SilentRaid oraz implant ORB Bulbature.
Po co ORB? Do ukrywania operatorów i „przekaźnikowania” operacji (także przez inne grupy).

Kontekst / historia / powiązania

Talos ocenia z wysoką pewnością, że UAT-7290 wpisuje się w chińską „rodzinę” APT i prowadzi działania o profilu cyber-wywiadowczym. Wskazywane są też nakładki TTP i infrastruktury z innymi znanymi bytami: m.in. artefakty kojarzone z RedLeaves (łączonym z APT10) i ShadowPad, a także podobieństwa do grupy opisywanej publicznie jako Red Foxtrot.

Ważny element układanki to ORB. Niezależnie od Talos, Sekoia opisywała już wcześniej ekosystem kompromitowanych urządzeń brzegowych, które po infekcji stają się Operational Relay Boxes – w praktyce „węzłami pośredniczącymi” dla dalszych ataków i tunelowania działań.

Analiza techniczna / szczegóły luki

1) Wejście: exploity na edge + brute force SSH

UAT-7290 ma stawiać na „pragmatykę”:

wykorzystywanie publicznych PoC dla znanych podatności w produktach brzegowych (one-day),
brute force SSH dopasowany do konkretnej ofiary (a nie masowy „spray”).

To model coraz częstszy w ekosystemie APT: urządzenia brzegowe (VPN, firewall, router, appliance) bywają słabiej monitorowane niż serwery, a ich kompromitacja daje świetny punkt do utrzymania dostępu.

2) Łańcuch malware (Linux): RushDrop → DriveSwitch → SilentRaid

RushDrop (alias ChronosRAT) działa jako dropper: wykonuje proste testy anty-VM, tworzy/wykorzystuje katalog “.pkgdb” i rozpakowuje komponenty, m.in. legalnego busybox, który następnie bywa nadużywany do wykonywania poleceń.

DriveSwitch jest komponentem „pomocniczym”, którego głównym zadaniem jest uruchomienie właściwego implantu.

SilentRaid (alias MystRodX) to zasadniczy implant utrzymujący dostęp – w Talos opisywany jako C++ backdoor z architekturą plugin-like, umożliwiający m.in. zdalną powłokę, operacje na plikach i port-forwarding. Zwraca uwagę detal operacyjny: rozwiązywanie domen C2 przez publiczny resolver 8.8.8.8.

3) Bulbature i ORB: „urządzenie brzegowe jako przekaźnik”

Talos wskazuje również na Bulbature – implant używany do przekształcania przejętych urządzeń w ORB (węzły przekaźnikowe). Malware przechowuje konfigurację C2 w plikach w /tmp (np. z rozszerzeniem *.cfg), potrafi rotować adresy C2 i zestawiać reverse shell.

Sekoia opisywała ORB jako część większej architektury: staging serwery + skrypty + malware, które finalnie robi z edge urządzeń „proxy-tunele” do ukrywania działań operatorów.

Praktyczne konsekwencje / ryzyko

Dla operatorów i firm zależnych od telco-infrastruktury to ryzyko w kilku wymiarach:

Długotrwała obecność w sieci (persistence) – edge urządzenia są idealne do „cichego” utrzymania dostępu, często poza standardowym EDR.
Pivot do systemów wewnętrznych (ruch „od brzegu do środka”), a w skrajnych scenariuszach także do środowisk klientów przez zaufane połączenia.
Zbieranie danych i ułatwienie operacji innym aktorom – rola UAT-7290 jako budowniczego ORB sugeruje, że kompromitacja może „żyć dalej”, nawet gdy pierwotny intruz zmieni priorytety.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, ukierunkowany na typowy łańcuch edge-compromise → implant → ORB.

1) Zbijanie powierzchni ataku na edge

Wyłącz ekspozycję paneli administracyjnych do Internetu (jeśli możliwe), ogranicz do VPN/management VLAN.
Wymuś MFA tam, gdzie to realne (zwłaszcza na VPN/SSO).
Zablokuj logowanie hasłem po SSH (preferuj klucze, ogranicz źródła, rate-limit, lockout).
Priorytetyzuj patching podatności na urządzeniach brzegowych – rządowe advisory pokazują, że aktorzy PRC rutynowo „jadą” na publicznych CVE na brzegu.

2) Hunting po artefaktach i zachowaniu

Szukaj nietypowych katalogów/plików: “.pkgdb”, a także podejrzanych plików konfiguracyjnych w /tmp (np. *.cfg) powiązanych z procesami nasłuchującymi na niestandardowych portach.
Monitoruj ruch DNS/egress z urządzeń brzegowych: nietypowe odpytywanie z appliance do 8.8.8.8 (jeśli normalnie nie powinno go być) może być poszlaką.
Anomalie typu: port-forwarding, tworzenie archiwów tar, odczyty /etc/passwd z kontekstu procesów, które nie mają uzasadnienia operacyjnego.

3) Detekcja sieci ORB / proxy-tunneling

Ustal baseline dla wychodzących połączeń TLS z edge urządzeń i odchyleń (np. nowe cele, stałe kanały utrzymujące sesję).
Szukaj sygnałów „proxy provider / tunnel” (Sekoia pokazywała, że ORB bywają zarządzane jak usługa tunelowania).

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

UAT-7290 wpisuje się w szerszy trend działań chińsko-powiązanych, gdzie:

edge urządzenia (backbone/PE/CE, firewalle, VPN, routery) są priorytetowym wektorem wejścia i miejscem utrzymywania dostępu,
kompromitacja bywa wykorzystywana do pivotowania i „zasilania” systemów wywiadowczych (zbieranie danych o komunikacji i przemieszczaniu się celów).

To zbieżne z tym, co rządowe agencje opisywały jako aktywność częściowo nakładającą się na klastry znane komercyjnie m.in. jako Salt Typhoon (i inne). Różnica praktyczna: Talos mocno akcentuje rolę UAT-7290 jako initial access + ORB builder, co może oznaczać „łańcuch dostaw dostępu” dla kolejnych operatorów.

Podsumowanie / kluczowe wnioski

UAT-7290 to nowo opisana (publicznie) aktywność China-nexus wymierzona w telekomy, z ekspansją na Europę Południowo-Wschodnią.
Technicznie grupa gra klasykiem, który nadal działa: one-day exploity na edge + brute force SSH, a potem linuksowy implant o architekturze modułowej.
Największa „waga” ryzyka wynika z ORB: przejęte edge urządzenia mogą stać się trwałą infrastrukturą przekaźnikową dla dalszych operacji.
Obrona powinna zacząć się od edge: patching, ograniczenie ekspozycji, twarde SSH, monitoring egress/DNS i hunting po artefaktach.

Źródła / bibliografia

Cisco Talos – analiza UAT-7290 (RushDrop/DriveSwitch/SilentRaid, ORB). (Cisco Talos Blog)
BleepingComputer – omówienie raportu Talos i podsumowanie arsenalu. (BleepingComputer)
The Hacker News – streszczenie + kontekst (MystRodX, Bulbature, overlap). (The Hacker News)
Sekoia.io – Bulbature/ORB jako model operacyjny na kompromitowanych edge urządzeniach. (Sekoia.io Blog)
Joint Cybersecurity Advisory (IC3.gov) – kontekst działań PRC na routerach/edge i wykorzystywaniu publicznych CVE.

CISA zamyka 10 Emergency Directives: co oznacza „sunset” i dlaczego wygrywa model KEV + BOD 22-01

Wprowadzenie do problemu / definicja luki

8 stycznia 2026 r. CISA (amerykańska agencja ds. cyberbezpieczeństwa) zamknęła jednorazowo aż 10 Emergency Directives (ED) wydanych w latach 2019–2024. W praktyce to „sunset” oznacza, że dyrektywy zostały oznaczone jako zamknięte, bo spełniły swój cel, a wymagane działania są już zrealizowane albo zostały „wchłonięte” przez stały mechanizm zarządzania ryzykiem podatności: KEV (Known Exploited Vulnerabilities) + BOD 22-01.

Warto to czytać szerzej niż jako porządkowanie archiwum: to sygnał, że CISA coraz częściej preferuje ciągły model priorytetyzacji podatności (KEV), zamiast utrzymywania wielu osobnych, kryzysowych nakazów.

W skrócie

CISA zamknęła 10 Emergency Directives (2019–2024).
Powód: wymagania z dyrektyw są zrealizowane lub zastąpione przez obowiązki wynikające z BOD 22-01 i katalogu KEV.
Zamknięte ED dotyczyły m.in. głośnych incydentów/podatności: DNS tampering, SolarWinds Orion, Exchange on-prem, Pulse Connect Secure, Print Spooler, VMware, a także kompromitacji korporacyjnej poczty Microsoft.

Kontekst / historia / powiązania

Emergency Directive to tryb „awaryjny” — narzędzie do szybkiego wymuszenia działań w sytuacji pilnego ryzyka dla amerykańskich agencji federalnych (FCEB). Binding Operational Directive (BOD) jest natomiast mechanizmem „systemowym”: obowiązkową dyrektywą dla agencji federalnych, porządkującą działania w skali całego rządu USA.

Kluczowa zmiana ostatnich lat to przeniesienie ciężaru z reakcji „incydent → osobna dyrektywa” na model „ciągła lista realnie wykorzystywanych podatności + terminy remediacji”. Ten model spina BOD 22-01 i katalog KEV, gdzie priorytetem jest to, co jest faktycznie eksploatowane.

4. Analiza techniczna / szczegóły luki

Jakie 10 ED zostało zamkniętych?

Lista zamkniętych Emergency Directives (wg publikacji podsumowującej zamknięcie):

ED 19-01: Mitigate DNS Infrastructure Tampering
ED 20-02: Mitigate Windows Vulnerabilities from January 2020 Patch Tuesday
ED 20-03: Mitigate Windows DNS Server Vulnerability from July 2020 Patch Tuesday
ED 20-04: Mitigate Netlogon Elevation of Privilege Vulnerability from August 2020 Patch Tuesday
ED 21-01: Mitigate SolarWinds Orion Code Compromise
ED 21-02: Mitigate Microsoft Exchange On-Premises Product Vulnerabilities
ED 21-03: Mitigate Pulse Connect Secure Product Vulnerabilities
ED 21-04: Mitigate Windows Print Spooler Service Vulnerability
ED 22-03: Mitigate VMware Vulnerabilities
ED 24-02: Mitigating the Significant Risk from Nation-State Compromise of Microsoft Corporate Email System

Co je łączy technicznie?

To zestaw dyrektyw skupionych na dwóch klasach ryzyka:

A) „Powszechna technologia + szybka eksploatacja”
Windows/AD (Netlogon), DNS, Print Spooler, Exchange, Pulse Secure, VMware — czyli komponenty, które są masowo wdrażane i często bywają „single point of failure” w środowiskach enterprise.

B) „Incydenty o charakterze kampanii / supply chain / APT”
SolarWinds Orion i kompromitacja systemów pocztowych to przykłady zdarzeń, które wymuszają nie tylko patchowanie, ale też: triage, hunting, segmentację i zmianę praktyk operacyjnych.

Rola KEV: przeniesienie „co robić” do katalogu eksploatowanych CVE

CISA wskazała, że część zamykanych dyrektyw stała się redundantna, bo podatności trafiły do KEV (a więc podlegają reżimowi BOD 22-01). W artykułach o zamknięciu ED wymieniono m.in.: CVE-2020-0601, CVE-2020-1350, CVE-2020-1472, CVE-2021-26855, CVE-2021-34527, CVE-2021-22893 oraz wątek podatności VMware.

W praktyce: zamiast utrzymywać osobną „akcję specjalną” dla każdej dużej podatności, CISA woli dziś dopinać ją do mechanizmu KEV, gdzie kluczowe są terminy remediacji i ciągłe raportowanie postępu.

Praktyczne konsekwencje / ryzyko

Dla agencji federalnych USA: zamknięcie ED nie oznacza „temat nieaktualny”, tylko że działania zostały wykonane albo przechodzą na trwalszy reżim BOD/KEV.

Dla organizacji spoza FCEB (w tym w Polsce): to mocny sygnał trendu:

priorytetem nie jest „najwyższy CVSS”, tylko podatność z realną eksploatacją (KEV jako heurystyka ryzyka),
procesy bezpieczeństwa powinny działać ciągle, a nie falami po medialnych incydentach.

Ryzyko biznesowe pozostaje takie samo jak w latach, gdy wydawano ED: te klasy podatności (Exchange, VPN, AD/Netlogon, drukowanie, hypervisor/virtualization) regularnie wracają w kampaniach ransomware i APT, bo dają szybki efekt: dostęp, eskalację, lateral movement i trwałość.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań, który „mapuje się” na logikę KEV/BOD, nawet jeśli nie podlegasz CISA:

Zasada 1: KEV jako „fast lane” w VM
Wprowadź osobny tor obsługi podatności „known exploited”: krótsze SLA, automatyczne eskalacje, raportowanie do właścicieli usług.
Zasada 2: inwentaryzacja > skanowanie
Większość ED dotyczyła technologii, które często żyją poza standardowym VM (appliance VPN, stare serwery Exchange, klastry vSphere). Upewnij się, że masz rzetelną listę: co mam, gdzie jest, kto jest właścicielem, jak patchuję.
Zasada 3: kompensacje, gdy patch nie wchodzi
Jeśli nie możesz patchować: odcięcie ekspozycji, segmentacja, WAF/IPS reguły, twarde ograniczenie adminów, monitoring anomalii (np. nietypowe logowania, nowe konta, eksport skrzynek, podejrzane usługi).
Zasada 4: „security hygiene” dla tożsamości i zdalnego dostępu
ED-y historycznie często dotykały wejść do sieci (VPN, poczta) — wymuś MFA, ogranicz dostęp administracyjny, wprowadź JIT/JEA, przegląd ról, alerty na niestandardowe tokeny/sesje.
Zasada 5: ćwiczenia IR pod scenariusze z listy ED
Zrób tabletop/blue-team exercise dla: kompromitacji poczty, łańcucha dostaw (SolarWinds), przejęcia AD (Netlogon), RCE w appliance VPN, eskalacji przez Print Spooler.

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

Model „ED” to reakcja punktowa: szybki nakaz na konkretny problem i konkretne wymagania. Model „KEV + BOD 22-01” to reakcja ciągła: stały katalog exploitable + terminy + raportowanie, które skaluje się lepiej niż utrzymywanie wielu równoległych dyrektyw.

To jest dojrzałościowo podobne do ewolucji SOC:

od „gaszenia pożarów po alertach”
do „zarządzania ryzykiem i ekspozycją w trybie ciągłym”.

Podsumowanie / kluczowe wnioski

8 stycznia 2026 r. CISA zamknęła 10 Emergency Directives z lat 2019–2024.
Najważniejsza zmiana to przesunięcie ciężaru na KEV + BOD 22-01 jako stały mechanizm priorytetyzacji i egzekwowania remediacji.
Dla organizacji komercyjnych to czytelna wskazówka: w VM i patchingu warto formalnie wyróżniać „known exploited” jako kategorię o najwyższym priorytecie, niezależnie od samego CVSS.

Źródła / bibliografia

The Record (Recorded Future News): informacje o zamknięciu 10 ED, kontekst KEV i lista przykładowych CVE.
BleepingComputer: lista 10 zamkniętych ED oraz opis powiązania z BOD 22-01 i KEV.
NIST (CSRC) – prezentacja dot. BOD 22-01: definicja BOD, obowiązkowość dla agencji federalnych i opis podejścia „katalog KEV + terminy”.

Pakistan-linked APT36 (Transparent Tribe) uderza w indyjskie instytucje: nowa fala spear-phishingu i malware „ReadOnly/WriteOnly”

Wprowadzenie do problemu / definicja luki

Na przełomie 2025/2026 roku odnotowano kolejną kampanię cyber-szpiegowską wymierzoną w indyjskie organizacje rządowe, akademickie i „strategiczne”. Badacze przypisują ją grupie APT36, znanej też jako Transparent Tribe — aktorowi powiązanemu z Pakistanem, aktywnemu co najmniej od 2013 r.

Warto podkreślić: tu nie chodzi o pojedynczą „lukę” w sensie CVE, ale o łańcuch infekcji oparty na socjotechnice (spear-phishing) i dostarczaniu złośliwych plików, które uruchamiają wieloetapowe komponenty malware. To klasyczny model APT: długofalowy dostęp, rozpoznanie, eksfiltracja, a nie szybka monetyzacja.

W skrócie

Kampania startuje od spear-phishingu z archiwum ZIP, zawierającego plik podszywający się pod PDF.
Po otwarciu, ładunek dostarcza dwa komponenty malware nazwane ReadOnly i WriteOnly.
Funkcje obejmują m.in. zdalną kontrolę, kradzież danych, trwałą obserwację, zrzuty ekranu oraz monitorowanie schowka.
Zachowanie malware ma się dostosowywać do wykrytego oprogramowania AV na stacji ofiary.
To kolejny przykład ewolucji APT36, które w ostatnich latach chętnie wykorzystuje „zaufane” formaty plików i legalne usługi/infrastrukturę do ukrywania działań.

Kontekst / historia / powiązania

Transparent Tribe (APT36) jest opisane w MITRE ATT&CK jako grupa podejrzewana o powiązania z Pakistanem, historycznie celująca w organizacje dyplomatyczne, obronne i badawcze w Indiach oraz Afganistanie.

W ujęciu „taktyk i technik” MITRE wskazuje m.in. na typowe dla tej grupy podejścia: rejestrację domen podszywających się pod legalne serwisy, spear-phishing (załączniki i linki) oraz uruchamianie złośliwych plików przez użytkownika (user execution).

Z perspektywy ostatnich kampanii (2024–2025) widać też rosnący nacisk na:

nadużywanie usług chmurowych i komunikatorów w łańcuchu dostarczania i C2 (np. Telegram, Google Drive, Slack),
„sprytne” nośniki startowe (LNK, CPL, skróty, pliki udające dokumenty),
oraz dopracowywanie odporności na detekcję.

Analiza techniczna / szczegóły luki

1) Wejście: spear-phishing + ZIP + „PDF”

Według opisu kampanii, atak rozpoczyna się od wiadomości spear-phishingowych z archiwum ZIP, w którym znajduje się plik przebrany za dokument PDF. To celowy wybór: formaty „biurowe” i „dokumentowe” nadal mają wysoki współczynnik otwarć w środowiskach urzędowych i akademickich.

2) Payload: ReadOnly + WriteOnly (modułowość)

Po uruchomieniu pliku ofiara otrzymuje dwa komponenty złośliwego oprogramowania określane jako ReadOnly i WriteOnly. Z punktu widzenia obrony to istotne, bo rozdzielenie funkcji na moduły zwykle ułatwia:

etapowanie (najpierw „cichy” loader, potem funkcje szpiegowskie),
mieszanie technik w zależności od środowiska,
oraz utrudnianie analizy.

3) Zachowanie na hoście: adaptacja do AV i funkcje szpiegowskie

Opisane możliwości obejmują zdalne sterowanie, eksfiltrację danych i utrzymywanie obserwacji (surveillance). Wprost wymieniane są m.in. zrzuty ekranu, monitorowanie schowka i zdalny pulpit.

Szczególnie ważne jest monitorowanie schowka: ta technika bywa używana nie tylko do „podsłuchiwania” wklejanych fragmentów (np. haseł, danych z dokumentów), ale też do podmiany wartości kopiowanych przez użytkownika — w artykule wskazano nawet scenariusz „podmiany” przy transakcjach kryptowalutowych.

4) Dlaczego to APT, a nie „zwykły malware”?

Badacze podkreślają, że to kampania nastawiona na długoterminowy nadzór, a nie szybki zysk czy destrukcję. To spójne z profilem Transparent Tribe w MITRE (spear-phishing, infrastruktura, długofalowe kampanie).

Praktyczne konsekwencje / ryzyko

Dla organizacji publicznych i uczelni skutki są zwykle „ciche”, ale bardzo kosztowne:

wyciek dokumentów (plany, korespondencja, projekty badawcze),
dostęp do skrzynek i zasobów współdzielonych,
rekonesans pod ataki łańcuchowe (np. na podmioty powiązane),
utrata poufności przez zrzuty ekranu i monitoring aktywności użytkownika.

Dodatkowo, jeśli malware faktycznie dostosowuje zachowanie do zainstalowanego AV, to organizacje z „różnorodnym” parkiem endpointów mogą mieć nierówny poziom widoczności incydentu (część hostów wykryje, część nie).

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie ograniczają ryzyko przy kampaniach spear-phishingowych APT36 (bez czekania na „łatkę”):

Higiena poczty i załączników

Sandboxing załączników oraz URL-i (detonacja w izolacji).
Blokowanie/oznaczanie archiwów z podejrzanymi cechami (nietypowe rozszerzenia, pliki „udające PDF”, podejrzane skróty).
Wymuszenie ostrzeżeń dla ZIP z plikami wykonywalnymi / nietypowymi kontenerami.

Hardening stacji roboczych

Ogranicz uprawnienia użytkowników (least privilege).
Zablokuj uruchamianie podejrzanych typów plików z katalogów użytkownika (reguły ASR/EDR), a także nietypowe „launch chain” (np. dokument → interpreter/skrót → pobranie → wykonanie).

Detekcja i threat hunting

Poluj na nietypowe procesy związane z funkcjami szpiegowskimi: masowe zrzuty ekranu, nietypowe użycie schowka, anomalie w zdalnym dostępie.
Koreluj zdarzenia „user execution” po kliknięciu załącznika z późniejszym ruchem sieciowym (zwłaszcza do świeżych domen/usług pośrednich). MITRE wskazuje, że spear-phishing i infrastruktura domenowa to częsty wzorzec dla tej grupy.

Ograniczanie kanałów C2 i nadużyć chmury
Check Point pokazywał, że Transparent Tribe potrafi wykorzystywać popularne usługi (np. Telegram/Google Drive/Slack) w dystrybucji i C2. W praktyce oznacza to: segmentację, egress filtering i monitoring anomalii do usług chmurowych (zwłaszcza „nietypowych” dla danej roli endpointa).

Różnice / porównania z innymi przypadkami

Ta kampania (ZIP + „PDF” + ReadOnly/WriteOnly) wpisuje się w szerszy trend ewolucji Transparent Tribe:

Windows: rozwój niestandardowych RAT/loaderów i kanałów C2
Check Point opisał rozwój ElizaRAT oraz nadużycia usług chmurowych do dystrybucji i komunikacji, a także różne metody uruchomienia payloadu w kampaniach 2023–2024.
Linux: wykorzystywanie „desktop entry” i pozornie niegroźnych artefaktów
CloudSEK i Sekoia opisywały kampanie, w których phishing prowadził do uruchomienia złośliwych elementów w środowiskach linuksowych (np. poprzez pliki .desktop), a następnie do komunikacji C2 (m.in. WebSocket) i uruchomienia końcowego RAT.

Wspólny mianownik: socjotechnika + „zaufany” nośnik startowy + etapowanie + adaptacja i ukrywanie.

Podsumowanie / kluczowe wnioski

Nowa kampania przypisywana APT36/Transparent Tribe ponownie pokazuje, że spear-phishing pozostaje najskuteczniejszym „wektorem APT” przeciw administracji i nauce.
Komponenty ReadOnly/WriteOnly oraz deklarowana adaptacja do AV sugerują nacisk na utrzymanie się w środowisku i długofalową eksfiltrację.
Obrona nie powinna opierać się na jednym punkcie (np. AV), tylko na warstwach: bramka pocztowa, izolacja/sandbox, hardening endpointów, monitoring egress i polowanie na TTP.

Źródła / bibliografia (wybrane)

The Record (Recorded Future News) — opis kampanii, ReadOnly/WriteOnly, TTP, cele (2 stycznia 2026). (The Record from Recorded Future)
MITRE ATT&CK — profil grupy Transparent Tribe (G0134), techniki i kontekst. (MITRE ATT&CK)
Check Point Research — ewolucja malware APT36 (ElizaRAT), nadużycia usług chmurowych (4 listopada 2024). (Check Point Research)
Sekoia.io — analiza łańcucha infekcji i narzędzi w kampanii DeskRAT (23 października 2025). (Sekoia.io Blog)
CloudSEK — kampania APT36 z phishingiem ZIP i mechanizmem .desktop oraz rekomendacjami defensywnymi (21 sierpnia 2025). (CloudSek)

Ponad 10 tys. firewalli Fortinet wciąż podatnych na obejście 2FA: powrót CVE-2020-12812 w kampaniach ataków

Wprowadzenie do problemu / definicja luki

W styczniu 2026 r. ponownie głośno zrobiło się o CVE-2020-12812 – luce w FortiOS SSL VPN, która pozwala ominąć drugi składnik uwierzytelniania (FortiToken/2FA) w określonej konfiguracji. Co istotne, mimo że poprawki są dostępne od lipca 2020 r., w internecie nadal widać ponad 10 000 urządzeń Fortinet wystawionych na ataki wykorzystujące tę podatność.

CVE-2020-12812 to klasyczny przykład ryzyka na styku „patching + konfiguracja + urządzenia brzegowe”: nawet jeśli organizacja „ma 2FA”, błędne założenia o tym, jak działa dopasowanie tożsamości użytkownika (np. wielkość liter w loginie) mogą otworzyć furtkę.

W skrócie

Co to jest? Luka „improper authentication” w FortiOS SSL VPN, umożliwiająca zalogowanie bez wywołania drugiego składnika (2FA) po zmianie wielkości liter w nazwie użytkownika.
Jak poważna? CVSS v3.1: 9.8 (Critical).
Kogo dotyczy? Wg NVD m.in. FortiOS: 6.4.0, 6.2.0–6.2.3, 6.0.9 i niżej (naprawione odpowiednio w 6.4.1 / 6.2.4 / 6.0.10).
Czy to jest realnie wykorzystywane? Fortinet opublikował analizę „Observed Abuse” i potwierdził nadużycia w środowiskach produkcyjnych (grudzień 2025).
Skala ekspozycji: raporty monitoringu internetu wskazują na >10k niezałatanych urządzeń widocznych publicznie.

Kontekst / historia / powiązania

Choć CVE ma „2020” w nazwie, problem jest dziś aktualny z trzech powodów:

Urządzenia brzegowe (SSL VPN) są stale skanowane, a „stare” luki pozostają opłacalne, bo część organizacji nie aktualizuje firmware’u lub ma ograniczenia utrzymaniowe.
Konfiguracja jest kluczowa: ten bypass nie musi działać na każdym FortiGate – zwykle wymaga specyficznego zestawu ustawień związanych z LDAP i sposobem mapowania użytkowników.
CVE-2020-12812 znajduje się w kontekście szerszego trendu: SSL VPN (Fortinet i nie tylko) to „złota żyła” dla operatorów ransomware i grup APT, bo daje szybki dostęp do sieci wewnętrznej.

NVD wskazuje też, że ta podatność jest ujęta w katalogu Known Exploited Vulnerabilities (KEV) CISA (z datą dodania i terminem wymuszenia działań dla agencji federalnych USA).

Analiza techniczna / szczegóły luki

Sedno problemu: różnica w traktowaniu wielkości liter

Fortinet opisuje mechanizm bardzo konkretnie: FortiGate domyślnie traktuje nazwy użytkowników jako case-sensitive, podczas gdy LDAP/AD zazwyczaj nie. W określonej konfiguracji prowadzi to do sytuacji, w której zmiana wielkości liter w loginie powoduje „rozminięcie się” z lokalnym wpisem użytkownika na urządzeniu i ominięcie ścieżki 2FA.

Warunki podatności (prerequisites) – kiedy to działa?

Zgodnie z analizą Fortinet, organizacja musi mieć łącznie m.in.:

lokalne wpisy użytkowników na FortiGate z włączonym 2FA, które odwołują się do LDAP,
tych samych użytkowników w grupach na serwerze LDAP,
co najmniej jedną z tych grup skonfigurowaną na FortiGate i użytą w polityce uwierzytelniania (np. admin, SSL VPN, IPsec VPN).

Scenariusz obejścia 2FA

Fortinet podaje przykład:

logowanie jako jsmith → dopasowanie do lokalnego użytkownika → token jest wymagany,
logowanie jako Jsmith / jSmith itd. → brak dopasowania „case-exact” do lokalnego wpisu → FortiGate przechodzi do alternatywnych polityk uwierzytelniania i może uwierzytelnić użytkownika bez drugiego składnika.

To ważne operacyjnie: atakujący nie musi „łamać” 2FA kryptograficznie. Wykorzystuje logikę dopasowania tożsamości w łańcuchu auth.

Praktyczne konsekwencje / ryzyko

Jeśli SSL VPN jest wystawiony do internetu (a często jest), a konfiguracja spełnia warunki podatności, skutki mogą obejmować:

nieautoryzowany dostęp zdalny do sieci (wejście przez VPN),
eskalację (np. przez dostęp do zasobów wewnętrznych po VPN),
zwiększone ryzyko incydentów typu ransomware / human-operated intrusions, gdzie pierwszym krokiem jest stabilny dostęp do sieci ofiary.

Dodatkowo, obserwowana skala niezałatanych systemów (ponad 10 tys.) oznacza, że atakujący mogą prowadzić ciągłe, zautomatyzowane kampanie nastawione na „łatwe trafienia”.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań w kolejności, która zwykle daje najszybszy spadek ryzyka:

1) Ustal, czy jesteś w zakresie wersji podatnych

Według NVD podatność dotyczy m.in. FortiOS 6.4.0, 6.2.0–6.2.3, 6.0.9 i niżej; poprawki: 6.4.1+, 6.2.4+, 6.0.10+.

2) Sprawdź, czy masz „podatną konfigurację LDAP + local users + 2FA”

Zweryfikuj dokładnie warunki opisane przez Fortinet (lokalne wpisy z 2FA „wracające” do LDAP + grupy LDAP użyte w politykach auth).

3) Wprowadź mitigację konfiguracyjną (jeśli nie możesz natychmiast aktualizować)

Fortinet wskazuje wyłączenie wrażliwości na wielkość liter dla nazw użytkowników na kontach lokalnych (nazwy poleceń zależą od wersji).

Przykładowo (logika wg Fortinet – dostosuj do swojej wersji i standardów zmian):

# Na starszych wersjach (wg Fortinet)
set username-case-sensitivity disable

# Na nowszych wersjach (wg Fortinet: v6.0.13, v6.2.10, v6.4.7, v7.0.1+)
set username-sensitivity disable

4) Ogranicz ekspozycję SSL VPN i powierzchnię ataku

Jeśli możesz: nie wystawiaj SSL VPN publicznie (dostęp tylko z sieci zaufanych / przez bastion).
Wymuś allowlist IP, geofencing (jeśli sensowne biznesowo), oraz twarde reguły IDS/IPS na brzegach.

5) Wykrywanie i monitoring (quick wins)

Szukaj w logach prób logowania z nietypową kapitalizacją (Jsmith, jsmiTh) oraz wzorców „success bez token prompt”.
Koreluj zdarzenia VPN z nietypowych ASN/VPN hostingów i świeżymi kontami/zmianami w grupach LDAP.

Różnice / porównania z innymi przypadkami

CVE-2020-12812 jest inne niż wiele popularnych luk SSL VPN, bo to błąd logiczny w procesie auth, a nie typowe RCE. W praktyce jednak efekt bywa podobny: uzyskanie dostępu do brzegu sieci. Tenable zwraca uwagę, że równolegle (historycznie) mocno wykorzystywane były też inne luki Fortinet/SSL VPN (np. odczyt plików / path traversal), a „legacy VPN vulns” pozostają atrakcyjne dla APT i ransomware.

Wniosek: MFA nie jest „magiczną tarczą”, jeśli integracja tożsamości i polityki uwierzytelniania mają rozjazdy (tu: case-sensitivity).

Podsumowanie / kluczowe wnioski

CVE-2020-12812 to krytyczna luka (CVSS 9.8) w FortiOS SSL VPN, pozwalająca ominąć 2FA przez manipulację wielkością liter w loginie – ale tylko w określonej konfiguracji LDAP/2FA.
Fortinet potwierdził nadużycia w realnych atakach (grudzień 2025), a monitoring internetu wskazuje >10 tys. publicznie wystawionych, niezałatanych urządzeń.
Najskuteczniejsze działania „na już”: aktualizacja do wersji naprawionych + mitigacja case-sensitivity + ograniczenie ekspozycji SSL VPN.

Źródła / bibliografia

BleepingComputer – „Over 10K Fortinet firewalls exposed to actively exploited 2FA bypass” (02.01.2026) (BleepingComputer)
Fortinet PSIRT Blog – „Observed Abuse of FG-IR-19-283 / CVE-2020-12812” (24.12.2025) (Fortinet)
NVD (NIST) – karta podatności CVE-2020-12812 (opis, CVSS, wersje, KEV) (NVD)
Tenable – „Fortinet vulnerabilities targeted by APT actors” (08.04.2021) (Tenable®)

GlassWorm wraca w 4. fali: macOS na celowniku, a wtyczki VS Code próbują podmieniać aplikacje portfeli (Ledger/Trezor)

Wprowadzenie do problemu / definicja luki

GlassWorm to wielofalowa kampania typu supply chain wymierzona w ekosystem rozszerzeń Visual Studio Code (Microsoft Visual Studio Marketplace) oraz Open VSX (alternatywny, „vendor-neutral” rejestr używany m.in. przez edytory kompatybilne z VS Code). Atak polega na publikowaniu trojanizowanych rozszerzeń, które po instalacji uruchamiają kolejne etapy infekcji: kradzież tokenów i danych, instalację backdoora oraz – w najnowszej odsłonie – próbę podmiany aplikacji obsługujących portfele sprzętowe na wersje złośliwe.

Istotna zmiana w fali 4: po wcześniejszym skupieniu na Windows, kampania przeniosła ciężar na macOS (deweloperów), co ma sens operacyjny – to popularna platforma w software housach i środowiskach krypto/Web3.

W skrócie

Kogo atakują? Deweloperów na macOS instalujących zaufanie-budujące rozszerzenia VS Code/Open VSX.
Jak? 3 podejrzane rozszerzenia na Open VSX zawierają zaszyfrowany (AES-256-CBC) payload w skompilowanym JavaScript, uruchamiany po opóźnieniu ~15 minut.
Po co? Kradzież danych (tokeny GitHub/NPM, dane przeglądarki, Keychain), celowanie w portfele krypto (rozszerzenia i aplikacje desktop), a w fali 4 także mechanizm podmiany Ledger Live i Trezor Suite.
C2/odporność infrastruktury: utrzymany został mechanizm C2 oparty o blockchain Solana (dynamiczne wskazywanie endpointów).

Kontekst / historia / powiązania

Październik 2025: kampania została opisana jako atak wykorzystujący m.in. „niewidzialne” znaki Unicode do ukrycia złośliwego kodu w rozszerzeniach.
Kolejne fale: napastnicy wracali mimo nagłośnienia i usuwania złośliwych pozycji z marketplace’ów.
Reakcja ekosystemu: zespół Open VSX (Eclipse Foundation) podkreślał, że incydent został opanowany, usuwał złośliwe rozszerzenia i wprowadzał zmiany w zarządzaniu tokenami oraz skanowaniu publikacji.

W praktyce ta historia pokazuje typowy problem obrony w łańcuchu dostaw: nawet po „cleanupie” i wzmacnianiu kontroli, atakujący iterują techniki dostarczania (Unicode → binaria/kompilacja → szyfrowany JS + opóźnienia) i przenoszą cele na najbardziej „opłacalne” środowiska.

Analiza techniczna / szczegóły luki

1) Nośnik: złośliwe rozszerzenia (Open VSX / VS Code)

W fali 4 badacze wskazali trzy identyfikatory rozszerzeń (Open VSX), powiązane z macOS-owym łańcuchem infekcji:

studio-velte-distributor.pro-svelte-extension
cudra-production.vsce-prettier-pro
Puccin-development.full-access-catppuccin-pro-extension

2) Dostarczenie i unikanie detekcji: szyfrowanie + opóźnienie

Zamiast „niewidzialnego” Unicode, payload jest opakowany w AES-256-CBC i zaszyty w skompilowanym JavaScript. Dodatkowo logika wykonuje się po ok. 15 minutach, co utrudnia sandboxing (wiele automatycznych analiz dynamicznych kończy się szybciej).

3) macOS TTP: AppleScript + LaunchAgents + Keychain

W porównaniu do wcześniejszych podejść (np. PowerShell/Registry na Windows), fala 4 używa natywnych dla macOS mechanizmów:

AppleScript do wykonania etapów wstępnych,
LaunchAgents jako mechanizm persystencji,
próby pozyskania haseł z Keychain (w tym wskazywane jest też pozyskanie samej bazy Keychain).

4) C2 na blockchainie Solana (odporność na „takedown”)

Mechanizm C2 pozostaje kluczowym elementem kampanii: malware ma pobierać aktualne endpointy (np. URL) z danych powiązanych z aktywnością w sieci Solana, co utrudnia klasyczne blokowanie domen/serwerów „na sztywno”.

5) Eskalacja: podmiana aplikacji portfeli sprzętowych

Najbardziej niepokojący element fali 4: kod sprawdza obecność Ledger Live i Trezor Suite, a następnie ma próbować pobrać i zainstalować ich trojanizowane odpowiedniki (po usunięciu legalnej aplikacji). Badacze odnotowali też, że w momencie testów część endpointów mogła zwracać puste pliki, przez co sama podmiana mogła „cicho” nie dojść do skutku – ale mechanizm jest już gotowy.

Przykładowe IoC (wartości z publicznych analiz)

Podejrzane rozszerzenia: jak wyżej (3 ID).
Wskazywane IP infrastruktury (C2/eksfil): m.in. 45.32.151.157, 45.32.150.251 (oraz historycznie 217.69.11.60).
Portfel/identyfikator wykorzystywany w mechanizmie Solana-C2 (podawany przez badaczy): BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC.

Praktyczne konsekwencje / ryzyko

Ryzyko kradzieży tożsamości deweloperskiej: tokeny i dane dostępowe do GitHub/NPM mogą przełożyć się na kolejne kompromitacje (repozytoria, paczki, pipeline’y CI/CD).
Ryzyko finansowe (krypto): celowanie w portfele przeglądarkowe i desktopowe oraz eskalacja w stronę portfeli sprzętowych oznaczają potencjalnie wyższy „payoff” dla atakujących.
Ryzyko lateral movement i trwałej obecności: persystencja (LaunchAgents) + zdalny dostęp/pośrednictwo ruchu (historycznie opisywane jako VNC/SOCKS) może zmienić stację deweloperską w punkt wejścia do sieci firmowej.
Trudniejszy „takedown”: C2 oparte o Solanę komplikuje tradycyjne podejście „zablokuj domenę/serwer”.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SOC/IR i IT

Natychmiastowy audyt rozszerzeń VS Code na macOS (szczególnie instalowanych z Open VSX), z naciskiem na nowe/mało znane wydawców oraz „podejrzanie podobne” nazwy (np. podszywanie się pod popularne narzędzia typu formatter/theme).
Wymuś allow-listę rozszerzeń (organizacyjnie) i ogranicz możliwość instalacji z nieautoryzowanych marketplace’ów, jeśli to możliwe.
Hunting na macOS pod kątem persystencji: przegląd ~/Library/LaunchAgents oraz /Library/LaunchAgents, korelacja z czasem instalacji rozszerzeń VS Code.
Monitoring procesów i zachowań:
- nietypowe użycie osascript / AppleScript w kontekście VS Code,
- odwołania do narzędzia security i operacji na Keychain,
- nietypowe archiwizowanie/staging danych w katalogach tymczasowych (w analizach wskazywano staging w /tmp).
Blokady i detekcje sieciowe (z rozwagą): dodaj do watchlisty wskazywane IP/ścieżki eksfiltracji, ale traktuj je jako zmienne (Solana-C2 ułatwia rotację).
Rotacja sekretów: jeśli wykryjesz podejrzane rozszerzenia na endpointach deweloperskich, załóż kompromitację tokenów (GitHub PAT, NPM, SSH keys) i wykonaj kontrolowaną rotację oraz przegląd logów dostępu.

Dla deweloperów

Instaluj rozszerzenia tylko od zweryfikowanych wydawców i weryfikuj, czy linki/identyfikatory wydawcy zgadzają się z projektem.
Ogranicz uprawnienia i ekspozycję sekretów w środowisku developerskim (np. osobne konta, krótkie TTL tokenów, minimalne scope).
Jeśli używasz Ledger/Trezor: zwróć uwagę na nagłe reinstalacje/„aktualizacje” aplikacji i weryfikuj podpisy/pochodzenie instalatorów (szczególnie po instalacji nowych rozszerzeń).

Różnice / porównania z innymi przypadkami

Fale 1–2: nacisk na ukrywanie kodu przez „niewidzialne” Unicode (w tym klasy znaków, które potrafią umykać typowym ostrzeżeniom) i kradzież danych deweloperskich/krypto.
Fala 3: odejście od „niewidzialnego” kodu w stronę trudniejszych w analizie artefaktów (np. natywnych/kompilowanych), utrzymanie Solana-C2.
Fala 4 (teraz): pełny pivot na macOS + AES-256-CBC w JS + opóźnienie 15 min + LaunchAgents/Keychain oraz wyraźna eskalacja w stronę podmiany Ledger Live i Trezor Suite.

To nie jest „jednorazowy incydent marketplace’u”, tylko kampania, która iteruje TTP pod presją publikacji i działań porządkowych.

Podsumowanie / kluczowe wnioski

GlassWorm w 4. fali pokazuje, że deweloperskie marketplace’y są atrakcyjnym wektorem APT-like dla cyberprzestępców (skala + zaufanie + dostęp do sekretów).
Pivot na macOS i próby podmiany Ledger/Trezor to sygnał, że kampania celuje w środowiska o wysokiej wartości (krypto, Web3, startupy).
Obrona „perymetrem” i samymi IOC nie wystarczy: potrzebne są polityki instalacji rozszerzeń, kontrola sekretów i detekcja behawioralna na endpointach deweloperskich.

Źródła / bibliografia

KOI Security – GlassWorm Goes Mac: Fresh Infrastructure, New Tricks (29.12.2025). (koi.ai)
BleepingComputer – New GlassWorm malware wave targets Macs with trojanized crypto wallets (01.01.2026). (BleepingComputer)
Endor Labs – Invisible Threats and the Blind Spots of Security: How GlassWorm Exploited Unicode Shadows… (endorlabs.com)
Truesec – GlassWorm – Self-Propagating VSCode Extension Worm (21.10.2025). (Truesec)
SecurityWeek – Open VSX Downplays Impact From GlassWorm Campaign (31.10.2025). (SecurityWeek)