Archiwa: Linux - Strona 47 z 52 - Security Bez Tabu

CVE-2011-0609 — Adobe Flash/Reader (Authplay) RCE w kampaniach spear‑phishingowych

TL;DR

Krytyczny błąd w Adobe Flash Player oraz w komponencie Authplay bibliotek Adobe Reader/Acrobat (CVE‑2011‑0609) umożliwiał zdalne wykonanie kodu przez spreparowane pliki SWF. W 2011 r. był aktywnie wykorzystywany w atakach z załącznikami XLS (osadzony SWF), m.in. w incydencie RSA SecurID. Detekcja: korelacja Email → Office/Reader → podejrzany child‑process/C2, blokada starych Flash/Reader, sandboxing załączników.


Krótka definicja techniczna

CVE‑2011‑0609 to luka (memory corruption/unspecified) w Adobe Flash Player 10.2.154.13 i starszych (Windows/macOS/Linux/Solaris, Android), Adobe AIR 2.5.1 i starszych oraz w Authplay.dll/AuthPlayLib.bundle używanym przez Adobe Reader/Acrobat 9.x–9.4.2 oraz 10.x–10.0.1. Otwarcie złośliwego SWF (np. osadzonego w pliku Excel) skutkuje RCE w kontekście aplikacji.


Gdzie występuje / przykłady platform

  • Windows / macOS / Linux / Solaris (endpointy) — przeglądarki i Office/Reader ładujące wtyczkę Flash/komponent Authplay.
  • Android (mobile) — podatne wydania Flash 10.1.106.16 i starsze.
  • Active Directory — punkt rozprzestrzenienia po początkowym foothold; nie jest bezpośrednio podatne.
  • M365 — wektor mailowy (Exchange/Defender for Office 365: Safe Attachments/Safe Links, Message trace).
  • AWS/Azure/GCP — brak bezpośredniej podatności; możliwa telemetria z WorkMail/SES/WorkSpaces, VPC Flow/Firewall do korelacji C2.
  • Kubernetes/ESXi — nie dotyczy bezpośrednio; przydatne do detekcji lateral movement po inicjalnym włamaniu.
    (Flash i Authplay są EOL; nadal warto utrzymywać detekcję retro/archiwalną dla threat huntingu i IR).

Szczegółowy opis techniki (jak działa, cele, skuteczność)

Ataki wykorzystywały SWF z exploitem osadzony w pliku .xls wysyłanym jako spear‑phishing. Po otwarciu arkusza Excel ładował komponent Flash/ActiveX, wykonywał payload w pamięci i uruchamiał proces podrzędny (np. dropper/loader), typowo ustanawiający łączność C2 i dogrywający RAT (w publicznych opisach wskazywano m.in. Poison Ivy). W kampanii na RSA załącznik o nazwie “2011 Recruitment plan.xls” prowadził do kradzieży poufnych danych SecurID. Ta taktyka była skuteczna z powodu: zaufania do dokumentów Office, łańcucha User Execution → Client Exploitation, braku patchy i ograniczonej widoczności korelacyjnej między warstwą e‑mail, procesami na hoście i ruchem sieciowym.


Artefakty i logi (tabela — EID, CloudTrail, K8s audit, M365)

KategoriaŹródłoID/OperacjaWzorzec / PolaCo oznacza
WindowsSysmonEID 1 (ProcessCreate)ParentImage in (EXCEL.EXE,AcroRd32.exe,WINWORD.EXE) + Image in (cmd.exe,powershell.exe,wscript.exe,mshta.exe,rundll32.exe)Nietypowe child‑procesy po otwarciu dokumentu/Readera (wskaźnik exploit→payload).
SysmonEID 3 (NetworkConnect)ParentImage jak wyżej; dest na świeże domeny/DGA/dynamic DNSWczesne C2 po exploitacji.
SysmonEID 7 (ImageLoaded)ImageLoaded endswith authplay.dll / Flash*.ocx z nieaktualnych ścieżekŁadowanie wrażliwego komponentu.
SysmonEID 11 (FileCreate)Tworzenie dropperów w %APPDATA%, %TEMP% (np. *.tmp, *.dat)Artefakty pierwszego etapu.
Windows Security4688Jak EID 1 (jeśli brak Sysmon)Procesy uruchomione przez Office/Reader.
Windows PowerShell4104Nieoczekiwane skrypty po otwarciu plikuWskaźnik T1059.
M365Defender for Office 365EmailEventsAttachmentExtension="xls" + ThreatTypes/MalwareVerdict + DetectionMethod=SafeAttachmentsZatrzymane/wykryte załączniki ze SWF/osadzonymi obiektami.
Unified Audit LogMailItemsAccessed/SendKorelacja adresatów/wątków phishingowychZasięg kampanii.
Proxy/DNSSecure Web Gateway / resolverUser-Agent Office/Reader → outbound, świeże domeny, nietypowe SNIPotwierdzenie C2 po otwarciu dokumentu.
AWS (telemetria)CloudWatch/VPC FlowNietypowe wyjścia z hostów WorkSpaces/EC2 po zdarzeniu e‑mailKorelacja sieciowa (brak bezpośredniego CloudTrail dla kontentu maili).
CloudTrail[brak danych / nie dotyczy] — CloudTrail nie rejestruje zawartości załącznikówUżyć WorkMail Message Flow/SES logs, VPC Flow.
K8s audit[brak danych / nie dotyczy]Dotyczy etapów późniejszych (lateral movement), nie samej CVE.

Detekcja (praktyczne reguły)

Sigma (Windows — Office/Reader uruchamia interpreter/shell po Flash/Authplay)

title: Office/Reader Suspicious Child Process (CVE-2011-0609 Tradecraft)
id: 6c6f3a3c-8f8c-4f2e-91c3-ofs-cve20110609
status: stable
description: Wykrywa uruchomienie interpreterów/shelli przez EXCEL/AcroRd32/Word – wzorzec obserwowany w eksploatacji SWF/Authplay (2011).
author: Badacz CVE
date: 2025/11/05
logsource:
  product: windows
  category: process_creation
detection:
  parent_office:
    ParentImage|endswith:
      - '\EXCEL.EXE'
      - '\AcroRd32.exe'
      - '\WINWORD.EXE'
  suspicious_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: parent_office and suspicious_child
falsepositives:
  - Dodatki/plug‑iny wywołujące narzędzia systemowe (rzadkie)
level: high
tags:
  - attack.t1204.002
  - attack.t1203
  - attack.t1059
  - cve.2011.0609

Splunk (Sysmon EID 1 + 3)

index=endpoint (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
| where like(ParentImage,"%\\EXCEL.EXE") OR like(ParentImage,"%\\AcroRd32.exe") OR like(ParentImage,"%\\WINWORD.EXE")
| where match(Image,"(?i)\\(cmd|powershell|wscript|cscript|mshta|rundll32)\\.exe$")
| stats earliest(_time) as firstSeen latest(_time) as lastSeen values(CommandLine) values(ParentCommandLine) by Computer, Image, ParentImage, ParentProcessGuid, ProcessGuid
| join type=left ProcessGuid
    [ search index=endpoint sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
      | stats values(DestinationIp) values(DestinationHostname) by ProcessGuid ]
| sort - lastSeen

KQL (Defender for Endpoint + MDO korelacja)

// 1) Host: podejrzane child-procesy po Office/Reader
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("EXCEL.EXE","AcroRd32.exe","WINWORD.EXE")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","mshta.exe","rundll32.exe")

// 2) E-mail: załączniki .xls ze złą reputacją
let suspiciousMail =
EmailEvents
| where AttachmentCount > 0 and tostring(AttachmentExtensions) has_cs "xls"
| where ThreatTypes has_any ("Malware","Phish") or MalwareFilterVerdict in~ ("Malware","HighConfMalware");
suspiciousMail
| project NetworkMessageId, RecipientEmailAddress, SenderFromDomain
| join kind=innerunique (
  DeviceProcessEvents
  | where InitiatingProcessFileName in~ ("EXCEL.EXE","AcroRd32.exe")
  | project Timestamp, DeviceId, InitiatingProcessParentCreationTime, InitiatingProcessFileName, FileName, ProcessCommandLine, NetworkMessageId
) on NetworkMessageId

AWS (CloudWatch Logs Insights — Amazon WorkMail Message Flow / alternatywnie SES)

Jeśli używasz Amazon WorkMail/SES z loggingiem do CloudWatch/S3:

fields @timestamp, fromAddress, recipient, attachmentExtension, malwareVerdict, attachmentMimeType
| filter attachmentExtension="xls"
| filter malwareVerdict="MALICIOUS"
  or like(attachmentMimeType, "%shockwave%")
  or like(attachmentMimeType, "%flash%")
| sort @timestamp desc

(CloudTrail nie zawiera treści e‑maili; użyj WorkMail Message Flow / SES event logs oraz VPC Flow do wskazania ewentualnego C2).

Elastic / EQL

process where
  process.parent.name in ("EXCEL.EXE","AcroRd32.exe","WINWORD.EXE") and
  process.name in ("cmd.exe","powershell.exe","wscript.exe","mshta.exe","rundll32.exe")

Heurystyki / korelacje

  • Łańcuch czasowy: Email (.xls z osadzonym SWF) → uruchomienie Office/Reader → child‑process → połączenie sieciowe do świeżej domeny → zapis droppera w %TEMP%/%APPDATA%.
  • Artefakty Flash/Authplay: ładowanie authplay.dll/Flash*.ocx przez Office/Reader w momencie otwarcia pliku.
  • Pola do pivotowania: NetworkMessageIdDeviceProcessEvents ↔ proxy/DNS; hash załącznika ↔ sandbox verdict.
  • Treść socjotechniki: tematy rekrutacyjne/HR (“Recruitment plan”), krótka treść maila zachęcająca do otwarcia załącznika.

False positives / tuning

  • Legalne dodatki Office/Reader mogą incydentalnie uruchamiać narzędzia systemowe (rzadkie).
  • Zastosuj tuning po wersjach: skup się na hostach, gdzie w telemetrycznych śladach widać obiekty Flash/Authplay lub historyczne wersje Reader/Flash (jeśli utrzymywane w VDI/legacy).
  • Kontekst e‑mail: preferuj zdarzenia z verdictem Malware/High‑confidence lub z sandboxu (MDO Safe Attachments/3rd‑party).
  • Sieć: ogranicz alerty tylko do outbound na świeże/dynamiczne domeny i/lub niedawno zarejestrowane certyfikaty.

Playbook reagowania (IR)

  1. Triage & izolacja hosta (EDR isolate/quarantine).
  2. Zabezpieczenie artefaktów: hash i kopia pliku .xls, volatile data (listy procesów, połączenia, moduły).
    • Windows (PowerShell, konto z uprawnieniami IR): Get-Process EXCEL,AcroRd32 -IncludeUserName Get-ChildItem $env:TEMP | Sort LastWriteTime -desc | Select -First 20 Get-FileHash "C:\Path\to\Attachment.xls" -Algorithm SHA256
  3. Hunting w skali organizacji: IOC = hash załącznika / domeny C2 / temat maila; wyszukaj w EmailEvents/MessageTrace i w EDR.
  4. Blokady: reguła w Secure Email Gateway/MDO na typ załączników (XLS z OLE/ActiveX), blokada starych komponentów Flash/Authplay.
  5. Eradykacja: usuń dropper/RAT, unieważnij poświadczenia z hosta, sprawdź persistence (usługi/Run Keys/Tasks).
  6. Lessons learned: wdroż patch‑management, makra ograniczone, otwieranie załączników w izolacji (sandbox/VDI).

Przykłady z kampanii / case studies

  • Incydent RSA SecurID (marzec 2011): spear‑phishing z „2011 Recruitment plan.xls”, osadzony SWF wykorzystał CVE‑2011‑0609, po czym doinstalowano backdoor (m.in. raportowano Poison Ivy) i kradziono dane związane z SecurID.
  • Wnioski branżowe: Adobe ostrzegało o aktywnej eksploatacji w ukierunkowanych atakach; aktualizacje zostały opublikowane w drugiej połowie marca 2011 r.

Lab (bezpieczne testy) — przykładowe komendy

Cel: zweryfikować, czy Twoje detektory wychwytują łańcuch Email/Office → child‑process/C2 bez używania realnego exploita.

  • Test 1 (host): z poziomu kontenera testowego/VDI uruchom kontrolowany child‑process z Office (np. otwarcie pliku, który uruchamia calc/whoami przez zgodny z polityką add‑in) i sprawdź, czy reguły Sigma/Splunk/KQL go łapią.
  • Test 2 (poczta): wyślij do skrzynki testowej plik XLS z nieszkodliwym osadzonym obiektem (np. formularz OLE bez makr) i obserwuj, czy Safe Attachments nadaje verdict i czy pipeline korelacyjny łączy NetworkMessageId ↔ DeviceProcessEvents.
  • Atomic Red Team (alternatywa): użyj atomików dla T1204.002 i T1566.001 (wersje bezpieczne/PUA), by wygenerować telemetryczne ślady bez rzeczywistej eksploatacji.

Mapowania (Mitigations, powiązane techniki)

Mitigations ATT&CK:

  • M1051 — Update Software: natychmiastowe łatki Flash/Reader (historycznie) i rygorystyczny patch management.
  • M1031 — Network Intrusion Prevention: IDS/IPS do blokady znanych C2/eksploatacji w ruchu.
  • M1047 — Audit: regularne audyty konfiguracji, telemetrii, list uprawnień.

Powiązane techniki (ATT&CK):

  • T1566.001 — Spearphishing Attachment (wektor początkowy).
  • T1204.002 — User Execution: Malicious File (uruchomienie przez użytkownika).
  • T1203 — Exploitation for Client Execution (RCE w aplikacji klienckiej).
  • T1105 — Ingress Tool Transfer (dogrywanie narzędzi/RAT).
  • T1059 — Command & Scripting Interpreter (uruchomienie poleceń/payloadów).

Źródła / dalsza literatura

  • Adobe Security Advisory APSA11‑01 (opis wektora: SWF w Excelu; aktywna eksploatacja). (adobe.com)
  • NVD/CVE — szczegóły produktu/wersji podatnych. (NVD)
  • CERT/CC VU#192052 (informacja o biuletynie z poprawką). (kb.cert.org)
  • Kaspersky/QuickHeal (informacja o wydaniu poprawek). (Securelist)
  • Case study RSA: Infosecurity‑Magazine, The Register, Wired, F‑Secure. (Infosecurity Magazine)
  • ATT&CK (T1566.001, T1204.002, T1203; Detection Strategies). (MITRE ATT&CK)
  • Wersjonowanie ATT&CK (aktualna v18.0). (MITRE ATT&CK)

15) Checklisty dla SOC / CISO

SOC:

  • Korelacja EmailEvents ↔ DeviceProcessEvents ↔ DNS/Proxy dla załączników .xls.
  • Aktywne reguły na Office/Reader → shell/interpreter (Sigma/SIEM).
  • Hunting: authplay.dll / Flash*.ocx załadowane przez Office/Reader (historyczne hosty/VDI).
  • Blokady w SEG/MDO: OLE/ActiveX w dokumentach Office z internetu.
  • Sandboxing załączników (dynamic + static) i automatyczna kwarantanna.

CISO:

  • Egzekwowanie M1051 (patch management) i EOL hygiene (wyeliminować Flash/Authplay).
  • NIPS/SSL inspection dla wczesnego C2 (M1031).
  • Szkolenia z rozpoznawania spear‑phishingu; procedury zgłoszeń.
  • Testy kontrolne (Purple Team/Atomic) mapowane do T1566.001/T1204.002/T1203.

Uwaga końcowa: Flash/Reader wersje z 2011 r. są dziś wygasłe, ale ślady i techniki (phishing + client‑side RCE) pozostają aktualne. Warto utrzymywać detekcje oparte na wzorcu zachowania (ATT&CK), nie na konkretnym CVE.

Krytyczna luka w React Native Community CLI (CVE-2025-11953): zdalne wykonanie kodu przez niezaufane żądania POST

Wprowadzenie do problemu / definicja luki

JFrog ujawnił krytyczną podatność CVE-2025-11953 (CVSS 9.8) w popularnym pakiecie npm @react-native-community/cli (i komponencie cli-server-api) wykorzystywanym do uruchamiania serwera deweloperskiego Metro w projektach React Native. Luka pozwala niezautoryzowanemu atakującemu na zdalne wykonanie poleceń poprzez wysłanie żądania POST do podatnego endpointu serwera. Błąd został załatany — poprawka dostępna jest od wersji 20.0.0 pakietu @react-native-community/cli-server-api.

W skrócie

  • CVE-2025-11953 umożliwia zdalne wykonanie kodu (RCE) na maszynie, która uruchomiła serwer Metro z podatną wersją CLI.
  • Dotyczy projektów inicjalizowanych z użyciem @react-native-community/cli (bez frameworka), gdy Metro nasłuchuje na interfejsach zewnętrznych. Expo i środowiska niekorzystające z Metro zwykle nie są podatne.
  • Wykonalność: pełne RCE potwierdzone na Windows; na macOS/Linux — uruchamianie arbitralnych programów z ograniczoną kontrolą argumentów (prawdopodobnie możliwa eskalacja po dalszych badaniach).
  • Aktualizacja do ≥20.0.0 (cli-server-api) lub wiązanie serwera do 127.0.0.1 niweluje ryzyko.

Kontekst / historia / powiązania

Zespół JFrog Security Research opisał podatność 4 listopada 2025 r.; SecurityWeek nagłośnił problem tego samego dnia. Meta (współopiekun ekosystemu RN) szybko wprowadziła poprawkę. Incydent wpisuje się w szerszy trend zagrożeń łańcucha dostaw JavaScript/npm oraz ataków na narzędzia deweloperskie.

Analiza techniczna / szczegóły luki

  • Zakres wersji: podatny jest komponent @react-native-community/cli-server-api w wersjach 4.8.0–20.0.0-alpha.2; naprawiono od 20.0.0. W praktyce dotyczy to również odpowiadających im wersji @react-native-community/cli.
  • Przyczyna: endpoint /open-url w middleware CLI przyjmował wartość z ciała żądania (req.body.url) i przekazywał ją bez walidacji do funkcji open() (pakiet open), co prowadzi do Command Injection. Dodatkowo serwer bywał wiązany do 0.0.0.0/[::] (zamiast localhost), wystawiając go na sieć.
  • Wektor ataku (bez uwierzytelniania): atakujący w tej samej sieci (lub przez ekspozycję portu) wysyła POST na podatny endpoint; na Windows możliwe jest wykonanie dowolnych poleceń shell (np. cmd /c ...).
  • Identyfikatory i scoring: CVE-2025-11953, CVSS 3.1: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
  • Advisory: wpis w GitHub Advisory Database opisuje podatność jako OS command injection w serwerze Metro otwieranym przez RN CLI.

Praktyczne konsekwencje / ryzyko

  • Przejęcie stacji deweloperskiej: uruchamianie arbitralnych poleceń (pełne RCE na Windows) może skutkować kradzieżą tokenów, kluczy SSH, poświadczeń do rejestrów, a nawet zatruciem łańcucha dostaw poprzez wstrzyknięcie backdoorów do kodu aplikacji.
  • Pivot w sieci firmowej: stanowiska Dev często mają szerokie uprawnienia i dostęp do CI/CD; złośliwy kod może rozprzestrzenić się do pipeline’ów. (Wniosek na bazie wektora RCE i typowych konfiguracji CI/CD).
  • Atak z sąsiedniej sieci / Wi-Fi gościnne: domyślny binding na wszystkie interfejsy zwiększa ryzyko w środowiskach współdzielonych (biura, coworkingi).

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowe działania naprawcze

  • Zaktualizuj **@react-native-community/cli-server-api do wersji >= 20.0.0 we wszystkich projektach RN; w razie potrzeby zaktualizuj także @react-native-community/cli do wersji zgodnej z poprawką.
  • Jeśli aktualizacja teraz niemożliwa: uruchamiaj Metro z wiązaną pętlą zwrotną:
    npx react-native start --host 127.0.0.1

2) Detekcja i triage

  • Sprawdź, czy w projekcie/globalnie masz podatny pakiet:
    npm list @react-native-community/cli-server-api oraz npm list -g @react-native-community/cli-server-api.
  • Przejrzyj logi zapór/IDS oraz telemetrykę hostów pod kątem nietypowych żądań POST do serwera Metro i uruchomień procesów spoza IDE (zwłaszcza na Windows). (Dobre praktyki wynikające z wektora ataku).

3) Utwardzenie procesu developerskiego

  • Ogranicz ekspozycję: tuneluj dostęp do Metro przez adb reverse/USB lub używaj sieci izolowanych dla dev.
  • Higiena sekretów: rotuj tokeny npm/GitHub, klucze SSH i ciasteczka SSO, jeśli Metro było wystawione i podatne.
  • CI/CD: uruchamiaj buildy w czystych, odseparowanych agentach; włącz skan zależności (SCA) i SAST (np. reguły wykrywające flow req.bodyopen()). (Rekomendacje spójne z analizą JFrog).

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

  • W przeciwieństwie do wielu incydentów npm z 2025 r. (ataków supply-chain poprzez zainfekowane pakiety), CVE-2025-11953 nie wymaga zainstalowania złośliwej wersji biblioteki — atak trafia w interfejs HTTP serwera dev działający lokalnie, ale często wystawiony do sieci. (Porównanie do ostatnich kampanii npm ma charakter kontekstowy).

Podsumowanie / kluczowe wnioski

  • Zagrożenie jest realne i krytyczne (CVSS 9.8): wystarczy niezaufane żądanie POST do serwera Metro.
  • Patch jest dostępny: aktualizuj do @react-native-community/cli-server-api >= 20.0.0 i/lub wiąż Metro do 127.0.0.1.
  • Zadbaj o higienę środowisk Dev: ogranicz ekspozycję, rotuj sekrety, wzmocnij monitoring oraz polityki CI/CD.

Źródła / bibliografia

  • JFrog Security Research — „Critical RCE Vulnerability CVE-2025-11953 Puts React Native Developers at Risk” (04.11.2025). Szczegóły techniczne, zakres wersji, mitigacje. (JFrog)
  • SecurityWeek — „Critical Flaw in Popular React Native NPM Package Exposes Developers to Attacks” (04.11.2025). Ujęcie newsowe, kontekst i potwierdzenie patcha. (SecurityWeek)
  • GitHub Advisory Database — opis OS command injection w Metro/CLI (CVE-2025-11953). (GitHub)
  • JFrog Advisory (JFSA-2025-001495618) — karta podatności, komponent i zakres wersji. (research.jfrog.com)
  • CVE feed (CVSS/Wejście CVE) — wektor i metadane CVE-2025-11953. (cvefeed.io)

Rosyjska grupa Curly COMrades ukrywa malware w linuksowych VM-ach Hyper-V, by omijać EDR

Wprowadzenie do problemu / definicja techniki

Badacze opisali nową technikę operacyjną grupy Curly COMrades: po kompromitacji hosta z Windows napastnicy włączają Hyper-V i importują ukrytą, minimalistyczną maszynę wirtualną z Alpine Linux, w której uruchamiają własne implanty. Dzięki izolacji wykonywania w VM unikają detekcji przez rozwiązania EDR działające na hoście.

W skrócie

  • Atakujący tworzą lekki VM (ok. 120 MB dysku, 256 MB RAM) na Hyper-V i nazywają go „WSL”, aby zlał się z otoczeniem.
  • Wewnątrz VM działają CurlyShell (reverse shell przez HTTPS, persystencja cron) i CurlCat (reverse proxy/SSH→HTTPS).
  • VM używa Default Switch Hyper-V, więc cały ruch wygląda jakby pochodził z IP hosta. To utrudnia sieciową detekcję C2.
  • Kampania była obserwowana m.in. latem 2025 r.; badania prowadził Bitdefender z udziałem CERT Gruzja.

Kontekst / historia / powiązania

Curly COMrades to aktor APT działający co najmniej od 2024 r., powiązany z celami zgodnymi z interesami Rosji. Wcześniejsze aktywności obejmowały m.in. sektor publiczny w Gruzji i energetykę w Mołdawii. Najnowsza publikacja rozszerza znane TTP o trwałą obecność w VM Hyper-V na hostach ofiar.

Analiza techniczna / szczegóły luki

Wejście i przygotowanie środowiska

  • Napastnicy zdalnie włączają rolę Hyper-V i wyłączają interfejs zarządzania, używając poleceń DISM; następnie importują prekonfigurowaną VM (VMCX/VHDX) i startują ją PowerShellem: Import-VM oraz Start-VM -Name WSL. Pliki VM trafiają pod mylącą ścieżkę w C:\ProgramData\Microsoft\AppV\app\.

Konfiguracja VM

  • VM z Alpine Linux jest skrojony „pod ofiarę” (m.in. wpisy /etc/hosts, niestandardowy DNS w /etc/resolv.conf). Sieć ustawiona na Default Switch (NAT), co tuneluje ruch przez stos sieciowy hosta.

Implanty i persystencja

  • CurlyShell (ELF, C++, libcurl) – reverse shell przez HTTPS, uruchamiany okresowo via cron; ukrywa I/O, stosuje niestandardową bazę Base64 w protokole C2. Przykładowy hash: MD5 c6dbf3de8fd1fc9914fae7a24aa3c43d.
  • CurlCat (ELF, C++, libcurl) – lekki tunnel/ProxyCommand w ~/.ssh/config, pakuje SSH w HTTP/HTTPS; przykład MD5: 1a6803d9a2110f86bb26fcfda3606302.

Dalsze operacje

  • Skrypty PowerShell do lateral movement/persystencji (m.in. wstrzyknięcia biletów Kerberos do LSASS oraz zadania GPO zakładające lokalne konta).

Praktyczne konsekwencje / ryzyko

  • Omijanie EDR host-based: wykonanie i artefakty procesu są „przeniesione” do VM, a ruch C2 bywa widoczny jedynie jako zwykły HTTPS z IP hosta. Bez inspekcji na granicy host↔VM anomalia może pozostać niewidoczna.
  • Trwałość i pivot: reverse proxy ułatwia skryte łącza zwrotne i przesiadki w sieci, także gdy host jest pozornie „czysty”.
  • Mylenie obrony: nazwanie VM jako „WSL” i ulokowanie plików w ProgramData\Microsoft\AppV\ ma obniżyć czujność operatorów SOC.

Rekomendacje operacyjne / co zrobić teraz

  1. Inwentaryzacja i kontrola wirtualizacji
    • Wymuś politykę: Hyper-V wyłączone na stacjach/serwerach, gdzie nie jest potrzebne. Alarmuj na nagłe włączenie roli Hyper-V (zapis DISM), import/start VM (logi Hyper-V/VMMS) oraz tworzenie VMCX/VHDX w nietypowych ścieżkach (ProgramData\Microsoft\AppV\...).
  2. Telemetria host↔VM i sieć
    • Monitoruj interfejs vEthernet (Default Switch), nietypowe połączenia wychodzące przez 443 z hostów bez roli serwerowej, a także HTTP/HTTPS z długimi sesjami i stałą entropią (tunnel). Stosuj egress filtering i listy dozwolonych kierunków.
  3. Hunting
    • Szukaj: Start-VM -Name WSL, Import-VM na hostach użytkowników; śladów RAR/WinRAR rozpakowujących VM z archiwów; obecności katalogu AppV\app\Virtual Machines\*.vmcx. W logach PowerShell – nietypowe I/O redirection typu | cmd > %ProgramData%\WindowsUpdateTask_*.tmp.
  4. EDR/EDR+NDR
    • Uzupełnij EDR o host-based network inspection (np. sensoring ruchu z interfejsów wirtualnych) i detekcje HTTPS-tunnel. Bez takiej warstwy VM-based C2 może pozostać niewidoczny.
  5. Twardnienie i polityki
    • Blokuj możliwość Import-VM/Start-VM dla zwykłych użytkowników; kontroluj WinRM/PowerShell Remoting, używaj Credential Guard/LSA Protection, ogranicz Kerberos ticket manipulation.
  6. IR: triage VM-ów
    • Jeśli wykryto ślady: zrzut konfiguracji Hyper-V (VM list, switch, NAT), snapshot dysku VHDX do analizy (montaż read-only), sprawdzenie cronów w /etc/crontabs i plików /bin/init_tools, /root/updater, ~/.ssh/config. Hashy CurlyShell/CurlCat porównaj z IOC z publikacji.

Różnice / porównania z innymi przypadkami

Kryminaliści/ransomware wcześniej wykorzystywali VM-y (np. do szyfrowania z wnętrza maszyny), jednak Curly COMrades idzie dalej: VM stanowi bazę operacyjną C2 z customowymi implantami i trwałą łącznością, a nie tylko jednorazowym narzędziem. Nowością jest też agresywne „udawanie” WSL i prekonfigurowany tunel SSH→HTTPS oparty na własnym komponencie (CurlCat).

Podsumowanie / kluczowe wnioski

  • Wirtualizacja to nie „bezpieczna strefa” – to wektor ukrywania operacji.
  • Widoczność w warstwie Hyper-V (zdarzenia, konfiguracje, pliki) i inspekcja ruchu z interfejsów wirtualnych stają się krytyczne.
  • Implementuj zasadę najmniejszych uprawnień dla operacji Hyper-V, monitoruj Default Switch i poluj na artefakty „WSL” w Hyper-V.

Źródła / bibliografia

  • Bitdefender: „Curly COMrades: Evasion and Persistence via Hidden Hyper-V Virtual Machines” (04.11.2025) – analiza techniczna, TTP, IoC. (Bitdefender)
  • BleepingComputer: „Russian hackers abuse Hyper-V to hide malware in Linux VMs” (04.11.2025) – omówienie kampanii. (BleepingComputer)
  • Dark Reading: „Pro-Russian Hackers Use Linux VMs to Hide in Windows” (04.11.2025) – kontekst i wnioski. (darkreading.com)
  • The Register: „Russian spies pack custom malware into hidden VMs on Windows” (04.11.2025) – streszczenie i cytaty z badań. (The Register)

Najczęściej Wykorzystywane Podatności CVE W Atakach Cybernetycznych

CVE, które przeszły do historii

Altualne na dzień 3.11.2025 – Artykuł będzie aktualizowany planowo 2 razy do roku.

Analizy firm z branży cyberbezpieczeństwa (m.in. Mandiant, Rapid7, Recorded Future, MITRE ATT&CK, Palo Alto Unit 42) oraz instytucji rządowych (CISA, FBI) wskazują na listę podatności, które były najczęściej wykorzystywane przez grupy APT oraz cyberprzestępców w latach 2010–2024.

Czytaj dalej „Najczęściej Wykorzystywane Podatności CVE W Atakach Cybernetycznych”

CVE – Kompleksowy Przewodnik Po Lukach Bezpieczeństwa

Co to jest CVE (Common Vulnerabilities and Exposures)?

CVE (Common Vulnerabilities and Exposures) to międzynarodowy standard nazewnictwa publicznie znanych luk bezpieczeństwa w oprogramowaniu i sprzęcie. Mówiąc prościej, jest to lista unikatowych identyfikatorów podatności oraz związany z nią system ich katalogowania. Dzięki CVE specjaliści ds. cyberbezpieczeństwa na całym świecie mogą mówić jednym językiem o konkretnych lukach – niezależnie od platformy czy producenta.

Czytaj dalej „CVE – Kompleksowy Przewodnik Po Lukach Bezpieczeństwa”

CISA nakazuje agencjom federalnym załatać lukę w VMware Tools wykorzystywaną od października 2024 r.

Wprowadzenie do problemu / definicja luki

CISA ostrzegła, że luka CVE-2025-41244 dotycząca VMware Tools oraz VMware Aria Operations jest aktywnie wykorzystywana. Błąd umożliwia lokalne podniesienie uprawnień do roota na maszynie wirtualnej (VM), jeśli spełnione są określone warunki konfiguracyjne. Agencjom FCEB w USA wyznaczono termin do 20 listopada 2025 r. na załatanie systemów; podatność trafiła do KEV (Known Exploited Vulnerabilities).

W skrócie

  • CVE-2025-41244: lokalny EoP w VMware Tools/Aria Operations (CVSS do 7,8). Warunek: VM z VMware Tools zarządzany przez Aria Operations z SDMP (Service Discovery Management Pack) włączonym. Brak obejść – tylko aktualizacja.
  • Eksploatacja: potwierdzona „in the wild”, przypisywana grupie UNC5174; początki co najmniej w połowie października 2024 r.
  • Terminy: CISA wymaga patchowania w FCEB do 20.11.2025 (BOD 22-01).
  • Wydane poprawki: m.in. VMware Tools 13.0.5 / 12.5.4 oraz Aria Operations 8.18.5; open-vm-tools dostarczają dystrybucje Linuksa.

Kontekst / historia / powiązania

Broadcom (VMware) opublikował VMSA-2025-0015 29 września 2025 r., aktualizowany 30 października 2025 r., obejmujący trzy luki: CVE-2025-41244 (EoP), CVE-2025-41245 (ujawnienie informacji w Aria Ops) oraz CVE-2025-41246 (niewłaściwe autoryzowanie w VMware Tools dla Windows). Zgodnie z informacjami producenta oraz analizami zewnętrznymi, CVE-2025-41244 była wykorzystywana jako zero-day od 2024 r., zanim pojawiły się łatki.

CISA dodała te podatności (w szczególności CVE-2025-41244) do KEV, co zgodnie z BOD 22-01 uruchamia obowiązkowe okno remediacji dla agencji federalnych. Media branżowe (BleepingComputer) podają wprost deadline 20 listopada 2025 r.


Analiza techniczna / szczegóły luki

  • Wektor ataku: napastnik z lokalnym kontem nie-admina na VM może eskalować uprawnienia do root/SYSTEM, jeżeli:
    1. na VM zainstalowano VMware Tools,
    2. VM jest zarządzany przez Aria Operations,
    3. w Aria włączono SDMP.
  • Zakres wersji (wg MS-ISAC/CIS): podatne VMware Tools < 13.0.5 / 12.5.4 (oraz 13.0.5 dla niektórych pakietów), Aria Operations < 8.18.5, VCF Operations < 9.0.1.0.
  • Szczegóły exploitacji: analiza NVISO wskazuje nadużycie funkcji z dopasowaniami regex w get_version(), z obserwowanym stagingiem plików m.in. w /tmp/httpd podczas przygotowania payloadu do eskalacji.
  • Dodatkowe luki z VMSA:
    • CVE-2025-41245 – wyciek poświadczeń w Aria Ops (CVSS 4,9).
    • CVE-2025-41246 – niewłaściwe autoryzowanie w VMware Tools dla Windows; wymaga uwierzytelnienia w vCenter/ESXi i znajomości haseł, może umożliwić dostęp do innych VM.

Praktyczne konsekwencje / ryzyko

  • Po kompromitacji punktu wejścia (np. przez phish lub inną lukę) atakujący mogą wykorzystać CVE-2025-41244 do szybkiego podniesienia uprawnień i utrwalenia się na VM, co ułatwia ruch lateralny w środowiskach multi-tenant i MSP.
  • Użycie SDMP w Aria Operations poszerza powierzchnię ataku — organizacje, które go włączają, muszą traktować patch jak priorytet typu „now”.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast aktualizuj do wersji naprawczych:
    • VMware Tools: 13.0.5 (gałąź 13.x) lub 12.5.4 (gałąź 12.x; 12.4.9 dla 32-bit Windows w pakiecie 12.5.4).
    • Aria Operations: 8.18.5.
    • VCF Operations: 9.0.1.0.
    • open-vm-tools (Linux): zastosuj wydania od dystrybutorów.
  2. Zweryfikuj konfigurację SDMP w Aria Operations; jeżeli nie jest niezbędny, rozważ tymczasowe wyłączenie do czasu pełnej remediacji. (Brak oficjalnych obejść; producent zaleca patch).
  3. Hunting / IOCs: przeszukaj hosty pod kątem podejrzanych binariów umieszczanych w ścieżkach jak /tmp/httpd oraz artefaktów wskazujących na nadużycie get_version()/regex.
  4. Utwierdź kontrolę uprawnień: egzekwuj zasadę least privilege dla kont w VM i rolach Aria Ops; zrewiduj konta serwisowe i rotuj poświadczenia.
  5. Zarządzanie lukami: włącz CVE-2025-41244 do backlogu „patch within 72h” (priorytet 1) i monitoruj KEV pod kątem zmian.
  6. Testy regresji: po aktualizacji narzędzi/agentów w VM zweryfikuj integracje (backupy, EDR, monitoring) oraz zgodność narzędzi automatyzujących gościa.

Różnice / porównania z innymi przypadkami

  • W odróżnieniu od wcześniejszych, host-escape luk w ESXi/Workstation, CVE-2025-41244 jest lokalne (wewnątrz VM) i wymaga włączonego SDMP; nadal jednak świetnie nadaje się post-exploitation do utrzymania i lateralnego ruchu.
  • W stosunku do CVE-2025-41246 (improper authorization w Tools for Windows), 41244 daje bezpośrednie EoP, podczas gdy 41246 wymaga dodatkowych warunków (uwierzytelnienie w vCenter/ESXi i znajomość haseł).

Podsumowanie / kluczowe wnioski

  • Patch teraz: luka jest aktywnie wykorzystywana co najmniej od 10.2024, a CISA dała sektorowi federalnemu twardy termin 20.11.2025.
  • Zaktualizuj VMware Tools, Aria Operations i powiązane komponenty zgodnie z VMSA-2025-0015; brak obejść.
  • Wykonaj hunting pod kątem śladów /tmp/httpd i innych artefaktów opisanych przez badaczy; wzmocnij kontrolę uprawnień.

Źródła / bibliografia

  1. BleepingComputer — CISA orders feds to patch VMware Tools flaw exploited since October 2024 (30.10.2025). (BleepingComputer)
  2. CISA — Known Exploited Vulnerabilities (KEV) Catalog; wpisy dot. VMware Tools/Aria Operations dodane 30–31.10.2025. (cisa.gov)
  3. Broadcom (VMware) — VMSA-2025-0015 / .1: VMware Aria Operations and VMware Tools updates address multiple vulnerabilities (29.09.2025; aktualizacja 30.10.2025). (Support Portal)
  4. Field Effect — Broadcom patches VMware flaw used by China-based threat actor (01.10.2025). (fieldeffect.com)
  5. CIS/MS-ISAC — Multiple Vulnerabilities in VMware Aria Operations and VMware Tools Could Allow for Privilege Escalation (30.09.2025). (CIS)

Qilin (dawniej Agenda) nadużywa WSL, aby uruchamiać linuksowe szyfratory w Windows. Co to oznacza dla SOC?

Wprowadzenie do problemu / definicja luki

Operatorzy ransomware Qilin (znani wcześniej jako Agenda) zostali zaobserwowani przy uruchamianiu linuksowych binarek szyfrujących na hostach Windows poprzez Windows Subsystem for Linux (WSL). Ten zabieg utrudnia wykrywanie, bo wiele rozwiązań EDR/NDR ma profil detekcji skupiony na natywnych procesach Windows i klasycznych łańcuchach ataku. Informację nagłośnił 28 października 2025 r. serwis BleepingComputer, opierając się na świeżych obserwacjach z kampanii Qilin.


W skrócie

  • Nowy wektor: uruchamianie linuksowego szyfratora w Windows przez WSL, często dostarczanego z legalnymi narzędziami RMM/transferu plików.
  • Cel atakującego: ominięcie części polityk EDR/AV, które nie śledzą dokładnie artefaktów i syscalls powiązanych z WSL.
  • TTPs w kampaniach Qilin: zdalne zarządzanie (AnyDesk/ScreenConnect/Quick Assist), BYOVD do wyłączania zabezpieczeń, lateral movement po kradzieży poświadczeń.
  • Skala i dotkliwość: Qilin jest aktywną operacją RaaS od 2022 r.; w 2025 r. łączono go m.in. z atakami na podmioty przemysłowe i produkcyjne (np. Asahi Group w Japonii).

Kontekst / historia / powiązania

Qilin wystartował jako Agenda w 2022 r., szybko ewoluując (m.in. wariant Rust, szyfrowanie przerywane, wersje na Linux/ESXi). W 2024 r. amerykańskie HHS opublikowało profil zagrożenia Agenda/Qilin, opisując klasyczne wektory wejścia (phishing, RDP/VPN, kradzież poświadczeń). Dzisiejsze kampanie dodają warstwę „cross-platform” dzięki WSL.

W październiku 2025 r. media informowały o przypisywaniu przez Qilin głośnych incydentów w sektorze produkcyjnym (Asahi Group). To wskazuje, że grupa celuje w operacje o niskiej tolerancji na przestoje, gdzie presja na zapłatę okupu jest większa.


Analiza techniczna / szczegóły ataku

Łańcuch ataku obserwowany w kampaniach Qilin (Agenda):

  1. Dostęp początkowy: phishing, nadużycie RDP/VPN lub skompromitowane konta; następnie instalacja legalnych narzędzi RMM (AnyDesk, ScreenConnect, Quick Assist itd.) dla utrwalenia i ręcznego sterowania.
  2. Przygotowanie środowiska: pobranie komponentów, często z wykorzystaniem BYOVD (Bring Your Own Vulnerable Driver) w celu wyłączenia EDR/AV i eskalacji uprawnień.
  3. Wykorzystanie WSL:
    • Włączenie WSL (jeśli wyłączony) i/lub doinstalowanie dystrybucji,
    • Dostarczenie linuksowego szyfratora ( ELF ),
    • Uruchomienie go w kontekście WSL, co daje dostęp do wolumenów Windows (np. /mnt/c) i udziałów sieciowych.
      Ten krok utrudnia detekcję, jeśli telemetria nie koreluje zdarzeń WSL z aktywnością na NTFS/Samba.
  4. Szyfrowanie i działania końcowe: niszczenie shadow copies/backupów, eksfiltracja i podwójny szantaż. (Warianty Qilin dokumentowano na Windows i Linux/ESXi).

Dlaczego to działa?

  • Procesy w przestrzeni WSL mogą generować IO na dyskach Windows, ale część rozwiązań ochronnych nie ma kompletnej widoczności syscalls/strumieni z warstwy WSL i nie łączy ich z efektami w NTFS. Elastic publikuje konkretne procedury detekcji „Suspicious Execution via WSL” i zaleca korelację telemetryczną (Defender, Sysmon, Endgame).

Praktyczne konsekwencje / ryzyko

  • Zwiększona szansa na „silent failure” detekcji – klasyczne reguły oparte na vssadmin, znanych packerach czy LOLBins Windows mogą nie zadziałać, jeśli właściwy szyfrator działa jako ELF w WSL.
  • Szybsze szyfrowanie zasobów sieciowych – binarka Linux może agresywnie iterować po udostępnionych zasobach (SMB/NFS), redukując czas do pełnego „blast radius”.
  • Ryzyko „false negative” w IR – bez dowodów na klasyczne narzędzia Windows zespoły IR mogą mylnie ocenić źródło szyfrowania i przeoczyć artefakty WSL.

Rekomendacje operacyjne / co zrobić teraz

1) Widoczność i telemetria WSL

  • Włącz logowanie i korelację zdarzeń WSL z IO na NTFS; stosuj gotowe reguły detekcji „Suspicious Execution via WSL” (Elastic) i ich odpowiedniki w SIEM/EDR. Monitoruj uruchomienia wsl.exe, tworzenie nowych dystrybucji i nietypowe procesy potomne.

2) Twarde kontrolki konfiguracyjne

  • Jeśli WSL nie jest potrzebny – wyłącz i egzekwuj to GPO/Intune.
  • Ogranicz instalację/uruchamianie niezatwierdzonych dystrybucji WSL (allow-list).

3) Ochrona przed BYOVD i RMM

  • Blokuj znane podatne sterowniki (WDAC/ Defender Attack Surface Reduction, polityki blokowania sterowników).
  • Wdróż kontrolę legalnych RMM (allow-list + monitorowanie anomalii, m.in. AnyDesk, ScreenConnect, Quick Assist), bo Qilin używa ich do dostarczania ładunku i utrzymania.

4) Backupy i segmentacja

  • Odseparuj repozytoria kopii zapasowych, testuj immutable snapshots i procedury odtwarzania. (Qilin celuje w backupy przed szyfrowaniem).

5) Playbook IR (aktualizacja pod WSL)

  • Dodaj kroki: enumeracja dystrybucji WSL, przegląd procesów ELF, artefaktów w %LOCALAPPDATA%\\Packages\\*Linux*, policji sieciowej WSL (gdy aktywna). Uwzględnij typowe ścieżki montowania (/mnt/c, /mnt/d itd.).

6) Higiena dostępu

  • MFA wszędzie, rotacja haseł po incydencie, zamykanie zbędnych RDP/VPN, polityki najmniejszych uprawnień – to nadal podstawy zgodne z zaleceniami profilu zagrożenia Qilin.

Różnice / porównania z innymi przypadkami

  • Klasyczne ransomware na Windows: bazuje na LOLBins (vssadmin, wmic), API Win32 i anty-debug, które łatwiej profilować.
  • Model Qilin z WSL: cross-platform, mniejsza sygnaturowość w warstwie Windows, inna telemetria, inne artefakty dyskowe i pamięciowe. Wymaga innych punktów obserwacji (mapowanie aktywności WSL ↔ NTFS).

Podsumowanie / kluczowe wnioski

Qilin podnosi poprzeczkę, łącząc Windows z Linuxem na jednym hoście i przesuwając środek ciężkości detekcji do obszarów, które wiele organizacji ignoruje: WSL, BYOVD oraz legalne RMM. Jeżeli nie monitorujesz WSL i nie egzekwujesz polityk RMM/sterowników, zostawiasz widoczną szczelinę w obronie. Priorytetem jest telemetria WSL + kontrola RMM + polityki sterowników + odporne backupy.


Źródła / bibliografia

  1. BleepingComputer – „Qilin ransomware abuses WSL to run Linux encryptors in Windows”, 28 października 2025. (BleepingComputer)
  2. Trend Micro Research – „Agenda Ransomware Deploys Linux Variant on Windows Systems…”, 23 października 2025. (www.trendmicro.com)
  3. Elastic Security – „Suspicious Execution via Windows Subsystem for Linux” (poradnik detekcji). (Elastic)
  4. HHS – „Qilin (Agenda) Threat Profile”, 18 czerwca 2024 (TLP:CLEAR). (HHS.gov)
  5. Reuters – „‘Qilin’ cybercrime gang claims hack on Japan’s Asahi Group”, 7 października 2025. (Reuters)