Archiwa: APT - Strona 16 z 32 - Security Bez Tabu

Tag: APT

Microsoft przejmuje serwery i rozbija RedVDS – jak działała abonamentowa platforma „cybercrime-as-a-service”

Wprowadzenie do problemu / definicja luki

RedVDS nie był „kolejnym botnetem” ani pojedynczą grupą APT. To model biznesowy: tani, abonamentowy dostęp do jednorazowych maszyn Windows, które cyberprzestępcy wykorzystywali jako infrastrukturę do phishingu, BEC (Business Email Compromise), przejęć kont i oszustw finansowych. Microsoft opisuje RedVDS jako element rosnącego ekosystemu cybercrime-as-a-service, gdzie przestępcy kupują gotowe usługi, zamiast budować zaplecze samodzielnie.

Klucz: taka „hurtowa” infrastruktura obniża próg wejścia. Za kwoty rzędu 24 USD/mies. można było uruchamiać operacje na skalę masową, płacąc kryptowalutami i redukując ślady.

W skrócie

  • Microsoft ogłosił skoordynowane działania prawne w USA oraz – po raz pierwszy w tym typie sprawy – w Wielkiej Brytanii, równolegle z operacją z udziałem organów ścigania (w tym niemieckich) i Europolu.
  • Przejęto kluczową infrastrukturę i zajęto dwie domeny obsługujące marketplace oraz portal klientów RedVDS.
  • Microsoft wiąże RedVDS z ok. 40 mln USD zgłoszonych strat w USA od marca 2025.
  • W „zaledwie jednym miesiącu” ponad 2 600 maszyn RedVDS wysyłało średnio 1 mln phishingowych wiadomości dziennie do klientów Microsoftu.
  • Od września 2025 aktywność wspierana przez RedVDS miała prowadzić do kompromitacji lub oszukańczego dostępu do ponad 191 tys. organizacji globalnie.

Kontekst / historia / powiązania

Z perspektywy obrony (SOC/CSIRT) RedVDS wpisuje się w trend „industrializacji” cyberprzestępczości: atakujący specjalizują się w wąskich fragmentach łańcucha (dostęp, phishing, pranie pieniędzy, infrastruktura), a resztę kupują w modelu usługowym.

Według Microsoft Threat Intelligence RedVDS działał publicznie od 2019 r., oferując serwery w wielu lokalizacjach (m.in. USA, UK, Kanada, Francja, Holandia, Niemcy) i używał kilku domen (m.in. redvds[.]com, redvds[.]pro, vdspanel[.]space).

Microsoft przypisuje rozwój i operowanie marketplace’em aktorowi śledzonemu jako Storm-2470 oraz wskazuje, że z infrastruktury korzystało wiele innych podmiotów (np. Storm-0259 i inne „Stormy”), co sugeruje, że RedVDS był „multitenantem” dla przestępców finansowych, a nie narzędziem jednej kampanii.

W komunikacji Microsoftu przewija się też wątek AI-enabled fraud: RedVDS miał być często łączony z generatywną AI do szybszego typowania celów i tworzenia bardziej wiarygodnych wątków korespondencji, a w części przypadków również z narzędziami deepfake (zamiana twarzy, manipulacja wideo, klonowanie głosu).

Analiza techniczna / szczegóły luki

1) „Disposable Windows” jako produkt

Rdzeniem oferty były tanie serwery Windows dostępne przez RDP z pełnymi uprawnieniami administratora i bez limitów użycia. To idealne środowisko do:

  • masowego wysyłania phishingu (w tym obejścia reputacji źródeł),
  • hostowania stron/landingów, paneli i kitów phishingowych,
  • prowadzenia BEC i „payment diversion” (podmiana rachunków, zmiana danych do przelewu),
  • przejęć kont i dalszego poruszania się po organizacjach.

2) „Palec odcisku” infrastruktury – klonowany obraz Windows

Microsoft opisuje ciekawy aspekt obronny: wiele instancji było tworzonych z jednego, klonowanego obrazu Windows Server 2022, co pozostawiało wykrywalne, powtarzalne artefakty. Przykład: ten sam computer name: WIN-BUNS25TD77J, widoczny m.in. w certyfikatach RDP i telemetrii. Legalni dostawcy chmury zwykle losują/unikalizują takie identyfikatory – tu tego zabrakło.

3) Automatyzacja provisioningu

Operator miał stosować QEMU i sterowniki VirtIO do szybkiego generowania klonów na żądanie klienta. Mechanika była prosta: kopiowanie „master VM” bez poprawnego sysprep/unikalizacji tożsamości systemu, co przyspieszało dostarczanie i obniżało koszty, ale jednocześnie zostawiało spójne ślady.

4) Warstwa utrudniania atrybucji

RedVDS sprzedawano z płatnością w kryptowalutach (Microsoft wymienia m.in. Bitcoin, Litecoin oraz szeroką listę innych) i z narracją o „podmiocie” rzekomo podlegającym prawu Bahamów – klasyczny zabieg zwiększający tarcie dla egzekwowania prawa i identyfikacji operatorów.

Praktyczne konsekwencje / ryzyko

Dlaczego ta historia jest ważna także dla organizacji, które „nie widzą” RedVDS u siebie? Bo usługi tego typu zmieniają ekonomię ataku:

  1. Skalowanie – atakujący nie muszą inwestować w własne serwery/botnety. W komunikacie Microsoftu pada skala: w jeden miesiąc 2 600 maszyn i średnio 1 mln phishingów dziennie do samych klientów Microsoftu.
  2. Szybka rotacja infrastruktury – „jednorazowe” maszyny można porzucić po kampanii, co utrudnia korelację i blokowanie per-IP.
  3. Lepszy social engineering – połączenie hostowanej infrastruktury + generatywnej AI (a czasem deepfake) zwiększa skuteczność BEC, szczególnie przy zmianach danych płatniczych.
  4. Straty finansowe – Microsoft wskazuje ok. 40 mln USD zgłoszonych strat w USA od marca 2025, a przykłady ofiar obejmują m.in. podmiot farmaceutyczny i wspólnotę mieszkaniową.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz”, które sensownie adresują ten typ zagrożeń (nie tylko RedVDS):

Dla zespołów IT/SOC

  • Wzmocnij polityki SPF/DKIM/DMARC i egzekwuj je (quarantine/reject), a w M365 dopnij ochrony anty-spoofingowe – Microsoft wskazuje, że aktorzy wykorzystywali złożone scenariusze routingu i błędne konfiguracje ochron.
  • Poluj na artefakty RDP/telemetrii: jeśli masz telemetryczne możliwości EDR/XDR, rozważ detekcje oparte o wskazane przez Microsoft charakterystyki klonów (np. powtarzalne elementy połączeń RDP/certyfikatów, fingerprint hosta).
  • Kontrola egress + reputacja: nie opieraj blokad wyłącznie o statyczne listy IP – przy „disposable infra” potrzebujesz korelacji zachowań (nietypowe logowania, masowe wysyłki, anomalie w OAuth).
  • Włącz i wymuś MFA odporne na phishing (FIDO2/passkeys, auth-app z number matching) na kontach uprzywilejowanych i finansowych. BEC to gra o przejęcie skrzynki i manipulację płatnością.

Dla finansów, zakupów i operacji

  • Proces „out-of-band verification”: każda zmiana numeru rachunku/beneficjenta musi być potwierdzona innym kanałem (telefon na znany numer, wideoweryfikacja, portal dostawcy).
  • Dwustopniowa autoryzacja przelewów i limity kwotowe z dodatkowymi kontrolami dla „pierwszego przelewu na nowy rachunek”.
  • Szkolenia na BEC oparte o realne scenariusze (pilne faktury, zmiany rachunku, „CEO fraud”) – RedVDS był wykorzystywany właśnie do takich schematów.

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

RedVDS warto zestawić z wcześniejszymi „takedownami” w modelu usługowym:

  • Phishing-as-a-Service vs Infrastructure-as-a-Service: przejęcie paneli/phishing kitów (PhaaS) ogranicza „narzędzie”, ale infrastruktura w stylu RedVDS to uniwersalny mnożnik – obsłuży phishing, BEC, hosting scamów i wiele innych działań naraz.
  • Wielu aktorów, jedna platforma: Microsoft wprost wskazuje, że z RedVDS korzystały różne „Stormy”, więc uderzenie w usługę ma szansę ograniczyć działalność całego ekosystemu klientów.
  • Legal + technika: kluczowy jest miks działań prawnych (USA i UK) oraz zajęć infrastruktury/domen, bo bez przejęcia marketplace’u i panelu klienta atakujący zwykle po prostu migrują.

Podsumowanie / kluczowe wnioski

Rozbicie RedVDS pokazuje, że współczesna cyberprzestępczość coraz częściej działa jak SaaS: tanio, masowo i z automatyzacją. Dla obrońców najważniejsze są dwa wnioski:

  1. Nie walczysz tylko z „atakującym”, ale z jego łańcuchem dostaw. Uderzenie w infrastrukturę-usługę może obniżyć tempo i skalę wielu kampanii naraz.
  2. BEC i phishing nie znikną po jednym takedownie. Trzeba domykać procesy (weryfikacja płatności) i technikę (MFA odporne na phishing, ochrona przed spoofingiem, detekcje anomalii).

Źródła / bibliografia

  1. Microsoft – Microsoft disrupts global cybercrime subscription service… (14 stycznia 2026) (The Official Microsoft Blog)
  2. Microsoft Threat Intelligence – Inside RedVDS: How a single virtual desktop provider fueled worldwide cybercriminal operations (14 stycznia 2026) (Microsoft)
  3. BleepingComputer – Microsoft seizes servers, disrupts massive RedVDS cybercrime platform (15 stycznia 2026) (BleepingComputer)
  4. Microsoft News (EMEA, DE) – komunikat prasowy dot. RedVDS (styczeń 2026) (Source)
  5. CyberScoop – kontekst współpracy z organami ścigania i Europolem (14 stycznia 2026) (CyberScoop)

UAT-8837: chińsko-powiązany aktor APT poluje na dostęp początkowy w sektorach infrastruktury krytycznej w Ameryce Północnej

Wprowadzenie do problemu / definicja luki

Cisco Talos opisuje UAT-8837 jako aktora APT o średnim poziomie pewności powiązań z Chinami, którego główną rolą wydaje się być pozyskiwanie dostępu początkowego (initial access) do organizacji o wysokiej wartości — a niekoniecznie prowadzenie pełnej kampanii destrukcyjnej czy ransomware. To ważne rozróżnienie: initial-access skupia się na wejściu, rozpoznaniu, kradzieży poświadczeń i „poręczach” do ponownych wejść, często przygotowując grunt pod kolejne etapy działań (także innych zespołów).

W tle pojawia się też wątek eksploatacji podatności CVE-2025-53690 (Sitecore, deserializacja ViewState), co sugeruje dostęp do świeżych technik/łańcuchów eksploatacyjnych i sprawność w szybkim monetyzowaniu błędów w systemach publicznie wystawionych.

W skrócie

  • Kto? UAT-8837 — Talos: medium confidence China-nexus APT.
  • Kogo atakuje? Od co najmniej 2025 r. wyraźny fokus na organizacjach z obszaru infrastruktury krytycznej w Ameryce Północnej.
  • Jak wchodzi? Eksploatacja podatnych serwerów (n-day i zero-day) oraz użycie przejętych poświadczeń.
  • Co robi po wejściu? Recon + kradzież informacji o domenie/AD + budowa wielu kanałów dostępu, głównie narzędziami open-source (Earthworm, SharpHound, DWAgent, Certipy itd.).
  • Detekcja/coverage: Talos podaje m.in. sygnaturę ClamAV (Win.Malware.Earthworm) i zestaw SID-ów Snort.
  • IOC: Talos publikuje hashe narzędzi oraz adresy IP infrastruktury (przykłady niżej).

Kontekst / historia / powiązania

Talos wskazuje na nakładanie się TTP UAT-8837 z innymi grupami z „chińskiego ekosystemu” (China-nexus), ale jednocześnie zaznacza medium confidence — co w praktyce oznacza: są przesłanki behawioralne i operacyjne, jednak atrybucja nie jest przedstawiona jako „zamknięta”.

Warto też zauważyć, że CVE-2025-53690 ma dobrze udokumentowany kontekst operacyjny: w analizie Google Cloud/Mandiant opisano realne nadużycia ViewState prowadzące do RCE w określonych wdrożeniach Sitecore (m.in. przypadki użycia przykładowego machine key z historycznych guide’ów).

Analiza techniczna / szczegóły luki

Wejście: podatności + konta

Talos opisuje dwa dominujące wektory initial access:

  1. Eksploatacja serwerów (w tym przypadek CVE-2025-53690).
  2. Użycie skompromitowanych poświadczeń.

Wczesny recon i „hands-on-keyboard”

Po uzyskaniu przyczółka operatorzy wykonują klasyczny zestaw komend rozpoznawczych (procesy, połączenia, użytkownicy, host, sesje) i przechodzą do działań interaktywnych na hoście (cmd.exe).

Istotny detal: Talos widzi wyłączanie mechanizmu RestrictedAdmin dla RDP poprzez modyfikację rejestru (po to, by ułatwić pozyskanie/wykorzystanie poświadczeń przy zdalnym dostępie).

Staging: gdzie lądują narzędzia

Talos wskazuje katalogi intensywnie wykorzystywane do „magazynowania” artefaktów:

  • C:\Users\<user>\Desktop\
  • C:\Windows\Temp\
  • C:\Windows\Public\Music

Toolchain: narzędzia i ich rola

UAT-8837 bazuje w dużym stopniu na narzędziach publicznych i miesza warianty, gdy są blokowane przez EDR/EPP (Talos wprost sugeruje „cycling” wersji narzędzi).

Najważniejsze elementy łańcucha po kompromitacji (wg Talos):

  • GoTokenTheft – kradzież tokenów dostępu i wykonywanie działań z podniesionymi uprawnieniami (Talos opisuje lokalizację i kontekst użycia).
  • Earthworm – tunelowanie/ruch typu reverse tunnel, wystawianie zasobów wewnętrznych na infrastrukturę atakującego (Talos podaje przykładowe komendy reverse socks/tunnel).
  • DWAgent – zdalna administracja, utrzymanie dostępu i „dropowanie” kolejnych elementów.
  • SharpHound + Certipy – rozpoznanie AD i elementy nadużyć wokół AD/PKI.
  • Impacket / Invoke-WMIExec / GoExec – próby zdalnego wykonania i lateral movement (w tym WMI/DCOM).
  • Rubeus – zestaw narzędzi do nadużyć Kerberos.

Recon domeny i AD

Talos pokazuje zestawy komend typu net group, nltest, setspn, a także wykorzystanie dsquery/dsget do masowego wyciągania atrybutów użytkowników i kont serwisowych — to klasyczny etap przygotowania do eskalacji uprawnień oraz polowania na „bogate” konta.

Utrzymanie dostępu: konta-tylne-furtki

Wprost opisano tworzenie kont domenowych (lub dodawanie istniejących kont do grup) jako kolejnego kanału powrotu do środowiska.

Sygnalizowany wątek supply chain

Talos odnotowuje przypadek eksfiltracji bibliotek DLL powiązanych z produktami ofiary, sugerując ryzyko przyszłego „trojanizowania” lub reverse engineeringu pod kątem kolejnych podatności — to szczególnie niepokojące w kontekście dostawców dla infrastruktury krytycznej.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko trwałej obecności: DWAgent + nowe konta + tunele to przepis na wiele niezależnych ścieżek powrotu.
  2. Ryzyko eskalacji domenowej: recon AD (SharpHound/Certipy/Rubeus) często poprzedza przejęcie kluczowych tożsamości i kontrolę nad środowiskiem.
  3. Ryzyko lateral movement: WMI/DCOM i RDP (wspierane zmianami w rejestrze) zwiększają zasięg intruza.
  4. Ryzyko dla systemów wystawionych do Internetu: CVE-2025-53690 dotyczy Sitecore i została opisana jako podatność typu deserializacja niezaufanych danych prowadząca do code injection; NVD wskazuje też, że CVE znalazło się w katalogu KEV CISA.
  5. Ryzyko łańcucha dostaw / własności intelektualnej: eksfiltracja DLL może zwiastować kolejne kampanie (np. „podmiana” komponentów lub szukanie błędów w produktach).

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: ogranicz initial access

  • Zidentyfikuj internet-facing systemy (szczególnie CMS/aplikacje web) i porównaj z podatnościami/konfiguracjami ryzykownymi (dla Sitecore: wątek ViewState/machine key i zalecenia producenta/analizy Mandiant).
  • Wymuś higienę tożsamości: MFA wszędzie, gdzie to możliwe; rotacja haseł uprzywilejowanych; detekcja anomalii logowania i „impossible travel”.

Priorytet 2: polowanie na zachowania i artefakty (TTP > IOC)

  • Monitoruj modyfikacje klucza rejestru dot. DisableRestrictedAdmin (zmiany pod RDP) oraz nietypowe uruchomienia cmd.exe/narzędzi administracyjnych na serwerach aplikacyjnych.
  • Kontrola staging paths: alarmuj na nowe binaria/skrypty w C:\Windows\Temp\ i C:\Windows\Public\Music, zwłaszcza gdy pliki udają .ico/.txt, a w praktyce są wykonywalne.
  • AD hunting: wykrywanie masowego dsquery/dsget, setspn -Q */*, nietypowych zapytań o membershipy i atrybuty kont serwisowych.
  • Account governance: alertuj na net user ... /add /domain, dodawanie kont do lokalnych grup administracyjnych i zmiany w grupach domenowych.

Priorytet 3: detekcje sieciowe i endpointowe

  • Jeśli używasz Snort, zweryfikuj wdrożenie wskazanych SID-ów (Snort 2 i Snort 3) oraz aktualność feedów.
  • Dla AV/anty-malware: Talos wskazuje sygnaturę ClamAV Win.Malware.Earthworm.

Priorytet 4: szybkie sprawdzenie IOC (punkt startowy)

Talos publikuje m.in. hashe i IP powiązane z aktywnością. Przykładowe elementy do natychmiastowego „sweepu”:

  • IP: 74[.]176[.]166[.]174, 20[.]200[.]129[.]75, 172[.]188[.]162[.]183, 4[.]144[.]1[.]47, 103[.]235[.]46[.]102
  • SHA-256 (wybrane):
    • 1b3856e5d8c6a4cec1c09a68e0f87a5319c1bd4c8726586fd3ea1b3434e22dfa (GoTokenTheft)
    • 451e03c6a783f90ec72e6eab744ebd11f2bdc66550d9a6e72c0ac48439d774cd (Earthworm)
    • 5090f311b37309767fb41fa9839d2770ab382326f38bab8c976b83ec727e6796 (SharpHound)
    • 887817fbaf137955897d62302c5d6a46d6b36cb34775e4693e30e32609fb6744 (GoExec)

Uwaga praktyczna: IOC traktuj jako „wskazówkę”, a nie wyrocznię — kluczowe jest wykrywanie zachowań (tunelowanie, recon AD, tworzenie kont, staging w publicznych katalogach), bo UAT-8837 ma obserwowaną skłonność do rotowania narzędzi.

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

  • Model działania „initial access-first” jest charakterystyczny dla kampanii, które chcą utrzymać długoterminowy dostęp i opcjonalnie przekazać „wejście” dalej (wewnętrznie lub zewnętrznie), zamiast od razu wdrażać destrukcję. W materiale Talos to mocno wybrzmiewa: narzędzia, recon, AD, wiele kanałów dostępu.
  • Wysoka adaptacyjność narzędziowa (cycling wariantów pod EDR) to element, który w praktyce obniża skuteczność statycznych blokad hash/opis i podnosi znaczenie telemetrii behawioralnej.
  • CVE-2025-53690 wyróżnia się tym, że doczekało się szczegółowego opisu łańcucha ataku (ViewState, machine key, RCE) oraz zostało ujęte w NVD wraz z informacją o obecności w KEV CISA — co w wielu organizacjach powinno automatycznie windować priorytet patch/mitigation.

Podsumowanie / kluczowe wnioski

UAT-8837 to przykład aktora, który systematyzuje wejście i utrzymanie dostępu, a po kompromitacji szybko przechodzi do rekonesansu i „porządkowania” Active Directory pod dalsze operacje. Jeśli Twoja organizacja ma elementy łańcucha dostaw dla infrastruktury krytycznej (lub sama do niej należy), ten profil działań jest szczególnie ryzykowny: już sama kradzież konfiguracji, poświadczeń i komponentów (np. DLL) może stworzyć warunki pod kolejne fale ataków.

Najbardziej opłacalne działania obronne to: twarde ograniczenie initial access (patch + redukcja powierzchni + tożsamość), detekcja zachowań w AD i na serwerach, oraz szybkie „sweepy” IOC jako wsparcie, nie fundament strategii.

Źródła / bibliografia

  1. Cisco Talos: UAT-8837 targets critical infrastructure sectors in North America (15 stycznia 2026). (Cisco Talos Blog)
  2. Google Cloud / Mandiant: ViewState Deserialization Zero-Day Vulnerability in Sitecore Products (CVE-2025-53690) (3 września 2025). (Google Cloud)
  3. NIST NVD: CVE-2025-53690 Detail (publikacja 3 września 2025; KEV CISA odnotowane na stronie CVE). (NVD)
  4. Materiał referencyjny nt. sektorów infrastruktury krytycznej (16 sektorów, PPD-21) — kopia treści CISA w formie PDF. (cdn.lawreportgroup.com)

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:

  1. Spearphishing / wiadomość z linkiem (często przez skracacze URL),
  2. wielostopniowe przekierowania przez usługi pośredniczące,
  3. krótka prezentacja legalnej przynęty PDF w przeglądarce (element „uśpienia czujności”),
  4. przekierowanie na fałszywy portal logowania,
  5. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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)

  1. 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.
  2. 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.
  3. 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

  1. Cisco Talos – analiza UAT-7290 (RushDrop/DriveSwitch/SilentRaid, ORB). (Cisco Talos Blog)
  2. BleepingComputer – omówienie raportu Talos i podsumowanie arsenalu. (BleepingComputer)
  3. The Hacker News – streszczenie + kontekst (MystRodX, Bulbature, overlap). (The Hacker News)
  4. Sekoia.io – Bulbature/ORB jako model operacyjny na kompromitowanych edge urządzeniach. (Sekoia.io Blog)
  5. 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):

  1. ED 19-01: Mitigate DNS Infrastructure Tampering
  2. ED 20-02: Mitigate Windows Vulnerabilities from January 2020 Patch Tuesday
  3. ED 20-03: Mitigate Windows DNS Server Vulnerability from July 2020 Patch Tuesday
  4. ED 20-04: Mitigate Netlogon Elevation of Privilege Vulnerability from August 2020 Patch Tuesday
  5. ED 21-01: Mitigate SolarWinds Orion Code Compromise
  6. ED 21-02: Mitigate Microsoft Exchange On-Premises Product Vulnerabilities
  7. ED 21-03: Mitigate Pulse Connect Secure Product Vulnerabilities
  8. ED 21-04: Mitigate Windows Print Spooler Service Vulnerability
  9. ED 22-03: Mitigate VMware Vulnerabilities
  10. 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:

  1. 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.
  2. 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ę.
  3. 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).
  4. 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.
  5. 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

  1. The Record (Recorded Future News): informacje o zamknięciu 10 ED, kontekst KEV i lista przykładowych CVE.
  2. BleepingComputer: lista 10 zamkniętych ED oraz opis powiązania z BOD 22-01 i KEV.
  3. 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ę”):

  1. 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.
  1. 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).
  1. 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.
  1. 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)

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