Archiwa: APT - Strona 25 z 31 - Security Bez Tabu

EDR vs MDR vs XDR

Czym się różnią i co wybrać?

EDR, MDR, XDR – trzy popularne skróty w świecie cyberbezpieczeństwa, często pojawiające się w ofertach dostawców i dyskusjach specjalistów. Oznaczają odpowiednio Endpoint Detection and Response, Managed Detection and Response oraz Extended Detection and Response. Choć brzmią podobnie, reprezentują różne podejścia do wykrywania zagrożeń i reagowania na nie.

Czytaj dalej „EDR vs MDR vs XDR”

CVE-2012-0158 — MSCOMCTL.OCX RCE w dokumentach Office

TL;DR

CVE‑2012‑0158 to klasyczna luka RCE w bibliotekach Windows Common Controls (ActiveX MSCOMCTL.OCX — m.in. kontrolki ListView/TreeView). Była masowo wykorzystywana poprzez złośliwe pliki RTF/DOC dostarczane e‑mailem; po otwarciu dokumentu dochodziło do wykonania kodu z uprawnieniami użytkownika. Microsoft załatał błąd w biuletynie MS12‑027 (2012‑04‑10), ale podatność pozostawała długo popularna w kampaniach APT i trafiła do katalogu CISA KEV. Dla SOC: monitoruj dzieci procesów Office (Word/Excel → cmd.exe/powershell.exe/wscript.exe), wymuś ASR „Block Office creating child processes”, blokuj/otwieraj w Protected View pliki RTF i egzekwuj aktualizacje.


Krótka definicja techniczna

Błąd stanowi przepełnienie bufora/pamięci w kontrolkach ActiveX (ListView, ListView2, TreeView, TreeView2) biblioteki MSCOMCTL.OCX. Specjalnie przygotowany dokument Office/RTF lub strona WWW może doprowadzić do zdalnego wykonania kodu (RCE) w kontekście ofiary (typowo przez osadzenie obiektu OLE/objocx w RTF).


Gdzie występuje / przykłady platform

  • Windows (stacje robocze z MS Office 2003/2007/2010) — główna powierzchnia ataku; komponent jest współdzielony z innymi produktami (np. SQL Server, BizTalk, Commerce Server).
  • M365/Exchange Online — wektor dostarczenia (załączniki); detekcja przez Defender for Office 365 (tabele EmailEvents, EmailAttachmentInfo w Advanced Hunting).
  • AD/Entra ID — kontekst tożsamości ofiary (późniejsze działania po przejęciu).
  • AWS/Azure/GCP — często hosting plików przynęt (S3/Blob/HTTP); przydatna telemetria z CloudTrail dla GetObject z nieznanych źródeł. [praktyka SOC]
  • Kubernetes/ESXi — nie dotyczy samej luki; możliwe tylko jako dalsze cele po kompromitacji użytkownika.

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

  • Mechanizm: złośliwy plik (najczęściej RTF) zawiera osadzony obiekt OLE z deklaracją kontrolki ActiveX (\object/\objocx). Renderowanie przez Worda wywołuje kod z biblioteki MSCOMCTL.OCX, co powoduje naruszenie pamięci i przekazanie sterowania attackerowi.
  • Skuteczność: wektor „zero‑click poza otwarciem” dla użytkownika (wystarczy otworzyć dokument), szeroko stosowany 2012‑2017; widoczny w wielu kampaniach, nawet po opublikowaniu łatki MS12‑027.
  • Łatki: MS12‑027 (10.04.2012) adresuje CVE‑2012‑0158 w Windows Common Controls; późniejszy MS12‑060 (08.2012) łata inną podatność w tej samej bibliotece (TabStrip, CVE‑2012‑1856), co podkreśliło potrzebę stałych aktualizacji.
  • Zagrożone produkty: Office 2003/2007/2010 oraz inne oprogramowanie korzystające z MSCOMCTL.OCX (m.in. SQL Server, Commerce Server, BizTalk, Visual Basic 6 runtime).

Artefakty i logi (co zbierać)

PlatformaŹródło danychZdarzenie/IDKluczowe pola / wzorceWskazówki analityczne
WindowsSysmonEID 1 (Process Create)ParentImage=WINWORD.EXE/EXCEL.EXE/POWERPNT.EXE + Image in (cmd.exe,powershell.exe,wscript.exe,mshta.exe,regsvr32.exe,rundll32.exe)Typowy łańcuch po eksploitacji dokumentu. Koreluj z CommandLine (URL, -enc, FromBase64String).
WindowsSysmonEID 7 (Image Loaded)ImageLoaded kończy się na \mscomctl.ocx przez WINWORD.EXERzadkie w zdrowych dokumentach; wzmacnia pewność analityki procesów.
WindowsSysmonEID 3 (Network Connect)Image=WINWORD.EXE lub dziecko → połączenia HTTP/HTTPSDokumenty przynęt często dociągały payloady; patrz hosty niesankcjonowane.
WindowsSecurityEvent ID 4688Procesy jak wyżej; NewProcessName, CreatorProcessNameAlternatywa dla środowisk bez Sysmon.
M365Defender for Office 365 (AH)tabele EmailEvents, EmailAttachmentInfoAttachmentFileType in (rtf, doc, docx); DetectionTechnology/ActionTypeTelemetria o załącznikach i kampaniach e‑mail; koreluj z host telemetry.
M365Unified Audit / MailItemsAccessedZdarzenia dostępu do wiadomościIP, klient, operacjaPomaga ocenić skalę kompromitacji skrzynek.
AWSCloudTrail (data events S3)GetObject, HeadObjectrequestParameters.key ~ `.(rtfdocx?)$, userAgent, sourceIPAddress`
Azure/GCP/K8s/ESXiNie dotyczy bezpośrednio luki; tylko kontekstowe telemetry (np. proxy, CASB).

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

title: Office Spawns Suspicious Child Process (CVE-2012-0158 Post-Ex)
id: 0b2c9c9a-5b6a-4a9b-b2d9-cc15e2150158
status: experimental
description: >
  Wykrywa aplikacje Office tworzące podejrzane procesy potomne
  (typowe po wykorzystaniu dokumentów, w tym CVE-2012-0158).
author: Badacz CVE
date: 2025/11/05
tags:
  - attack.t1203
  - attack.t1566.001
  - attack.t1204.002
  - cve.2012-0158
logsource:
  category: process_creation
  product: windows
detection:
  parent_office:
    ParentImage|endswith:
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
      - '\POWERPNT.EXE'
  suspicious_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: parent_office and suspicious_child
falsepositives:
  - legalne dodatki/deployment (udokumentowane wyjątki)
level: high

Splunk (SPL)

(index=endpoint OR index=sysmon)
(
  (sourcetype=XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode=1)
  OR (sourcetype=WinEventLog:Security EventCode=4688)
)
| eval ParentImage=coalesce(ParentImage, CreatorProcessName)
| eval Image=coalesce(Image, NewProcessName)
| search ParentImage IN ("*\\WINWORD.EXE","*\\EXCEL.EXE","*\\POWERPNT.EXE")
| search Image IN ("*\\cmd.exe","*\\powershell.exe","*\\wscript.exe","*\\cscript.exe","*\\mshta.exe","*\\rundll32.exe","*\\regsvr32.exe")
| stats count min(_time) as firstTime max(_time) as lastTime by host user ParentImage Image CommandLine ParentCommandLine
| where count>=1

KQL (Microsoft 365 Defender AH)

// Office -> suspicious child
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","regsvr32.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by Timestamp desc
// Word/Excel ładuje mscomctl.ocx (wzmacniacz hipotezy)
DeviceImageLoadEvents
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE")
| where FolderPath endswith @"\mscomctl.ocx"

AWS CloudTrail — CloudWatch Logs Insights (S3 data events)

fields @timestamp, eventSource, eventName, requestParameters.bucketName as bucket, requestParameters.key as key, sourceIPAddress, userAgent
| filter eventSource = "s3.amazonaws.com" and eventName in ["GetObject","HeadObject"]
| filter key like /.*\.(rtf|doc|docx)$/i
| sort @timestamp desc
| limit 100

Elastic / EQL

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

Heurystyki / korelacje (co łączyć)

  • Office → interpreter skryptów w krótkim interwale czasu + sieć (pobrania) = mocny sygnał post‑eksploatacyjny. (T1059 po T1203/T1204).
  • Skanowanie treści RTF pod kątem tokenów \object, \objocx, MSComctlLib.ListViewCtrl.2 (wskaźnik heurystyczny; niejednoznaczny).
  • Załączniki RTF/DOC w M365 (EmailAttachmentInfo) + DeviceProcessEvents (dzieci WINWORD.EXE).
  • Image load mscomctl.ocx przez Word + brak wcześniejszych makr/OLE w dokumencie → dodatkowy kontekst.
  • ASR: „Block all Office applications from creating child processes” — jeżeli trigger → wysoka wiarygodność.

False positives / tuning

  • Legalne wtyczki Office/rozwiązania DLP/drukarki wirtualne potrafią tworzyć procesy potomne; wprowadź allow‑listy podpisanych binariów i znanych ścieżek.
  • Środowiska developerskie (VBA, add‑ins) — filtruj zaufanych wydawców certyfikatów.
  • mscomctl.ocx może być ładowany także przez aplikacje legacy (VB6) — użyj dodatkowych warunków: parent=WINWORD/EXCEL, CommandLine z nietypowymi przełącznikami.
  • Na bramce pocztowej: samo wystąpienie \objocx w RTF to sygnał podejrzany, nie rozstrzygający (stosuj sandbox/MDO).

Playbook reagowania (IR)

  1. Izoluj hosta z alertu (EDR).
  2. Zabezpiecz artefakty: próbka pliku, prefetch, memoria, Process Tree, DeviceProcessEvents/DeviceImageLoadEvents.
  3. Weryfikacja aktualizacji (PowerShell; różne KB wg produktu z MS12‑027): Get-HotFix -Id KB2664258,KB2598039,KB2598041,KB2597112 -ErrorAction SilentlyContinue Get-ChildItem "C:\Windows\System32\MSCOMCTL.OCX","C:\Windows\SysWOW64\MSCOMCTL.OCX" -ErrorAction SilentlyContinue | Select FullName,@{n='FileVersion';e={$_.VersionInfo.FileVersion}} (Lista KB wg biuletynu MS12‑027 i wariantów produktowych).
  4. Łańcuch zdarzeń: wyszukaj inne hosty z tym samym załącznikiem (EmailEvents + SHA256 z EmailAttachmentInfo), a następnie koreluj z host telemetry.
  5. Blokady: dodaj hash/URL do blokady w MDO/EOP/Proxy; włącz/utwardź ASR „Block Office creating child processes”.
  6. Naprawa: wymuś instalację MS12‑027, a także późniejszych zbiorczych aktualizacji Office/Windows; wdroż Exploit Protection/DEP/ASLR.
  7. Komunikacja i hardening: włącz Protected View i File Block dla RTF w organizacji, zwłaszcza dla skrzynek o podwyższonym ryzyku.

Przykłady z kampanii / case studies

  • 2012 — pierwsza fala szerokich ataków z RTF/DOC; w RTF widoczne \objocx.
  • 2013 — analiza Kaspersky: RTF/DOC dla Office 2003/2007/2010; mimo łatki wciąż obserwowane infekcje.
  • 2016 — „Word bug that won’t die”: luki wciąż używane w realnych kampaniach phishingowych.
  • 2017 — kampanie przeciw organizacjom w Wietnamie, dokumenty polityczne, przypisywane m.in. 1937CN.
  • APT (MITRE) — np. Aoqin Dragon wykorzystywała CVE‑2012‑0158 do uzyskania wykonania.
  • CISA — CVE‑2012‑0158 w zestawieniach „Top Routinely Exploited” i w katalogu KEV.

Lab (bezpieczne testy) — przykładowe zadania

Uwaga: poniższe kroki nie zawierają exploitów ani makr ofensywnych; służą wyłącznie do weryfikacji detekcji.

Lab‑1: Heurystyka RTF w bramce/MDO

  1. Utwórz harmless.rtf zawierający nieszkodliwy tekst oraz nagłówek z ciągiem \object/\objocx (bez osadzania binariów OLE).
  2. Wyślij na skrzynkę testową M365 i sprawdź, czy polityki (MDO Safe Attachments/Sandbox) oraz reguły treści podnoszą alert/znacznik podejrzany.
  3. Koreluj EmailAttachmentInfo ↔ host telemetry (brak uruchomionych procesów wtórnych powinien dać „clean”).

Lab‑2: Analityka „Office → child process” (symulacja zachowania, bez dokumentu)

  1. Uruchom ręcznie Word, a następnie w tym samym czasie uruchom testowo powershell.exe -nop -c "Write-Host Test" (symulacja artefaktów procesowych bez łańcucha infekcji).
  2. Sprawdź, czy reguły Sigma/Splunk/KQL wyłapują przypadki dziecko procesu Office (w środowisku produkcyjnym zadziała to na realnych incydentach).
  3. W środowiskach z ASR, potwierdź, że reguła „Block Office creating child processes” blokuje podobny łańcuch.

Lab‑3: Telemetria mscomctl.ocx (obserwacja)

  • Monitoruj DeviceImageLoadEvents dla WINWORD.EXEmscomctl.ocx (zwykle pusto). To testuje pipeline logów i zapytania KQL, bez ryzyka.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK):

  • M1051 — Update Software: egzekwuj aktualizacje (MS12‑027 i późniejsze biuletyny Office/Windows).
  • M1042 — Disable or Remove Feature or Program: usuń starsze komponenty/formaty; blokuj RTF w File Block.
  • M1050 — Exploit Protection: włącz DEP/ASLR/Exploit Protection politykami.
  • M1017 — User Training: szkolenia anty‑phishing, higiena otwierania załączników.

Techniki pokrewne:

  • T1566.001 (Spearphishing Attachment) — nośnik.
  • T1204.002 (User Execution: Malicious File) — warunek powodzenia.
  • T1059 (Command and Scripting Interpreter) — post‑eksploatacja.

Źródła / dalsza literatura

  • Microsoft Security Bulletin MS12‑027 (MSCOMCTL.OCX RCE). (Microsoft Learn)
  • NVD/CVE wpisy szczegółowe. (NVD)
  • Blog Microsoft SRD o MS12‑027. (Microsoft)
  • McAfee: „CVE‑2012‑0158 exploit in the wild”. (McAfee)
  • Kaspersky: „The curious case of a CVE‑2012‑0158 exploit”. (Securelist)
  • Sophos: „The Word bug that just won’t die”. (Sophos News)
  • Fortinet: kampanie w Wietnamie (1937CN). (Fortinet)
  • CISA: KEV i „Top Routinely Exploited”. (CISA)
  • MITRE ATT&CK: T1203, T1566.001, T1204.002. (MITRE ATT&CK)
  • Attack Surface Reduction — „Block Office creating child processes”. (Microsoft Learn)
  • Exploit Protection (Windows). (Microsoft Learn)
  • MDO Advanced Hunting: EmailEvents, EmailAttachmentInfo. (Microsoft Learn)

Checklisty dla SOC / CISO (krótko)

SOC (operacyjnie):

  • Alerty na Office → interpreter (reguły z sekcji 7).
  • Korelacja MDO załącznikihost telemetry (hash, nadawca, kampania).
  • Watchlist domen/URL z kampanii; blokady w bramkach.
  • Raportowanie i „mass search” po mscomctl.ocx load (wzmocnienie hipotezy).
  • Retencja logów: min. 90 dni dla e‑mail + endpoint.

CISO (strategicznie):

  • Egzekwuj aktualizacje (M1051) i compliance na stacjach z Office.
  • ASR: włącz „Block Office creating child processes” dla ogółu, wyjątki per‑grupa.
  • Protected View / File Block dla RTF w całej organizacji.
  • Awareness (M1017): szkolenia, symulacje phishingu.
  • Testy kontrolne (purple team) — weryfikacja detekcji bez exploitów.

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)

Hakerzy atakują brytyjskich dostawców wody pitnej. Co ujawniają raporty do DWI i co zmieni nowe prawo?

Wprowadzenie do problemu / definicja luki

Brytyjskie przedsiębiorstwa wodociągowe zgłosiły do Drinking Water Inspectorate (DWI) łącznie 15 incydentów w okresie 1.01.2024–20.10.2025, z czego pięć dotyczyło cyberataków – ujawnia analiza wniosków FOI opisana przez Recorded Future News. Ataki nie zakłóciły dostaw ani jakości wody, ale uderzały w systemy organizacji wspierające ciągłość usług. Sprawa odsłania lukę w przepisach NIS: obowiązkowe jest raportowanie tylko tych zdarzeń, które rzeczywiście przerwały świadczenie usługi – co w praktyce może zaniżać obraz ryzyka prepozycjonowania i działań APT.

W skrócie

  • 5 cyberincydentów zgłoszonych „poza zakresem NIS” (dobrowolnie), łącznie 15 raportów do DWI od 2024 r.
  • Obecne Regulacje NIS wymagają zgłoszenia tylko wtedy, gdy dojdzie do realnej niedostępności usługi kluczowej.
  • Rząd zapowiada Cyber Security and Resilience Bill, który ma obniżyć próg raportowania i wzmocnić obowiązki dla infrastruktury krytycznej.
  • Wektor OT pozostaje wrażliwy (np. Unitronics PLC); w 2023–2024 r. ostrzegały o tym wspólne alerty CISA/NCSC.
  • Trwałe prepozycjonowanie (np. Volt Typhoon) podbija ryzyko, które regulacje „reaktywne” mogą przeoczyć.

Kontekst / historia / powiązania

W sektorze wodnym historycznie dominowały incydenty w IT/biurze (np. ransomware), rzadziej bezpośrednio w OT/ICS. Tendencję potwierdzają przypadki w Europie (m.in. brytyjski South Staffs Water czy hiszpańskie Aigües de Mataró), przy czym sam proces uzdatniania i dystrybucji zwykle nie został naruszony. Raport DWI pokazuje jednak, że dostawcy mimo braku formalnego obowiązku zaczynają dzielić się informacjami o cyberzdarzeniach wpływających na „odporność dostaw” – to krok w stronę kultury wymiany danych o zagrożeniach.

Analiza techniczna / szczegóły luki

Dlaczego obecny próg NIS jest problematyczny? Regulacje w wersji obowiązującej w Wielkiej Brytanii koncentrują się na incydentach, które doprowadziły do przerwy w usłudze (ang. essential service). W efekcie:

  • Ciche naruszenia (np. rekonesans, uzyskanie trwałego dostępu, zmiana konfiguracji bez skutku operacyjnego) mogą nie być zgłaszane.
  • Z perspektywy OT/ICS jest to krytyczne: prepozycjonowanie APT w sieci zakładu, segmentacji lub w kontrolerach PLC może trwać miesiącami bez widocznej awarii.

Przykład wektora: w 2023 r. CISA ostrzegła przed aktywną eksploatacją PLC Unitronics w zakładach wod-kan; NCSC równolegle wskazało na ryzyko w sektorze wodnym i potrzebę twardszej separacji IT/OT oraz twardej konfiguracji urządzeń. To typowe punkty zaczepienia dla aktorów państwowych i przestępczych.

Praktyczne konsekwencje / ryzyko

  • Ryzyko systemowe: brak pełnej widoczności zdarzeń poniżej progu NIS utrudnia świadomość sytuacyjną – zarówno u operatorów, jak i organów państwowych.
  • Ryzyko dla OT: nawet jeśli wody „nie zabrakło”, ataki na „out-of-NIS-scope systems” (systemy pomocnicze, zaplecze IT, telemetria) mogą degradować zdolność reagowania, utrzymania i bezpieczeństwo pracy.
  • Ryzyko geopolityczne: kampanie pokroju Volt Typhoon celują w infrastrukturę krytyczną, gdzie utrzymanie dostępu jest ważniejsze niż szybki efekt – co wymaga innej strategii detekcji i raportowania.

Rekomendacje operacyjne / co zrobić teraz

  1. Raportowanie „poniżej progu” jako standard – podążaj za dobrym przykładem branży i zgłaszaj do DWI/NCSC także incydenty niewywołujące przerwy, zwłaszcza w warstwie OT/telemetrii.
  2. Twarda segmentacja IT/OT i zasada najmniejszych uprawnień – mikrosegmentacja, odrębne domeny, kontrola przepływów (firewall L7, allow-list) między strefami. Rekomendacja spójna z wytycznymi NCSC.
  3. Higiena PLC/RTU – odłącz nieużywane interfejsy, zmień domyślne hasła, włącz MFA i VPN dla zdalnego dostępu, monitoruj anomalie protokołów przemysłowych; zastosuj zalecenia z alertu CISA ws. Unitronics.
  4. Łowy na zagrożenia (threat hunting) pod kątem prepozycjonowania – identyfikuj techniki mapowane do MITRE ATT&CK for ICS (np. Tactics: Initial Access/Discovery/Lateral Movement) wskazywane w doradztwach nt. Volt Typhoon/NCSC.
  5. Ćwiczenia scenariuszowe – tabletop’y obejmujące varianty „no-impact yet”, np. znajdowanie web-shelli w DMZ SCADA, nietypowe polecenia na HMI, podejrzane zmiany w konfiguracji PLC.
  6. Zarządzanie dostawcami – inwentaryzacja zewnętrznych serwisów (telemetria, łączność, ICS managed services), umowy z obowiązkami notyfikacji i testami 3rd-party.

Różnice / porównania z innymi przypadkami

  • IT vs OT: większość europejskich incydentów wodnych w ostatnich latach dotyczyła IT, co ograniczało wpływ na fizyczny proces (np. przypadki opisywane przez media branżowe). Ryzyko OT materializuje się rzadziej, ale gdy do niego dochodzi, skutki są natychmiast odczuwalne – co potwierdzają międzynarodowe ostrzeżenia dotyczące PLC i ICS.
  • NIS (UK) vs podejście „proaktywne”: podejście oparte wyłącznie na skutku operacyjnym różni się od praktyk, które zachęcają do reportowania faz wczesnych (rekonesans, dostęp wstępny). Zapowiadany Cyber Security and Resilience Bill ma zbliżyć regulacje do modelu proaktywnego (szybsze zgłaszanie, szerszy zakres).

Podsumowanie / kluczowe wnioski

  • Sektor wodny w Wielkiej Brytanii jest aktywnie atakowany, ale obecnie nie obserwuje się powszechnych przerw w dostawach – co nie znaczy, że ryzyko jest niskie.
  • Próg raportowania w NIS wymaga aktualizacji do realiów prepozycjonowania i ataków na łańcuch dostaw OT/ICS.
  • Nowe prawo (Cyber Security and Resilience Bill) ma potencjał, by zamknąć luki regulacyjne i zwiększyć odporność CNI – kluczowe będzie wdrożenie i egzekwowanie.
  • Operacyjnie należy traktować incydenty „poniżej progu” jak czerwone flagi i budować detekcję pod wczesne fazy ataku w OT.

Źródła / bibliografia

  1. Recorded Future News – raport o zgłoszeniach do DWI (FOI) i atakach na brytyjskich dostawców wody (03.11.2025). (The Record from Recorded Future)
  2. DWI – „The Network and Information Systems (NIS) Regulations 2018” (wymogi i zgłaszanie). (Drinking Water Inspectorate)
  3. GOV.UK – „Cyber Security and Resilience Bill” (kolekcja materiałów dot. projektu ustawy). (GOV.UK)
  4. CISA – „Exploitation of Unitronics PLCs used in Water and Wastewater Systems” (28.11.2023). (cisa.gov)
  5. NCSC – ostrzeżenia dot. PRC/Volt Typhoon i prepozycjonowania w CNI (07.02.2024; 30.11.2023). (ncsc.gov.uk)

SesameOp — backdoor wykorzystujący OpenAI Assistants API do ukrytego C2. Analiza i zalecenia dla SOC

Wprowadzenie do problemu / definicja luki

Microsoft Incident Response (DART) opisał nowy backdoor SesameOp, który wykorzystuje OpenAI Assistants API jako kanał command-and-control (C2). To nie jest podatność w OpenAI ani błąd konfiguracji — to nadużycie legalnego interfejsu API w celu ukrycia komunikacji atakujących w „szumie” ruchu do popularnej usługi chmurowej. OpenAI wraz z Microsoftem zidentyfikowali i wyłączyli klucz oraz powiązane konto wykorzystywane przez sprawcę; funkcja Assistants API i tak ma zostać wycofana w sierpniu 2026 r.

W skrócie

  • Odkrycie: lipiec 2025 podczas reakcji IR; w środowisku ofiary utrzymywano długotrwałą obecność (cel: utrwalenie i szpiegostwo).
  • Kanał C2: OpenAI Assistants API użyte jako „magazyn/relayer” poleceń i wyników, z kompresją i warstwowaniem kryptografii (sym./asym.).
  • Łańcuch: loader Netapi64.dll (obf. Eazfuscator.NET) + backdoor OpenAIAgent.Netapi64 ładowany przez .NET AppDomainManager injection.
  • Kontrola zadań: opis assistanta = SLEEP / Payload / Result; identyfikacja hosta, vector store per hostname, wątki i kasowanie wiadomości po użyciu.
  • Status platformy: to nadużycie funkcji, nie exploit; OpenAI/Microsoft skoordynowali wyłączenie klucza/konta.

Kontekst / historia / powiązania

Nadużywanie legalnych usług (tzw. LOLBAS/LOLCLOUD) do C2 to trend widoczny od lat (GitHub, Slack, Telegram, Pastebin). W 2025 r. ENISA raportuje nasilenie wykorzystywania narzędzi AI przez grupy APT i cyberprzestępców (od inżynierii społecznej, przez rozwój malware, po ukrywanie operacji). To raczej „turbo-doładowanie” starych technik niż zupełnie nowe zdolności ofensywne.

Analiza techniczna / szczegóły luki

Składniki i uruchomienie

  • Loader: Netapi64.dll (obfuskacja Eazfuscator.NET), znacznik uruchomienia C:\Windows\Temp\Netapi64.start, mutex jednosesyjny; dekoduje i uruchamia właściwy moduł z pliku kończącego się na .Netapi64.
  • Backdoor: .NET OpenAIAgent.Netapi64 — wbrew nazwie nie używa SDK agentów ani modeli, tylko Assistants API do pobierania poleceń i wysyłki wyników jako wiadomości. Konfiguracja z zasobów: OpenAI_API_Key|Dictionary_Key_Name|Proxy; obsługa proxy systemowego, B64 hostnamen. Mutex: „OpenAI APIS”.

Protokół C2 przez Assistants API

  1. Zapytanie listy vector stores w koncie; jeśli brak rekordu z hostname — tworzy nowy (wiąże hosta z artefaktami w OpenAI).
  2. Pobranie listy Assistants (paginacja do 100). Pola sterujące: description oraz instructions. description przyjmuje jedną z wartości:
    • SLEEP → odczyt timeSLEEP z wiadomości (po thread_id|message_id) i pauza wątku,
    • Payload → pobierz treść polecenia po thread_id|message_id, wykonaj w osobnym wątku, usuń wiadomość i assistanta,
    • Result → opublikuj wynik jako nową wiadomość (description=Result).
  3. Cała wymiana kompresowana i szyfrowana (warstwowo: symetrycznie i asymetrycznie).

Wejście do procesu i utrwalenie

  • Wektor uruchomienia: .NET AppDomainManager injection w komponenty Visual Studio za pomocą spreparowanego pliku .config; w środowisku ofiary działała dodatkowo siatka internal web shelli wspierających orkiestrację.

Detekcje Microsoft

  • Sygnatury AV: Trojan:MSIL/Sesameop.A (loader) i Backdoor:MSIL/Sesameop.A (backdoor).
  • Alerty EDR: m.in. „Possible .NET AppDomainManager injection”.
  • Przykładowe zapytanie huntingowe (Defender XDR) do wykrywania urządzeń łączących się z api.openai.com.

Praktyczne konsekwencje / ryzyko

  • Ukrywanie w legalnym ruchu: egress do popularnego API (OpenAI) utrudnia klasyczne IOC-based blocking i analitykę opartą wyłącznie o domeny.
  • Szyfrowanie + kompresja: minimalizuje telemetry „na drucie” i zwiększa koszt analizy NDR.
  • Ślad w chmurze dostawcy: użycie vector stores / threads / messages zostawia artefakty możliwe do skorelowania z kluczem API (pomaga po incydencie, jeżeli dostawca współpracuje).
  • Trend rynkowy: wg ENISA i OpenAI rosną próby nadużyć usług AI, ale zazwyczaj to przyspieszanie istniejących TTP — dlatego kontrola egress + tożsamości kluczy API staje się krytyczna.

Rekomendacje operacyjne / co zrobić teraz

Monitoring & hunting (SOC)

  • Widoczność egress do api.openai.com: koreluj proces → host → częstotliwość; zacznij od kwerendy Microsoft (lub odpowiednika w SIEM/NDR). Ustal listę dozwolonych procesów/serwerów korzystających z API OpenAI.
  • Reguły behawioralne: wykrywaj AppDomainManager injection, niespodziewane ładowanie DLL do procesów Visual Studio, tworzenie znaczników w C:\Windows\Temp\*Netapi64*.
  • Anomalie DNS/HTTP: długie okresy SLEEP, nietypowa paginacja Assistants i bursty wiadomości mogą tworzyć charakterystyczne wzorce czasowe (mimo TLS). (Wniosek na podstawie opisu protokołu.)

Kontrola dostępu i „egress governance” (IT/SecOps)

  • Allowlista egress dla AI: ograniczaj ruch do usług AI do zatwierdzonych podsieci/procesów; w proxy weryfikuj nagłówki autoryzacji i kontekst procesu (jeżeli wspiera). (Najlepsza praktyka zgodna z case’em Microsoft.)
  • Zarządzanie kluczami API: rotacja, skan tajemnic, ochrona przed wyciekiem; w razie incydentu — unieważnij klucze i wnioskuj u dostawcy o logi zasobów (threads/vector stores).
  • Wymuś PUA/EDR w trybie block i tamper protection w Defenderze; włącz cloud-delivered protection.

IR / odzyskiwanie

  • Artefakty na hoście: poszukuj mutexów „OpenAI APIS”, plików w C:\Windows\Temp\Netapi64.*, wpisów konfiguracyjnych .config wskazujących AppDomainManager.
  • Artefakty u dostawcy: listy Assistants, threads, messages, vector stores powiązane z kompromitowanym kluczem. (Współpraca z OpenAI/Microsoft okazała się skuteczna w tej sprawie.)

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

  • Względem „klasycznego” cloud-C2 (np. Slack/Telegram): SesameOp semantycznie mapuje logikę C2 na artefakty platformy AI (description = SLEEP/Payload/Result, threads, vector stores), co utrudnia pisanie prostych sygnatur i wymusza analizę zachowań aplikacji zamiast samych domen.
  • Względem generowania malware przez LLM: tu model nie jest wykorzystywany do generowania treści, a interfejs API – do transportu (stealth C2). To potwierdza obserwację OpenAI, że aktorzy głównie „dokładają AI do starych playbooków”.

Podsumowanie / kluczowe wnioski

SesameOp pokazuje, że governance nad ruchem do usług AI i bezpieczeństwo tożsamości API to nowe „must-have” w SOC. Należy inwentaryzować legalne użycia api.openai.com, egzekwować egress allowlisty, szukać behawioralnych anomalii .NET oraz artefaktów na hostach. Dobra współpraca z dostawcami (tu: Microsoft & OpenAI) przyspiesza neutralizację takich nadużyć.

Źródła / bibliografia

  1. ENISA Threat Landscape 2025 (TLP:CLEAR), październik 2025. (Trendy wykorzystania AI przez aktorów zagrożeń.)
  2. Microsoft Security Blog — „SesameOp: Novel backdoor uses OpenAI Assistants API for command and control”, 3 listopada 2025. (Podstawowa analiza techniczna, detekcje, hunting.) (Microsoft)
  3. OpenAI — „Disrupting malicious uses of AI: October 2025”. (Kontekst nadużyć usług AI, polityka egzekwowania.) (OpenAI)
  4. BleepingComputer — „Microsoft: SesameOp malware abuses OpenAI Assistants API in attacks”, 3 listopada 2025. (Zewnętrzne potwierdzenie i streszczenie.) (BleepingComputer)
  5. The Hacker News — „Microsoft Detects 'SesameOp’ Backdoor Using OpenAI’s API…”, 4 listopada 2025. (Dodatkowe omówienie, konsolidacja faktów.) (The Hacker News)

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”

Od ataków zewnętrznych do zagrożeń insiderskich: jak działa chińskie szpiegostwo gospodarcze

Wprowadzenie do problemu / definicja luki

Najnowsza analiza ITIF opisuje „ekosystem” chińskiego szpiegostwa gospodarczego, który łączy operacje cybernetyczne, rekrutację insiderów oraz pozornie legalne transfery technologii i talentów. Autor wskazuje, że programy rekrutacyjne, podmioty „prywatne” współpracujące z aparatem państwowym oraz instrumenty prawne (np. ustawa wywiadowcza) tworzą spójny mechanizm pozyskiwania własności intelektualnej i know-how z USA oraz państw sojuszniczych.

W skrócie

  • Zagrożenie jest systemowe: państwo, przemysł i środowisko akademickie w ChRL działają komplementarnie.
  • Insiderzy nadal najbardziej bolesni: od rekrutacji po „wyprowadzanie” TSI (trade secrets).
  • Krytyczna infrastruktura pod stałą presją: działalność grup pokroju Volt Typhoon ukierunkowana na pre-pozycjonowanie się w sieciach IT.
  • Skala i determinacja: FBI ocenia zagrożenie ze strony ChRL jako szerokie, ukierunkowane na niemal każdy sektor gospodarki.
  • Trend globalny: podobne wnioski publikują europejskie służby (np. NCSC dot. APT31 i ingerencji w procesy demokratyczne).

Kontekst / historia / powiązania

Chińskie dokumenty strategiczne (m.in. „Made in China 2025”) i polityka military-civil fusion wzmacniają presję na przyspieszony transfer technologii w kluczowych domenach (IT, lotnictwo, energia, bio). ITIF przypomina też, że narzędzia prawne (np. ustawa o wywiadzie z 2017 r.) nakładają na firmy obowiązek współpracy z organami bezpieczeństwa, co zaciera granicę między sektorem publicznym a „prywatnym”.

W tym samym czasie USA i partnerzy publikują wspólne ostrzeżenia techniczne przed długotrwałymi, nisko-szumowymi operacjami ChRL w infrastrukturze krytycznej (camp. Volt Typhoon).

Analiza techniczna / szczegóły luki

Vectory pozyskiwania (wg przekrojowych materiałów ITIF, CISA i FBI):

  • Cyber „living-off-the-land” (LotL): wykorzystanie natywnych narzędzi systemowych, kont wieloczynnikowych z osłabioną hybrydową ochroną, tunelowanie ruchu i łańcuchy proxy C2 – celem jest utrzymanie się w środowisku latami bez głośnego malware.
  • Insiderzy / transfer talentów: rekrutacja naukowców i inżynierów (następcy „Thousand Talents”) oraz fronty biznesowe w USA służące pozyskaniu TSI.
  • Persistent access: budowanie przyczółków w sieciach operatorów i dostawców łańcucha dostaw (telemetria ograniczona, segmentacja słaba).

Cele branżowe: sektory o wysokiej wartości dla konkurencyjności i obronności – lotnictwo, półprzewodniki, energia, biotechnologia, telekomunikacja. To pokrywa się z oceną FBI: „niemal każdy sektor gospodarki USA” doświadcza prób pozyskania IP/know-how.

Praktyczne konsekwencje / ryzyko

  • Ryzyko operacyjne: wpięcia pre-pozycjonujące w OT/IT mogą skutkować osłabieniem odporności i gotowości (np. scenariusze „śpiących” dostępów w sieciach operatorów).
  • Ryzyko strategiczne: przyspieszony rozwój konkurencyjnych produktów/usług dzięki kradzionym TSI oraz ich militaryzacja poprzez fuzję cywilno-wojskową.
  • Ryzyko regulacyjne i reputacyjne: wzrost wymogów nadzorczych (USA/EU/UK) i ekspozycja w komunikatach rządowych (np. NCSC dot. APT31) wpływa na due diligence i koszty zgodności.

Rekomendacje operacyjne / co zrobić teraz

1) Łowiectwo na techniki Volt Typhoon (LotL)

  • Priorytetowo wdrożyć detekcję anomalii w ruchu east-west, analitykę kont uprzywilejowanych, JEA/JIT, oraz rejestrowanie PowerShell/WSL/WinRM. Skorzystać z checklist i sygnałów IOC/IOA z poradników CISA.

2) Twarda segmentacja i e2e-telemetria

  • Oddzielenie stref OT/IT, kontrola ruchu administracyjnego, wymóg mTLS i kontrola urządzeń zdalnych, pełne logowanie DNS/HTTP i tożsamości.

3) Odporność na insiderów

  • Kontrole dostępu oparte na need-to-know, monitoring wycieków z repozytoriów, ochrona tajemnic przedsiębiorstwa (DLP, watermarking), background screening w rolach krytycznych i polityka wyjścia pracownika (offboarding) z audytem artefaktów. Rekomendacje ITIF podkreślają wagę proaktywnego podejścia.

4) Ćwiczenia „assume breach” i tabletopy łączone (CSIRT + HR + Legal)

  • Scenariusze: (a) dostęp trwały bez malware, (b) pracownik z kontem prywatnym w chmurze, (c) rekrut wrażliwy na konflikty interesów.

5) Due diligence dostawców i inwestycji

  • Weryfikacja powiązań właścicielskich, klauzule o ochronie TSI, ograniczenia w transferze technologii i kontroli kodu; korzystać z ostrzeżeń międzyagencyjnych i nowych poradników (2025) dot. aktywności państwowych aktorów.

6) Program wymiany informacji

  • Włączenie się do ISAC/CSIRT i regularne „intel-to-action” na bazie biuletynów CISA/FBI.

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

  • ChRL vs. zwykły APT: nacisk na długotrwałe, ciche utrzymanie dostępu w infrastrukturze i parowanie cyber z rekrutacją insiderów – nie tylko „kradzież plików”, ale ekosystem pozyskiwania wiedzy.
  • Kontekst europejski: atrybucje NCSC wobec APT31 dotyczyły również prób ingerencji w procesy demokratyczne, co rozszerza wektor wpływu poza czyste IP theft.

Podsumowanie / kluczowe wnioski

Chińskie szpiegostwo gospodarcze to strategiczny, wielotorowy wysiłek państwa – od cyberoperacji LotL po rekrutację insiderów i instrumenty prawne wymuszające współpracę firm. Obrona wymaga prewencji i przewidywania: proaktywnego threat huntingu, segmentacji, kontroli tożsamości oraz dojrzałego programu anty-insider. Organizacje powinny mapować swoje „koronne klejnoty” na taktyki opisywane w doradztwach CISA/FBI i wdrażać procedury reagowania z udziałem HR/Legal.

Źródła / bibliografia

  1. ITIF – „From Outside Assaults to Insider Threats: Chinese Economic Espionage” (03.11.2025). (itif.org)
  2. CISA – AA24-038A / wspólne doradztwo ws. Volt Typhoon (07.02.2024). (cisa.gov)
  3. FBI – Wystąpienia Dyrektora C. Wraya dot. skali zagrożenia (15–18.04.2024). (Federal Bureau of Investigation)
  4. NCSC (UK) – Komunikat o APT31 i celowaniu w instytucje demokratyczne (25.03.2024). (NCSC)
  5. CISA – Doradztwo 2025 nt. działań sponsorowanych przez ChRL (03.09.2025). (cisa.gov)