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.
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 danych
Zdarzenie/ID
Kluczowe pola / wzorce
Wskazówki analityczne
Windows
Sysmon
EID 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).
Windows
Sysmon
EID 7 (Image Loaded)
ImageLoaded kończy się na \mscomctl.ocx przez WINWORD.EXE
Rzadkie w zdrowych dokumentach; wzmacnia pewność analityki procesów.
Windows
Sysmon
EID 3 (Network Connect)
Image=WINWORD.EXE lub dziecko → połączenia HTTP/HTTPS
Dokumenty przynęt często dociągały payloady; patrz hosty niesankcjonowane.
Windows
Security
Event ID 4688
Procesy jak wyżej; NewProcessName, CreatorProcessName
Alternatywa dla środowisk bez Sysmon.
M365
Defender for Office 365 (AH)
tabele EmailEvents, EmailAttachmentInfo
AttachmentFileType in (rtf, doc, docx); DetectionTechnology/ActionType
Telemetria o załącznikach i kampaniach e‑mail; koreluj z host telemetry.
M365
Unified Audit / MailItemsAccessed
Zdarzenia dostępu do wiadomości
IP, klient, operacja
Pomaga ocenić skalę kompromitacji skrzynek.
AWS
CloudTrail (data events S3)
GetObject, HeadObject
requestParameters.key ~ `.(rtf
docx?)$, userAgent, sourceIPAddress`
Azure/GCP/K8s/ESXi
—
—
—
Nie dotyczy bezpośrednio luki; tylko kontekstowe telemetry (np. proxy, CASB).
(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)
Izoluj hosta z alertu (EDR).
Zabezpiecz artefakty: próbka pliku, prefetch, memoria, Process Tree, DeviceProcessEvents/DeviceImageLoadEvents.
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).
Łańcuch zdarzeń: wyszukaj inne hosty z tym samym załącznikiem (EmailEvents + SHA256 z EmailAttachmentInfo), a następnie koreluj z host telemetry.
Blokady: dodaj hash/URL do blokady w MDO/EOP/Proxy; włącz/utwardź ASR „Block Office creating child processes”.
Naprawa: wymuś instalację MS12‑027, a także późniejszych zbiorczych aktualizacji Office/Windows; wdroż Exploit Protection/DEP/ASLR.
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
Utwórz harmless.rtf zawierający nieszkodliwy tekst oraz nagłówek z ciągiem \object/\objocx (bez osadzania binariów OLE).
Wyślij na skrzynkę testową M365 i sprawdź, czy polityki (MDO Safe Attachments/Sandbox) oraz reguły treści podnoszą alert/znacznik podejrzany.
Koreluj EmailAttachmentInfo ↔ host telemetry (brak uruchomionych procesów wtórnych powinien dać „clean”).
Lab‑2: Analityka „Office → child process” (symulacja zachowania, bez dokumentu)
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).
Sprawdź, czy reguły Sigma/Splunk/KQL wyłapują przypadki dziecko procesu Office (w środowisku produkcyjnym zadziała to na realnych incydentach).
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.EXE → mscomctl.ocx (zwykle pusto). To testuje pipeline logów i zapytania KQL, bez ryzyka.
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
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\...).
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.
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.
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.
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.
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)
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
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.
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.
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.
Ł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.
Ć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.
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
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)
DWI – „The Network and Information Systems (NIS) Regulations 2018” (wymogi i zgłaszanie). (Drinking Water Inspectorate)
GOV.UK – „Cyber Security and Resilience Bill” (kolekcja materiałów dot. projektu ustawy). (GOV.UK)
CISA – „Exploitation of Unitronics PLCs used in Water and Wastewater Systems” (28.11.2023). (cisa.gov)
NCSC – ostrzeżenia dot. PRC/Volt Typhoon i prepozycjonowania w CNI (07.02.2024; 30.11.2023). (ncsc.gov.uk)
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.).
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:.NETOpenAIAgent.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
Zapytanie listy vector stores w koncie; jeśli brak rekordu z hostname — tworzy nowy (wiąże hosta z artefaktami w OpenAI).
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).
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ć.
Microsoft Security Blog — „SesameOp: Novel backdoor uses OpenAI Assistants API for command and control”, 3 listopada 2025. (Podstawowa analiza techniczna, detekcje, hunting.) (Microsoft)
OpenAI — „Disrupting malicious uses of AI: October 2025”. (Kontekst nadużyć usług AI, polityka egzekwowania.) (OpenAI)
BleepingComputer — „Microsoft: SesameOp malware abuses OpenAI Assistants API in attacks”, 3 listopada 2025. (Zewnętrzne potwierdzenie i streszczenie.) (BleepingComputer)
The Hacker News — „Microsoft Detects 'SesameOp’ Backdoor Using OpenAI’s API…”, 4 listopada 2025. (Dodatkowe omówienie, konsolidacja faktów.) (The Hacker News)
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.
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.
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
ITIF – „From Outside Assaults to Insider Threats: Chinese Economic Espionage” (03.11.2025). (itif.org)