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)
Krytyczna podatność w CoolType.dll (obsługa czcionek) programu Adobe Reader/Acrobat umożliwia zdalne wykonanie kodu po otwarciu specjalnie spreparowanego pliku PDF zawierającego wadliwy TTF z tabelą SING. Błąd był aktywnie wykorzystywany od września 2010 r.; naprawiono go w wersjach 9.4 / 8.2.5 (oraz później w Reader X z sandboxem). Mapowanie ATT&CK: T1566.001 (dostarczenie załącznikiem), T1204.002 (uruchomienie przez użytkownika), T1203 (exploitation for client execution). W praktyce szukaj: niezwykłych procesów potomnych uruchamianych przez AcroRd32.exe/Acrobat.exe, gwałtownych crashy modułu CoolType.dll (Event ID 1000) i łącz to z telemetrią pocztową.
Krótka definicja techniczna
CVE-2010-2883 to buforowy przepełnienie stosu w CoolType.dll (parsowanie tabeli SING w czcionce TrueType osadzonej w PDF), wyzwalane przy otwarciu złośliwego dokumentu PDF; skutkiem jest crash lub wykonanie dowolnego kodu w kontekście aplikacji.
Gdzie występuje / przykłady platform
Windows, macOS, UNIX (Reader 9.3.4 i starsze; Acrobat 9.3.4 i starsze; Reader/Acrobat 8.x do 8.2.4) — systemy te były podatne przed aktualizacją do 9.4/8.2.5.
Środowiska korporacyjne (AD/M365): najczęściej wektor dostarczenia to spearphishing z PDF (Exchange/M365). Mapowanie do ATT&CK Initial Access.
Chmura (AWS/GCP/Azure): pliki bywały hostowane na publicznych zasobnikach (np. S3); przydaje się telemetria dostępu (CloudTrail/S3 Access Logs) do analizy dystrybucji. [Uwaga: nie jest to błąd usług chmurowych, a jedynie kanał dostarczenia.]
K8s/ESXi: brak bezpośredniego wpływu — jedynie gdy stacje VDI/WorkSpaces otwierają PDF.
Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)
PDF może osadzać czcionki TTF/OTF. W podatnych wersjach Reader/Acrobat błędny kod w bibliotece CoolType nieprawidłowo łączył ciągi (m.in. z pola uniqueName w tabeli SING) wykonując niebezpieczne operacje na buforze (np. strcat), co prowadziło do przepełnienia stosu. Napastnik, dołączając tak przygotowany TTF do PDF, osiągał wykonanie kodu po otwarciu dokumentu przez ofiarę. We wrześniu 2010 r. raportowano aktywną eksploatację w kampaniach spearphishingowych. Adobe wydało aktualizacje 8.2.5/9.4 (APSB10‑21), zaś Reader X (11/2010) wprowadził Protected Mode (sandbox), znacząco utrudniający dalsze nadużycia klas tego typu błędów.
ParentImage=…\AcroRd32.exe, Image=…\powershell.exe, CommandLine zawiera -enc/URL
Wzorzec po‑eksploatacyjny (T1204.002/T1203)
Sysmon
1 (ProcessCreate)
Jak wyżej, bogatsze pola (hash, integrator)
Image, ParentImage, CommandLine
Sysmon
3 (NetworkConnect)
Nietypowe połączenia z procesu Reader/Acrobat po otwarciu PDF
AcroRd32.exe → nietypowe domeny/IP
Koreluj z 4688/1
Sysmon
11/15 (FileCreate/FileStream)
Upuszczenia binariów do %APPDATA%\*\Temp
Nazwy losowe .exe/.dll
Windows Application
1000/1001
Crash AcroRd32.exe/Acrobat.exe z modułem CoolType.dll (DoS/corruption)
„Faulting module name: CoolType.dll”
Częsty artefakt przy próbie eksploatacji
Poczta (M365/Exchange)
Threat/Policy events
Załączniki PDF oznaczone jako złośliwe/heurystyka fontów; kampanie spearphishing
Identyfikatory alertów EOP/Defender for Office
Mapuj do T1566.001
Proxy/HTTP
—
Pobrania PDF z domen jednorazowych/S3
UA programu pocztowego lub przeglądarki
AWS CloudTrail (S3 Data Events)
GetObject
(Gdy dystrybucja przez S3) masowe pobrania .pdf z publicznych bucketów
eventSource="s3.amazonaws.com" AND key LIKE "%.pdf"
Kanał dostarczenia, nie wektor wykonania
(Zakres podatnych wersji i platform: Adobe Advisory/US‑CERT).
Detekcja (praktyczne reguły)
Sigma (Windows / process_creation)
title: Acrobat/Reader Spawns Suspicious Child (CVE-2010-2883 Follow-on)
id: 2b2b8f2a-9a0e-4e7d-9b1c-4b3d9c9b6a88
status: test
description: >
Wykrywa podejrzane procesy potomne uruchamiane przez AcroRd32.exe/Acrobat.exe,
co może wskazywać na eksploatację PDF (np. CVE-2010-2883) i fazę post-exploitation.
references:
- https://attack.mitre.org/techniques/T1204/002/
- https://attack.mitre.org/techniques/T1203/
logsource:
product: windows
category: process_creation
detection:
sel_parent:
ParentImage|endswith:
- '\AcroRd32.exe'
- '\Acrobat.exe'
sel_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\msiexec.exe'
sel_cmd:
CommandLine|contains:
- ' -enc '
- 'http://'
- 'https://'
- 'FromBase64String'
condition: sel_parent and sel_child or (sel_parent and sel_cmd)
falsepositives:
- Otwarcie linku z PDF uruchamiające przeglądarkę (dopuszczalne; dodaj allowlist)
- Wtyczki lub integracje korporacyjne Acrobat (rzadko)
level: high
tags:
- attack.t1204.002
- attack.t1203
- attack.t1566.001
(Mapowanie ATT&CK)
Splunk (SPL)
(index=win* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
OR (sourcetype="WinEventLog:Security" EventCode=4688))
| eval ParentImage=coalesce(ParentImage, ParentProcessName, process_parent_image)
| eval Image=coalesce(Image, New_Process_Name, process_name)
| eval CommandLine=coalesce(CommandLine, Process_Command_Line, cmdline)
| search (like(ParentImage, "%\\AcroRd32.exe") OR like(ParentImage, "%\\Acrobat.exe"))
| search (like(Image, "%\\cmd.exe") OR like(Image, "%\\powershell.exe") OR like(Image, "%\\wscript.exe") OR like(Image, "%\\cscript.exe")
OR like(Image, "%\\rundll32.exe") OR like(Image, "%\\regsvr32.exe") OR like(Image, "%\\msiexec.exe")
OR CommandLine="* -enc *" OR CommandLine="*http*")
| stats earliest(_time) as firstSeen latest(_time) as lastSeen values(CommandLine) as cmd by host user ParentImage Image
| convert ctime(firstSeen) ctime(lastSeen)
KQL (Microsoft Defender for Endpoint / Sentinel)
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("AcroRd32.exe","Acrobat.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe","msiexec.exe")
or ProcessCommandLine has_any (" -enc ","http://","https://","FromBase64String")
| project TimeGenerated, DeviceName, InitiatingProcessAccountName,
InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine
| order by TimeGenerated desc
CloudTrail (CloudWatch Logs Insights) – dystrybucja przez S3 (opcjonalnie)
fields @timestamp, eventName, userAgent, requestParameters.bucketName as bucket,
requestParameters.key as key, sourceIPAddress
| filter eventSource = "s3.amazonaws.com" and eventName = "GetObject" and key like /.*\.pdf$/i
| stats count() as downloads by bucket, key, sourceIPAddress, userAgent
| sort downloads desc
Elastic / EQL
process where event.type == "start" and
process.parent.name in ("AcroRd32.exe","Acrobat.exe") and
process.name in ("cmd.exe","powershell.exe","wscript.exe","cscript.exe",
"rundll32.exe","regsvr32.exe","msiexec.exe")
Heurystyki / korelacje
Łańcuch rodzic‑potomek:AcroRd32.exe/Acrobat.exe → [„LOLBins”] powershell/wscript/rundll32 → połączenie sieciowe → zapis pliku w %APPDATA%.
Crash & połączenie: bliski w czasie Application Error 1000 (moduł CoolType.dll) i nowa aktywność procesu skryptowego.
Rzadkość: anomalna dla danej stacji liczba otwarć PDF zakończonych utworzeniem procesu systemowego lub połączeniem wychodzącym.
Poczta: alerty EOP/Defender for Office skorelowane z otwarciem konkretnego załącznika PDF (T1566.001).
False positives / tuning
Legalne akcje: kliknięcie linku w PDF (otwarcie przeglądarki) — odfiltrować „browser allowlist”.
Aktualizacje/Wtyczki: rzadkie scenariusze, w których PDF uruchamia dozwolony instalator/wtyczkę (np. msiexec w integracjach przedsiębiorstwa).
Tuning pól: wymagaj co najmniej jednego warunku: CommandLine z URL/-enc, hash niepodpisanego potomka, brak reputacji, lub nietypowe remote IP.
Playbook reagowania (IR)
Zatrzymaj rozprzestrzenianie: izoluj host(y) z alertami (EDR).
Przegląd KEV / zarządzanie podatnościami — CVE-2010-2883 traktować jako historycznie wykorzystywaną podatność (wysoki priorytet, jeśli legacy).
Uwaga końcowa: Podatność jest historyczna, ale nadal pojawia się w dziedzictwie (legacy) oraz w zestawach testowych. Kluczowe są: aktualizacje, sandboxing czytnika PDF oraz detekcje łańcuchów po‑eksploatacyjnych z procesów AcroRd32.exe/Acrobat.exe.
Luka w Windows Shell umożliwia zdalne wykonanie kodu przy samym wyświetleniu ikony spreparowanego skrótu .LNK/.PIF (bez kliku). Załatana w biuletynie MS10‑046 (KB2286198).
Realne zagrożenie: USB/udziały sieciowe/WebDAV → otwarcie folderu z LNK uruchamia kod napastnika. To był kluczowy wektor Stuxnet.
Mapowanie na ATT&CK: T1203, T1204.002, T1091 (replikacja przez nośniki).
Detekcja: Sysmon EID 7 (ImageLoad) z explorer.exe ładuje DLL z nośnika wymiennego, EID 1 (ProcessCreate) dla rundll32.exe z literą dysku USB; korelacja z USBDriveMounted w MDE.
Remediacja: Patch MS10‑046, blokady ASR/Device Control na USB, ograniczenie AutoRun/AutoPlay, polityki nośników.
Krótka definicja techniczna
CVE‑2010‑2568 to błąd w parsowaniu skrótów przez Windows Shell: podczas ładowania ikony skrótu (.LNK/.PIF) system może załadować i wykonać bibliotekę DLL wskazaną w polu zasobu ikony. Do eksploatacji dochodzi już na etapie renderowania ikon w Explorerze (i innych parserach), co daje RCE z uprawnieniami zalogowanego użytkownika.
Gdzie występuje / przykłady platform
Windows: XP SP3, Server 2003 SP2, Vista SP1/SP2, Server 2008 (w tym R2), Windows 7 — wszystkie dotknięte i ocenione jako Critical w MS10‑046 (serwer Core również podatny w niektórych scenariuszach).
Active Directory / DC: dotyczy, jeśli kontrolery domeny to ww. wersje Windows.
Chmury (AWS/Azure/GCP): Windows VM/WorkSpaces/VDI dziedziczą podatność do czasu aktualizacji.
ESXi/K8s/M365: sama luka dot. Windows; środowiska te są istotne jako źródła logów (Sentinel, Elastic, SIEM) i kontroli USB (MDE Device Control).
Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)
Atakujący tworzy skrót .LNK, którego metadane (np. zasób ikony) wskazują DLL położoną na nośniku wymiennym (USB), udziale UNC/WebDAV lub innym zasobie. Windows Explorer przy renderowaniu ikony odwołuje się do tej ścieżki i ładuje bibliotekę, co w wariancie podatnym daje arbitralne wykonanie kodu — bez interakcji użytkownika i bez uruchamiania celu skrótu. Skuteczność wynika z (1) powszechnego przeglądania folderów poprzez GUI, (2) faktu, że ikony ładowane są automatycznie oraz (3) łatwości wprowadzenia LNK na host (np. USB). Microsoft załatał błąd w MS10‑046/KB2286198, poprawiając walidację referencji do ikon.
Historyczny kontekst:Stuxnet używał CVE‑2010‑2568 do propagacji m.in. przez nośniki, co pozwalało pokonać segmentacje/air‑gap w środowiskach ICS.
Artefakty i logi (co i gdzie obserwować)
Źródło/produkt
Zdarzenie / ID
Co szukać
Uwagi
Sysmon
EID 7 (Image loaded)
Image = *\explorer.exeiImageLoaded wskazuje na ścieżkę z literą dysku (np. E:\*.dll), brak podpisu
EID 7 domyślnie wyłączony; włączyć selektywnie dla explorer.exe.
Sysmon
EID 1 (Process Create)
rundll32.exe lub regsvr32.exe z argumentem do X:\*.dll; rodzic explorer.exe
Częsty łańcuch po wczytaniu złośliwej biblioteki.
Windows Security
4688 (Process Create)
Jak wyżej (jeśli brak Sysmon)
Mniej kontekstu niż Sysmon.
MDE (Defender XDR)
DeviceImageLoadEvents
Ładowanie DLL przez explorer.exe z nie‑systemowych wolumenów
CloudTrail rejestruje API/AWS account activity, nie telemetrykę hosta. Używać CloudWatch Logs dla agentów zdarzeń Win/Sysmon.
K8s audit / M365 ops
—
[brak danych / nie dotyczy]
Luka dotyczy Windows Shell lokalnie.
Detekcja (praktyczne reguły)
Sigma (Sysmon ImageLoad + korelacja)
title: Possible CVE-2010-2568 Exploitation via Explorer DLL Load from Removable
id: 9d1f5c1f-9b0e-4f16-9d6a-ef7a3a2c2568
status: experimental
description: Detects explorer.exe loading an unsigned DLL from a non-system drive (often USB) – pattern linked to CVE-2010-2568 exploitation.
references:
- https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-046
- https://attack.mitre.org/techniques/T1091/
logsource:
product: windows
service: sysmon
category: image_load
detection:
selection:
Image|endswith: '\explorer.exe'
ImageLoaded|re: '^[A-Z]:\\.*\.dll$'
unsigned:
Signed: 'false'
condition: selection and unsigned
fields:
- Image
- ImageLoaded
- Signed
- SignatureStatus
- Hashes
level: high
tags:
- attack.t1203
- attack.t1091
Splunk (SPL) – 2 wzorce
A) DLL ładowana przez Explorera z dysku poza systemem:
index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
EventCode=7 Image="*\\explorer.exe"
| where like(ImageLoaded, "%:\\%.dll")
| stats count min(_time) as first_seen max(_time) as last_seen by host Image ImageLoaded Signed SignatureStatus
B) Próba rundll32 z literą dysku (po USB mount):
index=sysmon EventCode=1 Image="*\\rundll32.exe" ParentImage="*\\explorer.exe"
| where match(CommandLine, "[A-Z]:\\\\.+\\.dll")
| stats values(CommandLine) as cmd by host, ParentImage, Image
KQL (Microsoft Defender XDR / Sentinel)
Korelacja USB → ładowanie DLL przez Explorera (≤5 min):
let usb = DeviceEvents
| where ActionType == "UsbDriveMounted"
| extend DriveLetter = tostring(parse_json(AdditionalFields).DriveLetter)
| project DeviceId, DeviceName, MountTime=Timestamp, DriveLetter;
DeviceImageLoadEvents
| where InitiatingProcessFileName =~ "explorer.exe"
| where FolderPath matches regex @"^[A-Z]:\\.*\.dll$"
| project DeviceId, DeviceName, LoadTime=Timestamp, FolderPath, InitiatingProcessFileName
| join kind=innerunique (usb) on DeviceId
| where LoadTime between (MountTime .. MountTime + 5m)
| order by LoadTime desc
Uwaga: nazwy tabel/kolumn zgodnie z referencją AH; dostępność zależy od wdrożenia MDE.
(Aktywność CloudTrail zostaw do monitoringu API AWS).
Elastic / EQL
Proces z USB (rundll32) po Explorerze:
process where event.category == "process"
and process.name == "rundll32.exe"
and process.parent.name == "explorer.exe"
and process.command_line regex "^[A-Z]:\\\\.*\\.dll"
Ładowanie biblioteki (ECS event.category: "library") przez Explorera:
any where event.category == "library"
and process.name == "explorer.exe"
and dll.path regex "^[A-Z]:\\\\.*\\.dll"
(ECS pola dll.* dla zdarzeń ładowania bibliotek).
Heurystyki / korelacje
USB mount → (≤5 min) → explorer.exe ładuje nienadzorowaną DLL z tej litery → (≤10 s) → rundll32.exe/regsvr32.exe z tą ścieżką.
Brak podpisu / SignatureStatus ≠ Valid dla DLL ładowanych przez Explorera.
Nowe LNK pojawiające się na USB lub udziałach sieciowych; LNK wskazujące na nietypowe lokalizacje (\\server\share, \\?\GLOBALROOT\Device\...).
Zbieżność z politykami Device Control (odmowy/alerty MDE przy USB).
False positives / tuning
Legalne narzędzia portable na USB mogą dynamicznie ładować DLL (wyjątki po hashach/podpisach).
Środowiska dev/test uruchamiające biblioteki z nietypowych ścieżek — odseparuj po OU/Tagach i godzinach pracy.
Rozważ wąskie filtrowanie Sysmon EID 7 (np. tylko Image="*\explorer.exe"), by ograniczyć wolumen.
Playbook reagowania (IR)
Triaging & containment
Odizoluj host w EDR/EDR‑NAC. Zanotuj literę/identyfikator USB.
W MDE sprawdź oś czasu: UsbDriveMounted → DeviceImageLoadEvents/rundll32. (
Zbieranie artefaktów
Zabezpiecz nośnik i kopię folderu z LNK. Oblicz hashe (SHA‑256).
Z Sysmon wyciągnij EID 7/1 i towarzyszące 4688.
Analiza
Sprawdź podpisy DLL, nietypowe eksporty, ścieżki.
Koreluj z innymi hostami (ta sama litera USB, te same LNK).
Remediacja
Wymuś instalację KB2286198 / MS10‑046 (dla systemów historycznych) i aktualizacje.
Włącz/egzekwuj ASR / Device Control dla USB, wyłącz AutoRun/AutoPlay.
Higiena i komunikacja
Blokada podpisu/uruchamiania z USB w GPO/MDE.
Komunikat dla użytkowników nt. bezpiecznego użycia nośników.
Stuxnet (2010–2011): wykorzystanie CVE‑2010‑2568 do propagacji m.in. przez nośniki wymienne (i do eksfiltracji na systemy air‑gapped); Microsoft opisał eksploatację w MS10‑046, a szczegółowy dossier Symanteca dokumentuje oś czasu i wektory.
Lab (bezpieczne testy) — symulacja detekcji, nie exploit
Cel: wygenerować telemetrię, która powinna uruchomić reguły bez realnego wykorzystania luki.
Przygotuj: host testowy z Sysmon (EID 1 i selektywnie EID 7 dla explorer.exe) i MDE.
Włóż czysty pendrive (zapisz jego literę; w MDE powstanie UsbDriveMounted).
Uruchom próbę ładowania DLL z USB (bez powodzenia, ale z logiem):
# Stwórz pusty plik DLL (nie zostanie załadowany poprawnie)
New-Item -Path "E:\test.dll" -ItemType File | Out-Null
# Wywołaj rundll32 ze ścieżką na USB (wygeneruje EID 1 i próbę dostępu)
Start-Process -FilePath "$env:SystemRoot\System32\rundll32.exe" -ArgumentList "E:\test.dll,EntryPoint" -NoNewWindow
Opcjonalnie: skopiuj zwykły skrót .lnk na USB (bez złośliwych właściwości) i obserwuj zapisy plikowe.
Zweryfikuj alerty/reguły: Sigma/Splunk/KQL/Elastic z sekcji 7.
Nie twórz ani nie uruchamiaj spreparowanych LNK z osadzonymi DLL — lab ma charakter wyłącznie defensywny.
M1040 — Behavior Prevention on Endpoint: reguły ASR blokujące uruchamianie z nośników.
M1042 — Disable or Remove Feature or Program: wyłącz Autorun/AutoPlay; ogranicz użycie USB.
Powiązane techniki:
T1203 — Exploitation for Client Execution – Eksploatacja luki w komponencie klienckim (Windows Shell) dla uzyskania wykonania na hoście ofiary. Takt.: Execution; Wersja 1.5 (2025‑10‑24).
T1204.002 — User Execution: Malicious File -Skrót/LNK jako złośliwy plik wywołujący łańcuch wykonania; często po spear‑phishingu lub przez udostępnione zasoby. Takt.: Execution; Wersja 1.6 (2025‑10‑24).
T1091 — Replication Through Removable Media – Dystrybucja przez USB, w tym historyczny przypadek Stuxnet używający CVE‑2010‑2568 do propagacji. Taktyki: Initial Access, Lateral Movement; Wersja 1.3 (2025‑10‑24).
T1547.009 — Shortcut Modification – Nie ta luka, ale pokrewne użycie .LNK dla Persistence (autostart/Startup). Warto monitorować modyfikacje LNK w lokacjach autostartu.
Źródła / dalsza lektura
Microsoft: MS10‑046 — Vulnerability in Windows Shell Could Allow Remote Code Execution (2286198). (Microsoft Learn)
Zbierasz Sysmon EID 1/7 i masz selektory dla explorer.exe?
Masz reguły korelacji USB mount → ImageLoad/ProcessCreate?
Monitorujesz tworzenie/modyfikacje .LNK w autostarcie i na USB?
Utrzymujesz allow‑listy podpisów/ścieżek dla legalnych portable?
CISO (strategiczne):
Potwierdzone wdrożenie MS10‑046 na hostach historycznych / obrazach VM.
Polityki Device Control / ASR: blokada uruchamiania z USB, audyt wyjątków.
Wyłączone Autorun/AutoPlay i egzekwowane szyfrowanie nośników.
Procedury reagowania na incydenty z udziałem nośników wymiennych (izolacja, zabezpieczenie dowodów, komunikacja).
Uwaga końcowa: CVE‑2010‑2568 jest historycznie krytyczna i szeroko udokumentowana. Współczesne systemy Windows mają łatę, ale wektory LNK/USB pozostają popularne (np. jako malicious file w T1204.002). Detekcja zachowania i higiena USB są kluczowe nawet po załataniu luki.
Komendy Windows jako pierwsza linia analizy incydentu
W codziennej pracy analityka bezpieczeństwa (SOC) umiejętność szybkiego korzystania z wbudowanych poleceń Windows bywa bezcenna. Gdy liczy się czas – na przykład podczas triage incydentu lub szybkiego forensics – dostęp do graficznych narzędzi może być ograniczony, a instalacja dodatkowego oprogramowania niemożliwa.
W rejestrze Open VSX wykryto fałszywe rozszerzenie dla języka Solidity: juan-bianco.solidity-vlang. Początkowo niewinne wydanie z 31 października 2025 r. zostało dzień później zaktualizowane o złośliwe możliwości — już po zdobyciu dużej liczby pobrań. Rozszerzenie zawierało trojana zdalnego dostępu SleepyDuck, który komunikuje się z serwerem dowodzenia m.in. poprzez kontrakt na blockchainie Ethereum, co utrudnia neutralizację infrastruktury C2. Z pakietu skorzystały dziesiątki tysięcy użytkowników Open VSX, w tym popularnych forków VS Code (Cursor, Windsurf).
W skrócie
Wejście: fałszywe rozszerzenie „Solidity” w Open VSX.
Ładunek: RAT SleepyDuck z mechanizmem C2 opartym na kontrakcie Ethereum (odporność na wyłączenie domeny).
Aktywacja: start edytora, otwarcie pliku .sol lub kompilacja.
Cel: kradzież danych systemowych i wykonywanie poleceń; ryzyko dalszej eskalacji.
Reakcja: Open VSX rotuje tokeny wydawnicze i wdraża dodatkowe kontrole po serii incydentów łańcucha dostaw.
Kontekst / historia / powiązania
Ostatnie miesiące przyniosły presję na ekosystemy rozszerzeń edytorów. Wiz Research ujawnił >550 wyciekłych sekretów, w tym dostępy wydawnicze do marketplace’ów, co umożliwia przestępcom wpychanie złośliwych aktualizacji do już popularnych rozszerzeń (autoupdate robi resztę). Open VSX jest szczególnie atrakcyjny dla użytkowników Cursor/Windsurf, bo nie mogą oni korzystać z oficjalnego Microsoft Visual Studio Marketplace.
Open VSX/Eclipse poinformował następnie, że incydenty zostały opanowane do 21 października 2025 r. oraz zapowiedział krótsze TTL tokenów, łatwiejsze unieważnianie, skany przy publikacji i wymianę informacji z innymi platformami.
Warto pamiętać, że Solidity-devowie są celem od dawna: w lipcu 2025 r. opisano przypadek kradzieży ~500 000 USD po instalacji fałszywego rozszerzenia z Open VSX/Cursor.
Analiza techniczna / szczegóły luki
Wejście i maskowanie: wydanie 0.0.7 było „czyste”; 0.0.8 (1 listopada) dołożyło komponenty złośliwe. Zanim to nastąpiło, rozszerzenie zdążyło nabić ~14 tys. pobrań, co zwiększyło bazę ofiar na starcie. Twórcy złośliwego pakietu stosowali też taktyki pozycjonowania (aktualność, pobrania) typowe dla ataków na marketplace’y.
Warunki aktywacji: start IDE, otwarcie pliku .sol lub wywołanie komendy kompilacji Solidity.
Ładunek i telemetria: komponent inicjalizujący podszywa się pod webpack.init() i ładuje payload, który zbiera hostname, username, MAC, strefę czasową oraz uruchamia sandbox wykonywania komend.
C2 i odporność: moduł wybiera najszybszego dostawcę Ethereum RPC, odczytuje kontrakt zawierający bieżącą konfigurację (np. nowy adres C2, interwały), a gdy domena C2 padnie, polecenia i aktualizacje są pobierane prosto z łańcucha. To zapewnia przetrwanie kampanii mimo blokad DNS/hostingu.
Praktyczne konsekwencje / ryzyko
Ryzyko operacyjne: zdalne wykonywanie poleceń w środowisku deweloperskim → kradzież sekretów (tokeny, klucze), modyfikacja repozytoriów, dołączanie do kolejnych ataków łańcucha dostaw.
Ryzyko finansowe: historycznie ataki na rozszerzenia „Solidity” prowadziły do utracenia środków z portfeli krypto i kompromitacji stacji roboczych.
Ryzyko systemowe:wycieki tokenów wydawniczych tworzą masowy punkt zapalny — atakujący może wypchnąć złośliwą AKTUALIZACJĘ do całej bazy instalacji rozszerzenia.
Rekomendacje operacyjne / co zrobić teraz
Dla zespołów bezpieczeństwa / dev platform:
Inwentaryzacja i blokady: utrzymujcie listę dozwolonych rozszerzeń (allowlist) i centralną dystrybucję rozszerzeń. Wyłączcie instalacje spoza zaufanych wydawców.
Zarządzanie aktualizacjami: rozważcie opóźnione autoupdate rozszerzeń + promowanie wersji po skanowaniu (staging).
Monitoring IDE: detekcje na uruchamianie skryptów z katalogów rozszerzeń (~/.vscode/extensions, %USERPROFILE%\.vscode\extensions) i nietypowe wywołania PowerShell/cmd przez procesy VS Code/Cursor.
Skany IOCs: blokujcie znane wskaźniki (domeny typu sleepyduck[.]xyz, adresy kontraktów, nietypowe zapytania RPC). (Wg materiałów badawczych, C2 i kontrakt są częścią TTP tej kampanii).
Higiena sekretów: skanowanie repozytoriów i paczek .vsix pod kątem sekretów; rotacja tokenów publikacyjnych; krótkie TTL i prefiksy ułatwiające detekcję. (To też kierunek zmian po stronie Open VSX).
Dla pojedynczych deweloperów:
Instaluj rozszerzenia wyłącznie od znanych wydawców; weryfikuj historię, kod źródłowy i różnicę między podobnie nazwanymi pakietami (popularna technika podszywania się).
Zredukuj liczbę rozszerzeń do niezbędnego minimum; każde to nowa powierzchnia ataku.
Włącz monitorowanie EDR/XDR na stacjach dev i segregację portfeli krypto (oddzielne hosty/przeglądarki, sprzętowe klucze, brak kluczy na maszynach dev). (Rekomendacje wynikają z analizy incydentów krypto-kradzieży na tle fałszywych rozszerzeń).
Różnice / porównania z innymi przypadkami
SleepyDuck vs. wcześniejsze kampanie (Cursor/Open VSX 2025): wcześniejsze przypadki częściej stawiały na klasyczny zdalny dostęp (np. ScreenConnect) i kradzież seedów; SleepyDuck wprowadza C2 przez kontrakt Ethereum, co utrudnia wyłączenie kampanii i sprzyja długowieczności złośliwych konfiguracji.
GlassWorm / wycieki tokenów: równoległe kampanie wykorzystywały wycieknięte tokeny wydawnicze do publikowania/zamiany wersji rozszerzeń na złośliwe. Odpowiedzią były rotacje tokenów i skrócenie czasu życia po stronie Open VSX.
Podsumowanie / kluczowe wnioski
Zaufanie do marketplace’ów IDE nie może zastąpić kontroli bezpieczeństwa po stronie organizacji.
Atakujący coraz częściej używają łańcucha bloków jako kanału C2 (odporność na zdejmowanie domen).
Operatory rejestrów (Open VSX) wzmacniają kontrole — rotują tokeny, skracają TTL, dodają skany — ale higiena po stronie wydawców i użytkowników jest równie kluczowa.
Źródła / bibliografia
BleepingComputer — „Fake Solidity VSCode extension on Open VSX backdoors developers” (03.11.2025). (BleepingComputer)
3 listopada 2025 r. media branżowe ujawniły akt oskarżenia wobec trzech obywateli USA — w tym dwóch byłych negocjatorów ds. ransomware i menedżera IR — którym zarzucono działanie jako afilianci gangu ALPHV/BlackCat oraz przeprowadzenie serii ataków na co najmniej pięć firm w USA (służba zdrowia, farmacja, inżynieria, UAV). Według śledczych sprawcy włamali się do sieci, wykradli dane, wdrożyli szyfrator BlackCat i żądali okupu w kryptowalutach. Jedna z ofiar — producent urządzeń medycznych z Tampy — miała zapłacić ok. 1,27 mln USD.
W skrócie
Kim są oskarżeni: Ryan Clifford Goldberg (były IR Manager w Sygnia), Kevin Tyler Martin (były negocjator w DigitalMint) oraz nieujawniony z nazwiska współsprawca.
Zakres działań: włamania, kradzież danych, wdrożenie ransomware ALPHV/BlackCat oraz wymuszenia (maj–listopad 2023; w dokumentach są też uzupełnienia procesowe z 2025 r.).
Kary: za zarzuty dot. wymuszeń i celowego uszkodzenia systemów grożą im dziesiątki lat więzienia; część podejrzanych przebywała w areszcie, inni nie przyznali się do winy.
Model przestępstwa: klasyczny Ransomware-as-a-Service (RaaS) — operatorzy ALPHV dostarczają narzędzia, a afilianci (tu: oskarżeni) prowadzą włamania i dzielą się zyskami.
Kontekst / historia / powiązania
ALPHV/BlackCat to jedna z najaktywniejszych rodzin ransomware od końca 2021 r., znana z ataków na podmioty ochrony zdrowia i infrastrukturę krytyczną oraz z podwójnego (a czasem potrójnego) wymuszania. W 2024 r. FBI, CISA i HHS publikowały wspólne ostrzeżenia techniczne z aktualnymi IOC i TTP.
Analiza techniczna / szczegóły sprawy
Wejście do sieci i eskalacja: Z aktu oskarżenia i doniesień wynika, że sprawcy uzyskiwali nieuprawniony dostęp do środowisk ofiar, eksfiltrowali wrażliwe dane, a następnie wdrażali szyfrator BlackCat. Ofiary obejmowały m.in. firmę medtech z Florydy (Tampa), producenta farmaceutycznego z Maryland, praktykę lekarską i biuro inżynieryjne w Kalifornii oraz wytwórcę dronów w Wirginii. Kwoty żądań mieściły się od 300 tys. do 10 mln USD.
Rola „insiderów branżowych”: Szczególnie alarmujący jest fakt, że oskarżeni pracowali w firmach świadczących usługi IR i negocjacji okupów. Według sądu i materiałów prasowych co najmniej jeden z podejrzanych miał pozostać w areszcie, a drugi nie przyznał się do winy; firmy, w których pracowali, podkreśliły współpracę z organami ścigania i brak wiedzy o przestępstwach.
Model RaaS w praktyce: Zgodnie z opisem TechCrunch, ALPHV/BlackCat funkcjonuje w modelu RaaS: operatorzy tworzą malware i infrastrukturę, a afilianci prowadzą penetrację i eskalację, dzieląc się okupem z operatorem. To klasyczny układ, który obniża barierę wejścia dla atakujących i utrudnia atrybucję.
Praktyczne konsekwencje / ryzyko
Erozja zaufania do łańcucha dostaw bezpieczeństwa: gdy osoby z firm IR/negocjacyjnych stają się afiliantami RaaS, standardowe due-diligence dostawców przestaje wystarczać.
Ryzyko nadużyć informacji wrażliwych: dostęp do artefaktów incydentów, procedur, runbooków i danych klientów może ułatwiać planowanie ataków „pod klienta”. (W sprawie padają przykłady celowania w sektory o wysokiej skłonności do płatności).
Presja regulacyjna i ubezpieczeniowa: zgodność z wytycznymi #StopRansomware (FBI/CISA/HHS) i warunkami polis cyber stanie się bardziej rygorystyczna po tym precedensie.
Rekomendacje operacyjne / co zrobić teraz
Zarządzanie dostawcami i personelem:
KYE (Know Your Employee/Expert) i KYS (Know Your Supplier): ponowna weryfikacja kluczowych konsultantów IR/negocjatorów, kontrole konfliktu interesów, NDA z klauzulami o zakazie afiliacji z RaaS.
Segregacja ról: negocjacje okupowe i IR prowadzone przez oddzielne zespoły/firmy; dostęp „just-in-time” i „least privilege” dla zewnętrznych konsultantów.
Monitoring działań konsultantów: dzienniki EDR/SIEM obejmujące konta dostawców; wymóg sesji uprzywilejowanych przez PAM z pełnym nagraniem.
Higiena techniczna:
Hardening tożsamości: MFA niefiszowalne (FIDO2/Passkeys) dla VPN/RDP/M365; polityki Conditional Access i monitorowanie anomalii logowania.
Segmentacja i EDR: segmentacja sieci + EDR z regułami behawioralnymi dla znanych TTP ALPHV (np. Living-off-the-Land, exfil+encrypt). Wytyczne IOC/TTP patrz #StopRansomware.
DLP i egress control: kontrola wycieku (S3/SharePoint/SMTP), ograniczenia do domen zaufanych, szyfrowanie i tokenizacja danych wrażliwych.
Proces i prawo:
Runbook „bez płatności z zaskoczenia”: rada kryzysowa, ścieżka zgłoszeń do organów ścigania, ocena sankcyjna; minimalizuj rozmowy 1:1 z „negocjatorami z ulicy”.
Kontrakty: klauzule o audytowalności, „right-to-monitor”, odpowiedzialności i karach umownych przy naruszeniach etycznych.
Różnice / porównania z innymi przypadkami
Wcześniej głośne były sprawy „pośredników” i firm odzysku danych ukrywających płatności dla gangów. Tu jednak rdzeniem jest aktywna afiliacja RaaS przez osoby z branży IR/negocjacji, co stanowi jakościowo bardziej niebezpieczny precedens — wprost podważa to model zaufania do dostawców reagowania na incydenty.
Podsumowanie / kluczowe wnioski
Akt oskarżenia z 3 listopada 2025 r. pokazuje, że wektor „insider-affiliate” przestał być scenariuszem teoretycznym.
Organizacje muszą traktować dostawców IR/negocjacji jak użytkowników uprzywilejowanych, z pełną telemetrią i kontrolą.
Utrzymuj zgodność z najnowszymi wytycznymi #StopRansomware i stale weryfikuj partnerów bezpieczeństwa.
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)