Archiwa: Phishing - Strona 79 z 98 - Security Bez Tabu

Salesforce bada kradzież danych klientów po incydencie z aplikacjami Gainsight

Wprowadzenie do problemu / definicja luki

Salesforce poinformował o „nietypowej aktywności” dotyczącej aplikacji publikowanych przez Gainsight (partnera z AppExchange), która mogła umożliwić nieautoryzowany dostęp do danych części klientów poprzez zewnętrzne połączenie aplikacji z instancjami Salesforce. W reakcji Salesforce unieważnił wszystkie aktywne access i refresh tokeny powiązane z tymi aplikacjami oraz tymczasowo usunął je z AppExchange na czas śledztwa. Firma podkreśla, że nie chodzi o lukę w samym rdzeniu platformy CRM, lecz o wektor przez integrację z aplikacją zewnętrzną. Źródła branżowe wiążą sprawę z aktywnością grupy ShinyHunters, która miała wykorzystać poświadczenia powiązane z wcześniejszą kampanią Salesloft/Drift.

W skrócie

  • Kiedy: komunikaty Salesforce oraz publikacje branżowe z 20–21 listopada 2025 r.
  • Co się stało: wykryto nietypową aktywność na aplikacjach Gainsight połączonych z Salesforce; możliwy dostęp do danych przez łącze aplikacyjne. Tokeny OAuth/refresh zostały unieważnione, aplikacje tymczasowo wycofane z AppExchange.
  • Skala: BleepingComputer relacjonuje deklaracje ShinyHunters o dostępie do ~285 instancji Salesforce; trwa weryfikacja.
  • Jakie dane: Gainsight wcześniej potwierdzał, że w incydencie powiązanym z Salesloft/Drift dostępne były głównie dane kontaktowe i treści części zgłoszeń wsparcia (bez załączników).

Kontekst / historia / powiązania

W sierpniu–wrześniu 2025 r. doszło do szerokiej kampanii kradzieży danych z instancji Salesforce przez kompromitację integracji Salesloft/Drift i kradzież tokenów OAuth. Wtedy ShinyHunters przypisywało sobie atak na setki firm. Obecny incydent z Gainsight ma podobny profil — wektor przez zaufane połączenie aplikacyjne, nie przez samą platformę Salesforce. Media odnotowują ciągłość taktyk: „przeskakiwanie” między SaaS-ami przez łańcuch integracji i nadmierne uprawnienia aplikacji.

Analiza techniczna / szczegóły luki

Kluczowym elementem jest OAuth oraz refresh tokeny wydawane dla aplikacji zewnętrznych (Connected Apps). Gdy aplikacja ma szerokie zakresy (scopes) i długowieczne refresh tokeny, atakujący, którzy zdobędą którykolwiek z sekretów (token, client secret, zapisane poświadczenia w logach/zgłoszeniach), mogą:

  1. Wydawać nowe access tokeny, nawet po wygaśnięciu poprzednich.
  2. Przeglądać/eksportować dane CRM przez API (np. obiekty Lead, Contact, Case, Opportunity).
  3. Omijać klasyczne kontrole użytkowników (MFA), bo autoryzacja odbywa się jako integracja aplikacyjna.

Salesforce zareagował zgodnie z najlepszą praktyką: całkowita revokacja tokenów dla dotkniętych aplikacji i ich czasowe wycofanie z AppExchange, aby przerwać łańcuch odświeżania. To minimalizuje możliwość dalszego „mintowania” access tokenów z przejętych refresh tokenów.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla prywatności i zgodności: możliwy wyciek danych klientów B2B (dane kontaktowe, kontekst wsparcia), co uruchamia obowiązki notyfikacyjne (RODO/GDPR) i ryzyka phishingu ukierunkowanego. (Wcześniejsze oświadczenie Gainsight wskazywało właśnie taki profil danych).
  • Ryzyko lateralne w SaaS: jeśli te same kontakty/poświadczenia są używane w innych systemach, możliwe kampanie spear-phishing/smishing na konta zespołów sprzedaży i success.
  • Ryzyko ciągłości działania: doraźne wyłączenie integracji Gainsight może wpływać na procesy CS/CRM, automatyzacje i raportowanie.

Rekomendacje operacyjne / co zrobić teraz

Dla administratorów Salesforce / SecOps:

  1. Inwentaryzuj i tymczasowo ogranicz wszystkie Connected Apps Gainsight (CS, PX, itp.) — sprawdź OAuth scopes, IP Relaxation, Permitted Users, Session Policies.
  2. Wymuś rotację: odłącz i ponownie autoryzuj integracje po oficjalnym przywróceniu; przeprowizjonuj klucze API/sekrety i zmień client secrets po stronie Gainsight.
  3. Przejrzyj logi: Event Monitoring (LoginEvent, ApiEvent, ConnectedAppUsage), Setup Audit Trail, Login History — filtruj po OAuth Client Id Gainsight i anomalie (nietypowe IP/ASN, masowe eksporty, SOQL z SELECT * / LIMIT high).
  4. Zastosuj polityki: High Assurance Sessions dla wrażliwych obiektów, Transaction Security Policies dla masowych zapytań API, MFA/step-up dla administracji integracjami.
  5. Zasada najmniejszych uprawnień: ogranicz scopes i profile integracji; rozdziel instancje/projekty dla środowisk (prod/sandbox).
  6. DLP i monitoring: reguły DLP na eksport CSV/Reports, alerty na nietypową objętość API.
  7. Higiena tokenów: krótszy TTL refresh tokenów, cykliczna rotacja, bez przechowywania sekretów w ticketach/jira/confluence; redakcja danych w zgłoszeniach.
  8. Komunikacja i zgodność: przygotuj notyfikacje do klientów/partnerów (szczególnie w UE), aktualizuj rejestry przetwarzania i oceny DPIA jeśli używasz Gainsight.
  9. Phishing readiness: przeszkol handlowców/CS pod kątem phishingu kontekstowego wykorzystującego realne dane wsparcia.

Różnice / porównania z innymi przypadkami

  • Salesloft/Drift (VIII–IX 2025): masowa kompromitacja tokenów OAuth integracji Drift → dostęp do danych w wielu instancjach Salesforce; nie była to luka w Salesforce, lecz łańcuch dostaw SaaS. Obecny przypadek wygląda podobnie w wektorze (OAuth + integracja), ale dotyczy aplikacji Gainsight i jest świeżo wykrywany/neutralizowany (revokacja tokenów i wycofanie z AppExchange).

Podsumowanie / kluczowe wnioski

  • To nie jest błąd w rdzeniu Salesforce, lecz kompromitacja łańcucha integracji poprzez aplikacje Gainsight.
  • Największym ryzykiem są tokeny odświeżania i szerokie uprawnienia Connected Apps.
  • Natychmiastowa revokacja tokenów przez Salesforce ogranicza skutki, ale zespoły muszą prześwietlić logi, zawęzić scopes i zrotować sekrety.
  • Firmy powinny traktować integracje SaaS jak tożsamości uprzywilejowane i objąć je taką samą dyscypliną bezpieczeństwa jak konta adminów.

Źródła / bibliografia

  • BleepingComputer: oficjalne podsumowanie incydentu i wypowiedzi Salesforce + deklaracje ShinyHunters (20 listopada 2025). (Bleeping Computer)
  • Salesforce Status: komunikat o nietypowej aktywności, revokacji tokenów i czasowym usunięciu aplikacji Gainsight z AppExchange. (status.salesforce.com)
  • Reuters: potwierdzenie dochodzenia Salesforce ws. możliwej ekspozycji danych (21 listopada 2025). (Reuters)
  • TechCrunch: ujęcie techniczno-biznesowe i kontekst wcześniejszej kampanii Salesloft/Drift. (TechCrunch)
  • Gainsight – Security / Alerts: zakres danych z wcześniejszego incydentu i współpraca z Salesforce. (Gainsight Software)

GlobalProtect na celowniku: 2,3 mln prób dostępu do portali VPN Palo Alto w 5 dni

Wprowadzenie do problemu / definicja luki

W dniach 14–19 listopada 2025 r. odnotowano gwałtowny wzrost wrogiej aktywności wymierzonej w portale logowania Palo Alto Networks GlobalProtect. Według danych GreyNoise zarejestrowano 2,3 mln sesji trafiających w /global-protect/login.esp, co oznacza 40-krotny skok w 24 godziny i nowy szczyt z ostatnich 90 dni. Najwięcej ruchu pochodziło z AS200373 (3xK Tech GmbH), głównie geolokalizowanego w Niemczech (62%) i Kanadzie (15%), z dodatkowymi wkładami z AS208885. Celem były w szczególności USA, Meksyk i Pakistan.

O lawinowym wzroście skanów informował także serwis BleepingComputer, zestawiając najnowsze dane z wcześniejszymi pikami na tej samej powierzchni ataku.

W skrócie

  • Co się dzieje? Zautomatyzowane, masowe skanowanie i próby logowania do GlobalProtect na ścieżce /global-protect/login.esp.
  • Skala: ~2,3 mln sesji w 5 dni; 40× wzrost w 24h.
  • Infrastruktura źródłowa: dominacja AS200373, część ruchu z AS208885.
  • Ryzyko kontekstowe: w 2025 r. CVE-2025-0108 (PAN-OS) trafiło do katalogu CISA KEV jako wykorzystywane w atakach; bywało łączone z innymi błędami (np. CVE-2025-0111, CVE-2024-9474).

Kontekst / historia / powiązania

GreyNoise wcześniej raportował wzrosty skanów dotyczących GlobalProtect/PAN-OS (m.in. na początku października), wskazując, że piki rekonesansu często wyprzedzają ujawnienia nowych podatności w ekosystemie urządzeń sieciowych. Najnowszy skok z połowy listopada wpisuje się w tę sekwencję. Niezależne media branżowe odnotowały identyczne wnioski i parametry kampanii.

W lutym 2025 r. CISA dodała CVE-2025-0108 do katalogu znanych, wykorzystywanych podatności (KEV), a Palo Alto Networks potwierdziło aktywne nadużycia – co znacząco podnosi priorytet działań po stronie obrońców.

Analiza techniczna / szczegóły luki

  • Wejście atakującego: publiczny punkt /global-protect/login.esp – strona logowania GlobalProtect na firewallu Palo Alto (PAN-OS). To nie jest sama luka, ale powierzchnia ataku idealna do:
    • hurtowych prób uwierzytelnienia (credential stuffing/brute force),
    • zbierania sygnatur serwera (banery, JA4t/TLS), mapowania wersji i konfiguracji,
    • poszukiwania n-day/0-day w komponentach portalu.
  • Atrybucja infrastruktury: powtarzalne odciski TCP/JA4t, konsolidacja w AS200373 i AS208885, co sugeruje skoordynowaną kampanię jednego lub kilku powiązanych operatorów.
  • Powiązane CVE:
    • CVE-2025-0108 – obejście uwierzytelniania w PAN-OS (interfejs zarządzania); potwierdzone nadużycia & wpis w CISA KEV.
    • CVE-2025-0111authenticated file read w interfejsie zarządzania; często łączone w łańcuchach.

Uwaga: obecna fala skanów nie oznacza automatycznie wykorzystania nowej luki w login.esp, ale jest silnym wskaźnikiem wzmożonego rekonesansu pod kątem błędów i słabych haseł.

Praktyczne konsekwencje / ryzyko

  • Ryzyko natychmiastowe: przejęcie kont VPN metodami credential stuffing/spray, blokady kont, zakłócenia działania, zwiększony noise w SOC/SIEM.
  • Ryzyko pośrednie: przygotowanie gruntu pod eksploatację n-day/0-day w PAN-OS/GlobalProtect, zwłaszcza w środowiskach z ekspozycją interfejsu zarządzania lub nieaktualnymi poprawkami bezpieczeństwa (historycznie obserwowane korelacje).
  • Ryzyko strategiczne: pivot z VPN do sieci wewnętrznej, kradzież danych i ransomware po uzyskaniu dostępu. (Wniosek oparty na wzorcach kampanii wobec bram sieciowych w 2025 r.).

Rekomendacje operacyjne / co zrobić teraz

  1. Wymuś MFA odporną na phishing (FIDO2/WebAuthn) dla wszystkich dostępów VPN; wyłącz słabe formy 2FA (TOTP bez zabezpieczeń, SMS) tam, gdzie to możliwe. (Najbardziej efektywna kontra na stuffing/spray.)
  2. Geo/ASN filtering na brzegu: tymczasowo ogranicz loginy do oczekiwanych krajów/ASN; rozważ denylistę dla AS200373 i AS208885 (z zachowaniem wyjątków biznesowych).
  3. Rate-limiting i ochrona przed brute force na endpointzie /global-protect/login.esp (CAPTCHA po nieudanych próbach, progressive backoff, blokady IP).
  4. Monitoruj sygnatury JA4t/TLS wskazane przez GreyNoise w regułach NIDS/SIEM; koreluj z logami failed-auth.
  5. Aktualizacje PAN-OS / GlobalProtect: upewnij się, że środowisko ma załataną CVE-2025-0108 i pokrewne błędy – status znajduje się w advisory Palo Alto i w katalogu CISA KEV.
  6. Ogranicz ekspozycję paneli: nie wystawiaj interfejsu zarządzania PAN-OS do Internetu; jeśli to konieczne – IP allowlist/VPN administracyjny, cert-based auth. (Dobra praktyka rekomendowana przez dostawcę/branżę.)
  7. Higiena haseł i polityki kont: wymuś rotację haseł po wykryciu anomalii, włącz ochronę przed reuse, sprawdzaj przeciw bazom wycieków (np. HIBP).
  8. Dzienniki i telemetria: zbieraj i alertuj na anomalię failed-auth burst/login from new ASN/country, korelacja z WAF/NGFW.

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

  • Doświadczenia z 2025 r.: podobne skoki rekonesansu bywały prekursorem ujawnień/eksploatacji błędów w bramach sieciowych (np. wcześniejsze fale na GlobalProtect, a także głośne kampanie wobec urządzeń innych producentów). Choć wektor i vendor się różnią, wspólny mianownik to: ekspozycja usług webowych, masowe skanowanie, szybkie łańcuchowanie CVE oraz próby ukrycia śladów przez atakujących.

Podsumowanie / kluczowe wnioski

  • Obserwowany 40× wzrost i 2,3 mln sesji na /global-protect/login.esp to istotny sygnał ryzyka – nawet jeśli nie wskazuje na nowy 0-day, to potwierdza ukierunkowany rekonesans i presję na kradzież poświadczeń.
  • Organizacje korzystające z GlobalProtect powinny już teraz zaostrzyć kontrolę dostępu (MFA odporna na phishing, filtrowanie geo/ASN, rate-limits), zaktualizować PAN-OS (zwłaszcza pod kątem CVE-2025-0108 i powiązań) oraz wzmocnić monitoring.

Źródła / bibliografia

  1. GreyNoise: Palo Alto Scanning Surges 40X in 24 Hours, Marking 90-Day High (19 listopada 2025). (greynoise.io)
  2. BleepingComputer: GlobalProtect VPN portals probed with 2.3 million scan sessions (20 listopada 2025). (Bleeping Computer)
  3. Palo Alto Networks – Advisory CVE-2025-0108 (12 lutego 2025). (security.paloaltonetworks.com)
  4. CISA: Adds Two Known Exploited Vulnerabilities to Catalog – wpis dot. CVE-2025-0108 (18 lutego 2025). (CISA)
  5. The Register: Palo Alto kit sees massive surge in malicious activity (20 listopada 2025). (The Register)

Sneaky2FA dodaje Browser-in-the-Browser (BitB). Nowa przynęta dla kradzieży sesji Microsoft 365

Wprowadzenie do problemu / definicja luki

Phishing-as-a-Service (PhaaS) Sneaky2FA dorzucił do swojego arsenału technikę Browser-in-the-Browser (BitB) – fałszywe „okno przeglądarki w przeglądarce”, które imituje pop-up logowania Microsoft i maskuje podejrzany URL. W efekcie ofiary podają hasła oraz potwierdzają MFA w kontrolowanym przez napastnika oknie, a zestaw przechwytuje zarówno poświadczenia, jak i aktywne ciasteczka sesyjne (AiTM). To znacznie podnosi skuteczność przejęć kont Microsoft 365.

Technika BitB została szczegółowo opisana przez badacza mr.d0x w 2022 r. – to sprytna kombinacja HTML/CSS/JS budująca wiarygodny, ruchomy pop-up z paskiem adresu udającym domenę docelową (np. login.live.com), choć strona ładuje się z innego źródła.


W skrócie

  • Co nowego? Sneaky2FA renderuje fałszywe okno logowania (BitB) i w jego wnętrzu ładuje swoją stronę AiTM, co łączy „realistykę” z pełnym przechwytem sesji.
  • Kogo celuje? Głównie Microsoft 365/Entra ID (OAuth/SSO).
  • Jak zwodzi? Bot-check (Cloudflare Turnstile), warunkowe ładowanie/geofencing, ciężka obfuskacja HTML/JS, rotacja domen i ścieżek (często długie, losowe path).
  • Skutki: kradzież ciasteczek sesyjnych → ominięcie 2FA → BEC/escalation.

Kontekst / historia / powiązania

Sneaky2FA został nagłośniony na początku 2025 r. przez Sekoia TDR jako świeży zestaw AiTM/PhaaS sprzedawany via bot Telegram, z charakterystycznymi wzorcami URL i nietypowym profilem User-Agent podczas negocjacji z API Microsoftu („niemożliwa zmiana urządzenia”). Sekoia wskazała też pokrewieństwa kodowe do W3LL OV6. W telemetrii z Q1 2025 Sneaky2FA był wśród najpopularniejszych AiTM-kitów obok Tycoon2FA i EvilProxy.

W listopadzie 2025 r. Push Security odnotowało nową odmianę Sneaky2FA z BitB, a media branżowe (m.in. BleepingComputer) potwierdziły obserwacje. Równolegle, inne PhaaS (np. Raccoon0365) też eksperymentują z BitB.


Analiza techniczna / szczegóły luki

Łańcuch ataku Sneaky2FA z BitB (obserwacje Push Security):

  1. Ofiara trafia na domenę przynęty (np. previewdoc[.]us) i przechodzi Cloudflare Turnstile.
  2. Strona stylizowana na podgląd PDF/Adobe zachęca do „Sign in with Microsoft”.
  3. Po kliknięciu renderowane jest okno BitB – pasek adresu i ramka imitują Edge/Windows lub Safari/macOS (dopasowanie do platformy ofiary).
  4. Wewnątrz okna ładuje się realny przepływ logowania Microsoft, ale przez reverse-proxy/Sneaky AiTM, który podkrada hasło + token sesyjny.
  5. Po sukcesie następuje redirect do prawdziwego zasobu, by ukryć ślady.

Techniki uniku i utrudniania analizy:

  • Obfuskacja HTML/JS (dzielenie tekstu na fragmenty z niewidocznymi tagami, elementy interfejsu jako obrazy/BASE64, anty-fingerprinting kodu).
  • Warunkowe ładowanie: niepożądany ruch (VPNy, adresy vendorów) → przekierowanie na nieszkodliwe strony (np. Wikibooks).
  • Bot-protection przed crawlerami (Turnstile/CAPTCHA).
  • Rotacja domen/ścieżek: krótkie życie kampanii, bardzo długie ścieżki (≈150 znaków).

Wskaźniki i heurystyki detekcji (Sekoia):

  • „Impossible device shift” w logach Entra ID: kolejne kroki logowania z odmiennymi UA (np. iOS Safari → Windows Edge w jednej sesji).
  • Wzorce URL generowane przez kit (/index, /verify, /validate po długiej ścieżce), autograb e-maila w parametrze URL.
  • Infrastruktura i licencjonowanie via Telegram bot („Sneaky Log”).

Czym BitB różni się od typowego AiTM?
BitB to warstwa „kosmetyczna” – sprawia, że phishing wygląda jak natywny pop-up SSO (z rzekomo „dobrym” adresem), przez co „sprawdź URL” traci sens. W Sneaky2FA BitB nakłada się na klasyczny przepływ AiTM odpowiedzialny za kradzież sesji.


Praktyczne konsekwencje / ryzyko

  • Przejęcia kont M365 mimo włączonego 2FA (kradzież ciastek sesyjnych) → BEC, wycieki danych, ruch boczny w M365/SharePoint/Teams, utrata reputacji i realne straty finansowe.
  • Podwyższona „skuteczność socjotechniczna”: pop-up wygląda jak natywny dla przeglądarki/OS ofiary.
  • Utrudniona analiza i blokowanie domen przez rotację/warunkowe ładowanie.

Rekomendacje operacyjne / co zrobić teraz

Prewencja (to-do dla SecOps/IT):

  1. Wymuś phishing-resistant MFA (FIDO2/WebAuthn) dla kont uprzywilejowanych i wrażliwych ról; ogranicz SMS/OTP. (Kontekst: AiTM/BitB atakują sesję).
  2. SSO/MFA policy hardening: step-up dla ryzykownych sygnałów, blokada starszych metod (legacy), wymuszenie device compliance.
  3. Zasady przeglądarkowe: blokady iFrame’ów/okien z nieznanych domen w krytycznych aplikacjach (CSP, X-Frame-Options), izolacja przeglądarkowa dla dostępu do SaaS krytycznego.
  4. Edukacja, ale konkret: „przeciągnij pop-up” – prawdziwe okno da się wysunąć poza ramy głównej przeglądarki i pojawia się w pasku zadań; BitB – nie. (Uwaga: to tylko szybki test heurystyczny, nie gwarancja).

Detekcja i reagowanie (Blue Team):

  1. Korelacja anomalii UA/klientów w jednym przepływie logowania („impossible device shift”). Wdrożenie reguł Sigma/UEBA dla Entra ID (przykłady z publikacji Sekoia).
  2. Hunting domen kampanii: długie, losowe ścieżki, motywy lure (podgląd dokumentu/Adobe), CAPTCH-e przed właściwą stroną, domeny w stylu previewdoc[.]*.
  3. Telemetria przeglądarkowa/EDR: wykrywanie osadzonych „okien” z atrybutami nietypowymi dla natywnego pop-upa; alerty na Cloudflare Turnstile → Microsoft login w krótkiej sekwencji.
  4. Playbook IR: natychmiastowe unieważnienie sesji (Revoke refresh tokens), wymuszenie key rotation, przegląd reguł skrzynek (forwardy, reguły ukrywania), MFA re-enrollment i risk-based sign-out.

Twardnienie M365/Entra:

  • Włącz Continuous Access Evaluation, Sign-in risk policies, Token protection (jeśli dostępne), ogranicz Auth Session Lifetime; monitoruj Consent Grants i aplikacje typu OAuth z nadmiernymi uprawnieniami.

Różnice / porównania z innymi przypadkami

  • Tycoon2FA/Mamba2FA – klasyczne AiTM (proxy/relay) bez akcentu na BitB; skuteczne, ale mniej „wizualnie” przekonujące niż BitB. Sneaky2FA łączy AiTM + „makijaż” BitB.
  • Raccoon0365 – również eksperymentuje z BitB (zapowiedzi „BITB mini-panel”), co sugeruje trend w PhaaS.

Podsumowanie / kluczowe wnioski

Sneaky2FA podniósł poprzeczkę: BitB zwiększa wiarygodność phishingu, a warstwa AiTM nadal zapewnia kradzież sesji i ominięcie MFA. Organizacje muszą traktować „sprawdzaj URL” jako niewystarczające – potrzebne są phishing-resistant MFA, polityki kontekstowe, korelacja logów (UA/anomalia), szybszy IR po incydencie i ochrona tożsamości w przeglądarce.


Źródła / bibliografia

  1. BleepingComputer – Sneaky2FA PhaaS kit now uses redteamers’ Browser-in-the-Browser attack (19 listopada 2025). (BleepingComputer)
  2. Push Security – Analyzing the latest Sneaky2FA Browser-in-the-Browser phishing page (18 listopada 2025). (Push Security)
  3. Sekoia – Sneaky 2FA: exposing a new AiTM Phishing-as-a-Service (16 stycznia 2025). (Sekoia.io Blog)
  4. Sekoia – Global analysis of Adversary-in-the-Middle phishing threats (11 czerwca 2025). (Sekoia.io Blog)
  5. mr.d0x – Browser In The Browser (BITB) Attack (15 marca 2022). (mrd0x.com)

WhatsApp: luka enumeracyjna umożliwiła „spis powszechny” 3,5 mld kont. Co naprawdę wyciekło i jak się bronić?

Wprowadzenie do problemu / definicja luki

Zespół badaczy z Uniwersytetu Wiedeńskiego i SBA Research ujawnił krytyczną słabość mechanizmu „odkrywania kontaktów” w WhatsApp. Funkcja, która ma ułatwiać znalezienie znajomych po numerze telefonu, pozwalała na hurtową enumerację: automatyczne sprawdzanie, czy numer jest zarejestrowany oraz pobieranie publicznych elementów profilu (nazwy, zdjęcia, opisu „O mnie”, kluczy publicznych). W efekcie badacze potwierdzili 3,5 miliarda aktywnych kont i zebrali powiązane metadane. Meta (właściciel WhatsAppa) wdrożyła środki ograniczające po zgłoszeniu, a badacze potwierdzili, że obecnie metoda jest blokowana.

W skrócie

  • Skala: potwierdzono 3,5 mld numerów WhatsApp; tempo pozyskiwania danych sięgało ~100 mln wpisów/h, bez skutecznego rate limitu. 57% profili miało publiczne zdjęcia, ~29% — publiczny opis.
  • Wejście: wystarczył generator numerów i zapytania do mechanizmu wykrywania kontaktów (m.in. w oparciu o libphonenumber).
  • Status: Meta wdrożyła „nowe zabezpieczenia anty-scrapingowe”; badacze mówią, że dziś ich metoda jest blokowana.
  • Ryzyka: spam/robocalls, phishing ukierunkowany, deanonymizacja (powiązania zdjęć/tekstów profilu), ryzyko dla użytkowników w krajach, gdzie WhatsApp jest zakazany.

Kontekst / historia / powiązania

Badanie to kolejny etap prac zespołu nad prywatnością komunikatorów E2EE. Akademicki komunikat Uniwersytetu Wiedeńskiego wskazuje na odpowiedzialne ujawnienie i współpracę z Meta; luka została „zmitigowana”. Jednocześnie relacje prasowe podkreślają, że pełna reakcja po stronie WhatsAppa zajęła wiele miesięcy od pierwszych zgłoszeń.

Analiza techniczna / szczegóły luki

  • Wektor: API/flow „Contact Discovery” zdradzało binarnie, czy numer istnieje w WhatsApp. Zautomatyzowane zapytania na listach kolejnych numerów (generowanych np. z wykorzystaniem bibliotek numeracji telefonicznej) pozwalały na masowe potwierdzanie kont.
  • Pobierane dane: dla kont z domyślnie publicznymi elementami — nazwa, zdjęcie profilowe, tekst statusu/„O mnie”, a także klucze publiczne używane w E2EE (co nie daje dostępu do treści, ale ma implikacje operacyjne).
  • Wydajność ataku: badacze raportują ~7000 numerów/s na sesję, brak realnych blokad po stronie serwisu i możliwość potwierdzenia 3,5 mld numerów po sprawdzeniu ~63 mld wygenerowanych pozycji.
  • Ciekawostki kryptograficzne: w zebranym zbiorze odnotowano powtórzenia kluczy publicznych u części kont (prawdopodobnie efekt nieoficjalnych klientów/automatyzacji, a nie błąd protokołu WhatsAppa). Nie oznacza to złamania E2EE, ale może wskazywać na słabe implementacje po stronie nieautoryzowanych aplikacji.
  • Kontratak i obecny stan: WhatsApp wdrożył nowe mechanizmy anty-scrapingowe i rate-limiting; ponowne testy badaczy po publikacji miały zostać szybko zablokowane.

Praktyczne konsekwencje / ryzyko

  1. Zwiększona skuteczność oszustw: kompletne słowniki aktywnych numerów ułatwiają smishing, spam VOIP/robocalls i podszywanie się na WhatsApp (np. ataki „na dziecko/na szefa”). Publiczne zdjęcia i statusy pomagają w personalizacji socjotechniki.
  2. Ryzyko dla osób wysokiego ryzyka: możliwa deanonimizacja (np. po zdjęciach i opisach), a także identyfikacja użytkowników w krajach z banem na WhatsApp — potencjalne konsekwencje prawne lub represje.
  3. Mapowanie infrastruktury przestępczej (perspektywa obrony): klucze i wzorce powtarzalności mogą pomagać wykrywać farmy kont oraz klientów nieoficjalnych używanych przez scammerów.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników (od ręki)

  • Ustawienia prywatności → Zdjęcie profilowe, Informacje, Ostatnio widziano: ustaw „Tylko kontakty” lub „Nikt”. Rozważ neutralne zdjęcie/bez twarzy. (Zmniejsza ekspozycję przy ewentualnych kolejnych słabościach enumeracyjnych).
  • Weryfikacja dwuetapowa (PIN) w WhatsApp oraz blokada karty SIM (PIN SIM) — ogranicza skutki przejęć numeru.
  • Czujność na smishing: nie klikaj linków w niespodziewanych wiadomościach, weryfikuj przelewy poza komunikatorem.

Dla zespołów bezpieczeństwa (organizacje)

  • Reguły detekcji: monitoruj kampanie smishingowe kierowane do firmowych numerów/WhatsApp Business; koreluj z masowymi próbami na innych kanałach.
  • Polityka komunikacji: nie używaj WhatsApp do wrażliwych ustaleń biznesowych; jeśli już, wymuś minimalną ekspozycję profilu i edukuj pracowników.
  • Ochrona VIP/eksponowanych ról: przegląd ustawień prywatności, rotacja zdjęć, „higiena” statusów (bez informacji o podróżach, stanowisku itp.).
  • Filtry po stronie operatorów/UCaaS: wdrażaj filtry anty-robocall, numery „pułapki” i sinkhole do wczesnego wykrywania kampanii.

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

  • „Scraping” vs klasyczny wyciek: to nie włamanie do bazy danych, lecz masowe odczytanie publicznie dostępnych elementów przez funkcję kontakt-discovery, w połączeniu z brakiem skutecznego rate-limitingu. Konsekwencje mogą być porównywalne do wycieków, bo tworzą „książkę telefoniczną świata” z kontekstem (zdjęcia/teksty).
  • Powiązanie z „wielkim skrobaniem Facebooka 2021”: badacze wskazują, że znaczna część numerów z tamtego zbioru pozostaje aktywna — to podnosi wartość kombinacji starych i nowych danych dla przestępców.

Podsumowanie / kluczowe wnioski

  • Mechanizm „odkrywania kontaktów” w usługach opartych na numerach telefonu z natury sprzyja enumeracji.
  • Nawet jeśli Meta załatała wektor i dziś blokuje scraping, ryzyko resztkowe pozostaje — dane mogły być już pozyskane, a sam model identyfikacji po numerze jest trudny do pełnego zabezpieczenia.
  • Minimalizuj ekspozycję profilu i przygotuj organizację na wzmożone kampanie socjotechniczne oparte na numerach WhatsApp.

Źródła / bibliografia

  1. University of Vienna – komunikat prasowy o luce i mitigacji. (Universität Wien)
  2. SBA Research – notatka o badaniu i potwierdzeniu wdrożonych zabezpieczeń. (sba-research.org)
  3. WIRED – artykuł z technicznymi szczegółami (tempo enumeracji, statystyki profili, powtórzenia kluczy) oraz stanowiskiem WhatsApp. (WIRED)
  4. The Register – relacja z komentarzami badaczy i inżyniera WhatsApp (stan po wdrożeniu środków anty-scrapingowych). (The Register)
  5. Repozytorium GitHub projektu whatsapp-census (opis i materiały badania). (GitHub)

CVE-2015-3113 — Adobe Flash Player RCE

TL;DR

Krytyczna luka w Adobe Flash Player (CVE‑2015‑3113) umożliwiała zdalne wykonanie kodu poprzez przepełnienie bufora na stercie, m.in. po wejściu na złośliwą stronę lub kliknięciu odsyłacza w kampanii phishingowej. Zero‑day wykorzystywany był w operacji Clandestine Wolf (APT3), z łańcuchem: e‑mail → profilowanie JS → załadowanie pliku SWF/FLV → ROP/DEP/ASLR bypass → zrzut backdoora (SHOTPUT). Detekcja: obserwuj pobrania .swf, procesy/załadowane moduły Flash oraz nietypowe dzieci procesów Flash (cmd/powershell/wscript). Ponieważ Flash jest EOL (12.2020), każde użycie Flash w 2025 r. jest co najmniej podejrzane.


Krótka definicja techniczna

CVE‑2015‑3113 to luka typu heap‑based buffer overflow w Adobe Flash Player (przed 13.0.0.296; 14.x–18.x < 18.0.0.194 dla Windows/OS X; Linux < 11.2.202.468), pozwalająca zdalnie wykonać kod przy przetwarzaniu specjalnie spreparowanych treści Flash; w czerwcu 2015 była aktywnie wykorzystywana na wolności.


Gdzie występuje / przykłady platform

  • Endpointy: Windows (IE/Edge Legacy/Chrome/Firefox), macOS (Safari/Firefox/Chrome), Linux (Firefox/Chromium – PPAPI/NPAPI).
  • Scenariusze ataku: phishing z linkiem do serwisu z exploitem, drive‑by po wejściu na zainfekowaną stronę; znane cele zawierały m.in. Windows 7 (IE) i Firefox na XP.
  • Stan dzisiaj: Flash Player zakończył życie 31.12.2020 (blokada uruchomienia od 12.01.2021) — użycie w sieci produkcyjnej to incydent ryzyka.

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

Kampania Operation Clandestine Wolf przypisywana APT3 wykorzystywała e‑maile z odsyłaczami do przejętych witryn. Po kliknięciu ofiara była przekierowywana do skryptów profilujących (JS), które sprawdzały wersje przeglądarki/wtyczek. Następnie serwer dostarczał parę plików SWF + FLV wykorzystujących CVE‑2015‑3113. Exploit uzyskiwał arbitralny zapis/odczyt, wykonywał łańcuch ROP omijający DEP/ASLR, a finalnie odpalał shellcode i zrzucał backdoora SHOTPUT. Efekt: zdalne RCE i trwała kontrola hosta.

Dlaczego skuteczna?
(1) popularność Flash w 2015, (2) atak drive‑by nie wymagał pobierania plików przez użytkownika, (3) łańcuch exploitów obchodził mechanizmy łagodzące (DEP/ASLR), (4) szybka adopcja w ekosystemie exploit kitów (np. Magnitude).


Artefakty i logi

WarstwaArtefakt / źródłoWskaźniki / polaUwagi
Windows (Sysmon)EID 1 Process CreateImage/ParentImage: FlashPlayer.exe, FlashUtil*.exe, FlashPlayerPlugin*.exe; dzieci: cmd.exe, powershell.exe, wscript.exe, rundll32.exe, regsvr32.exeNietypowe dziecko procesu Flash = silny sygnał RCE. Nazwy procesów potwierdza Adobe Flash Player Admin Guide.
Windows (Sysmon)EID 7 Image LoadedImageLoaded = \pepflashplayer.dll (Chrome/Chromium)Obserwuj załadowanie w procesach przeglądarki.
Windows (Application)EID 1000 Application ErrorAwaria modułów Flash/pepflashNagłe crashe Flash niedługo przed nietypowym procesem‑dzieckiem.
Proxy/NGFW/DNSDostęp HTTP/S do *.swf, MIME application/x-shockwave-flashurl, mime, user_agent, referrerKoreluj z kliknięciami z e‑maila (M365).
M365 DefenderEmailUrlInfo, UrlClickEventsUrl, UrlDomain, kliknięcia Safe LinksŁącz URL .swf z hostami, które uruchomiły procesy Flash.
MITRE ATT&CK (kontekst)APT3 + SHOTPUTProfilowanie, dostarczenie backdooraDo korelacji z TTP grupy.
AWS (opcjonalnie)CloudTrail Lake (S3 Data Events)GetObject na kluczach %.swfWymaga włączonych data events.
CDNCloudFront Access Logs / Athenacs-uri-stem like '%.swf', sc-content-typePrzy hostowaniu/pośrednictwie treści.

Detekcja (praktyczne reguły)

Sigma (Windows / Sysmon – anomalie dzieci procesów Flash)

title: Flash Plugin Spawns Suspicious Child (CVE-2015-3113 Context)
id: 5a8b2f3b-8ce3-49d0-9f1f-6a2e1d1f3f31
status: experimental
description: Wykrywa nietypowe dzieci procesów Flash (cmd/powershell/skrpty), co bywa obserwowane przy RCE (np. CVE-2015-3113).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2015-3113
  - https://cloud.google.com/blog/topics/threat-intelligence/operation-clandestine-wolf-adobe-flash-zero-day/
tags:
  - attack.t1203
  - attack.t1189
  - attack.t1566.002
  - cve.2015-3113
logsource:
  category: process_creation
  product: windows
detection:
  sel_parent:
    ParentImage|contains:
      - '\FlashPlayer'
      - '\FlashUtil'
      - '\FlashPlayerPlugin'
  sel_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: sel_parent and sel_child
fields:
  - ParentImage
  - ParentCommandLine
  - Image
  - CommandLine
falsepositives:
  - Rzadkie narzędzia korporacyjne wołane z aplikacji opartej na Flash (dziś skrajnie rzadkie)
level: high

Splunk (SPL)

1) Flash uruchomiony przez przeglądarkę

index=sysmon EventCode=1
(ParentImage="*\\iexplore.exe" OR ParentImage="*\\chrome.exe" OR ParentImage="*\\firefox.exe" OR ParentImage="*\\msedge.exe")
(Image="*\\FlashPlayer*.exe" OR Image="*\\FlashUtil*.exe" OR Image="*\\FlashPlayerPlugin*.exe")
| stats count min(_time) max(_time) by host, ParentImage, Image, CommandLine, ParentCommandLine

2) Dzieci procesów Flash

index=sysmon EventCode=1
(ParentImage="*\\FlashPlayer*.exe" OR ParentImage="*\\FlashUtil*.exe" OR ParentImage="*\\FlashPlayerPlugin*.exe")
(Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\wscript.exe" OR Image="*\\rundll32.exe" OR Image="*\\regsvr32.exe")
| table _time host ParentImage Image CommandLine

3) Proxy/HTTP — pobrania .swf

index=proxy (uri_path="*.swf" OR mime_type="application/x-shockwave-flash")
| stats count by src_ip, user, uri, http_status, user_agent, referrer

KQL (Microsoft Defender / M365)

Defender for Endpoint — dzieci procesów Flash

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("FlashPlayer.exe","FlashPlayerPlugin.exe","FlashUtil32.exe","FlashUtil64.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine

MDO — kliknięcia linków .swf

UrlClickEvents
| where Url endswith ".swf" or Url has ".swf?"
| summarize Clicks=count() by UrlDomain, Url, AccountUpn, Timestamp

MDO — adresy URL w wiadomościach

EmailUrlInfo
| where Url endswith ".swf" or Url has ".swf?"
| join kind=leftouter EmailEvents on NetworkMessageId
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Url, UrlDomain, Subject, ThreatTypes

(Definicje tabel: EmailUrlInfo, UrlClickEvents — dokumentacja Microsoft).

CloudTrail / CloudWatch (AWS)

Założenie: włączone S3 Data Events lub logi CloudFront.

CloudTrail Lake SQL (AWS CLI): wyszukaj pobrania *.swf z bucketów

SELECT eventTime, sourceIPAddress, userIdentity.principalId, requestParameters.bucketName AS bucket,
       requestParameters.key AS objectKey
FROM event_data_store
WHERE eventSource = 's3.amazonaws.com'
  AND eventName   = 'GetObject'
  AND requestParameters.key LIKE '%.swf'
  AND eventTime > TIMESTAMP '2025-11-01 00:00:00';

(Wymaga włączonych data events).

CloudFront / Athena (przykład):

SELECT date, time, cs_host, cs_uri_stem, sc_status, sc_content_type, c_ip, cs_user_agent
FROM cloudfront_logs
WHERE cs_uri_stem LIKE '%.swf'
ORDER BY date, time DESC;

Elastic EQL

process where
  process.parent.name in ("FlashPlayer.exe","FlashPlayerPlugin.exe","FlashUtil32.exe","FlashUtil64.exe") and
  process.name in ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","rundll32.exe","regsvr32.exe")

Heurystyki / korelacje

  • Klik .swf ⇒ proces Flash ⇒ podejrzane dziecko ⇒ połączenie wychodzące (czasowo blisko) — korelacja M365 (UrlClickEvents / EmailUrlInfo) + EDR + egress DNS/HTTP.
  • Załadowanie pepflashplayer.dll przez przeglądarkę, następnie nietypowe zachowanie (np. nagłe powershell.exe).
  • Rzadko używane dziś MIME application/x-shockwave-flash w ruchu web — traktuj jako anomalię.
  • Artefakty APT3/SHOTPUT (nietypowe rozpoznanie hosta/użytkowników/sieci po kompromitacji) jako sygnały post‑exploitation do korelacji (np. lista kont, netstat).

False positives / tuning

  • Dziedzictwo wewnętrzne: pojedyncze kioski/offline‑aplikacje z zawartością SWF (dziś wyjątkowe). Użyj allowlist domen/aplikacji biznesowych i ogranicz reguły do organizacji/OU, gdzie jakiekolwiek Flash jest dopuszczone.
  • Narzędzia administracyjne mogą incydentalnie wywołać interpretery (np. skrypty logowania), ale rodzicem nie powinien być proces Flash.
  • Ustal okno czasowe (np. ±5 min od kliknięcia URL .swf) i filtruj znane testy w labie.

Playbook reagowania (SOC/IR)

  1. Zablokuj źródło: domenę/URL z .swf w proxy/DNS firewall; wypchnij blokadę przez EDR.
  2. Izoluj host z alertem (EDR quarantine).
  3. Triage artefaktów:
    • Procesy potomne Flash, dropy w %APPDATA%, połączenia C2.
    • Zrzut pamięci procesu przeglądarki/Flash (jeśli polityka na to pozwala).
  4. Hunting rozprzestrzenienie: użyj zapytań (SPL/KQL/EQL powyżej) w horyzoncie 7–30 dni.
  5. Patch & harden: potwierdź brak Flash w flocie (wycofanie EOL), wymuś aktualizacje przeglądarek.
  6. Eradykacja: usuń artefakty, przeinstaluj przeglądarkę, unieważnij poświadczenia pozyskane po kompromitacji.
  7. Lessons learned: blokada typów/MIME, EDR policy na podejrzane dzieci procesów, kampania edukacyjna „nie klikaj .swf”.

Przykłady z kampanii / case studies

  • Operation Clandestine Wolf (APT3/UPS) — phishing z odsyłaczami do przejętych witryn; profilowanie JS; exploit CVE‑2015‑3113; backdoor SHOTPUT (Backdoor.APT.CookieCutter). Branże: A&D, telco, high‑tech, transport, budownictwo.
  • Eksploatacja na szeroką skalę — szybka adopcja w exploit kitach (np. Magnitude) w 2015 r.

Lab (bezpieczne testy) — tylko w kontrolowanym środowisku

Nie instaluj Flash w produkcji. Nie testujemy exploitu — jedynie łańcuch detekcji.

  • Symulacja ruchu web
    • curl -I https://lab.example.org/test.swf (serwuj neutralny plik binarny z nagłówkiem Content-Type: application/x-shockwave-flash).
    • Zweryfikuj, że proxy/NGFW/Athena (CloudFront) odnotowały żądanie *.swf.
  • Symulacja korelacji M365
    • Wyślij na skrzynkę testową e‑mail z linkiem do https://lab.example.org/test.swf.
    • Sprawdź EmailUrlInfo / UrlClickEvents (KQL z sekcji 7).
  • Symulacja anomalii procesów
    • Zastępczo uruchom aplikację, która imituje wzorzec: proces „AplikacjaGUI.exe” → cmd.exe /c whoami. Reguły powinny złapać schemat „aplikacja multimedialna → interpreter”. (Bez użycia Flash).

Mapowania

Mitigations (ATT&CK):

  • M1050 Exploit Protection — ASR/Exploit Guard/EDR exploit prevention.
  • M1033 Limit Software Installation — blokada instalacji wtyczek/dodatków; usunięcie Flash.
  • M1040 Behavior Prevention on Endpoint — blokuj podejrzane łańcuchy (Flash → skrypty/LOLBins).
  • M1017 User Training — prewencja kliknięć w odsyłacze .swf.

Powiązane techniki (kaskada):

  • T1105 Ingress Tool Transfer — dociąganie backdoora po RCE.
  • T1027 Obfuscated/Compressed Files & Information — xor/steganografia/packery w payloadach.

Źródła / dalsza literatura

  • NVD: opis, wersje, „exploited in the wild” (VI 2015). (NVD)
  • Mandiant/FireEye: Operation Clandestine Wolf, łańcuch ataku, SHOTPUT (APT3). (Google Cloud)
  • SecurityWeek: zero‑day, cele (IE na Win7, Firefox na XP), powiązanie z APT3. (SecurityWeek)
  • Trend Micro: adopcja w exploit kitach (Magnitude). (www.trendmicro.com)
  • Adobe: EOL Flash (31.12.2020). (Adobe)
  • Adobe Flash Player 32 Admin Guide: procesy/plik DLL (FlashUtil*, pepflashplayer.dll). (open-flash.github.io)
  • MITRE ATT&CK: T1189, T1566.002, T1203; wersja v18.0. (MITRE ATT&CK)
  • Microsoft Defender: tabele EmailUrlInfo, UrlClickEvents. (Microsoft Learn)
  • AWS: CloudTrail Data Events, CloudFront/Athena zapytania. (AWS Documentation)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Włączone telemetry: Sysmon (EID 1/7), proxy/DNS, M365 Defender (EmailUrlInfo/UrlClickEvents).
  • Reguły: Sigma (Flash → cmd/powershell), SPL/KQL/EQL z sekcji 7.
  • Korelacja: klik .swf ↔ procesy Flash ↔ dziecko/egress DNS/HTTP.
  • Blokady: MIME application/x-shockwave-flash, rozszerzenie .swf w bramkach.
  • Hunting retro 30 dni: dzieci procesów Flash i ruch do domen z kampanii (wg TI).

CISO (strategiczne):

  • Potwierdzić brak Flash w organizacji (EOL).
  • Polityka „deny by default” dla wtyczek przeglądarek.
  • Wymuszony Exploit Protection/EDR (M1050/M1040).
  • Szkolenia użytkowników (M1017) z naciskiem na klikalność linków.
  • Gotowość IR: playbook powyżej, retencja logów ≥ 30–90 dni.

CVE-2015-2545 — złośliwy EPS w dokumentach Microsoft Office

TL;DR

CVE‑2015‑2545 to krytyczna podatność RCE w parserze EPS pakietu Microsoft Office, umożliwiająca wykonanie kodu po otwarciu dokumentu z osadzonym plikiem EPS. Była szeroko wykorzystywana w kampaniach APT (m.in. PLATINUM, APT16). Dziś kluczowe jest: pełne łatanie (MS15‑099), blokada EPS w Office (domyślnie wyłączone od 2017 r.), filtrowanie w bramkach pocztowych oraz detekcje „Office → nietypowe dziecko” i (na starszych hostach) ładowanie EPSIMP32.FLT.


Krótka definicja techniczna

CVE‑2015‑2545 to błąd w obsłudze grafiki Encapsulated PostScript (EPS) w Office, który po otwarciu dokumentu z wbudowanym EPS pozwala napastnikowi doprowadzić do korupcji pamięci i zdalnie wykonać kod w kontekście użytkownika. Exploit wykorzystuje kod PostScript, a historycznie potrafił omijać ASLR/DEP.


Gdzie występuje / przykłady platform

  • Windows / Office: Office 2007 SP3, 2010 SP2, 2013 SP1, 2013 RT SP1 (późniejsze Office miały zablokowaną obsługę EPS).
  • M365 (Exchange/Defender): wektor pocztowy (załączniki DOC/DOCX/RTF z EPS); telemetria EmailEvents, EmailAttachmentInfo, DeviceProcessEvents.
  • Pozostałe platformy (AD, AWS, Azure, GCP, K8s, ESXi, M365): wpływ pośredni (np. phishing do skrzynek M365; hosty Windows). CloudTrail/K8s/ESXi zazwyczaj nie dotyczy samej eksploatacji, ale można korelować pobrania plików z S3 (jeśli dokument był hostowany w chmurze).

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

Atakujący wysyła do ofiary dokument Office (DOC/DOCX/RTF) z osadzonym EPS. Po otwarciu dokumentu silnik importu grafiki (EPSIMP32.FLT) parsuje treść EPS, co przy specjalnie spreparowanych danych prowadzi do RCE. W praktyce łańcuch wyglądał następująco:

  1. Initial Access: spearphishing z załącznikiem zawierającym EPS (T1566.001).
  2. Execution: użytkownik otwiera plik (T1204.002), Office ładuje filtr EPS i wyzwala błąd → shellcode.
  3. Post‑exploitation: uruchomienie procesu lolbin (np. rundll32.exe, regsvr32.exe, mshta.exe) lub droppera.

Eksploatacja była popularna, bo łączyła socjotechnikę z błędem klienta (Office), a ochrona oparta wyłącznie na AV bywała nieskuteczna. Microsoft wydał poprawki w MS15‑099 (09.2015; 11.2015 re-release), a w 04.2017 domyślnie wyłączył EPS w Office (trwale od 05.2018 w M365/Office 2019+).


Artefakty i logi (co zbierać)

ŹródłoPole / EIDCo szukaćUwagi
Windows Security4688 (Process Creation)WINWORD.EXE / EXCEL.EXE / POWERPNT.EXE / OUTLOOK.EXE → dziecko: cmd.exe, powershell.exe, wscript.exe, cscript.exe, mshta.exe, regsvr32.exe, rundll32.exe, schtasks.exe, certutil.exeSilny wskaźnik post‑exploitation
Sysmon1 (Process Create)Jak wyżej + CommandLine z nietypowymi parametramiKorelować z 7 i 11
Sysmon7 (ImageLoad)ImageLoaded kończy się na \EPSIMP32.FLT ładowane przez OfficeMa sens wyłącznie na starych, niezałatanych hostach/wersjach Office (EPS włączony)
Sysmon11 (FileCreate) / 15 (FileStreamCreated)Zapisy Office do %TEMP% i strumieni z URL/UNC; wkrótce spawn lolbinDobrze korelować w oknie 0–5 min
M365 DefenderDeviceProcessEventsInitiatingProcessFileName ∈ {WINWORD, EXCEL, POWERPNT, OUTLOOK} → child z listy lolbinówT1204.002 / T1203
M365 DefenderEmailEvents, EmailAttachmentInfoZałączniki .doc/.docx/.rtf z nietypowych nadawców, tematy kampanii APTWspiera triage Initial Access
Exchange OnlineAudit/SearchCompliance Search po Attachments:*.epsPo stronie poczty
CloudTrail (S3 Data Events)GetObjectPobrania dokumentów z rozszerzeniami .doc/.docx/.rtf/.eps z nieznanych lokalizacji/IPOpcjonalne, jeśli hosting w S3
K8s audit / ESXi[brak danych / zwykle nie dotyczy]Eksploatacja dotyczy klienta Office

Źródła podatności i wersji: NVD/MS15‑099; KEV potwierdza eksploatację w realu.


Detekcja (praktyczne reguły)

Sigma (dwie gotowe reguły)

A) Office → nietypowe procesy potomne (T1204.002 / T1203 / T1566.001)

title: Office Spawns Unusual Child Process (EPS/CVE-2015-2545 tradecraft)
id: 1b3ef8a6-5d5e-4f79-8c42-3f9f5f0c9b15
status: stable
description: Detects Office applications spawning suspicious system utilities often used post-exploitation.
references:
  - https://attack.mitre.org/techniques/T1204/002/
  - https://attack.mitre.org/techniques/T1203/
  - https://attack.mitre.org/techniques/T1566/001/
tags:
  - attack.T1204.002
  - attack.T1203
  - attack.T1566.001
logsource:
  category: process_creation
  product: windows
detection:
  parent_office:
    ParentImage|endswith:
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
      - '\POWERPNT.EXE'
      - '\OUTLOOK.EXE'
  suspicious_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\regsvr32.exe'
      - '\rundll32.exe'
      - '\schtasks.exe'
      - '\certutil.exe'
  condition: parent_office and suspicious_child
falsepositives:
  - Legalne dodatki Office, automatyzacja skryptowa w działach DTP
level: high
fields:
  - ParentImage
  - Image
  - CommandLine
  - ParentCommandLine
  - User

B) (Środowiska legacy) Ładowanie filtra EPS przez Office

title: Office Loads EPS Filter (EPSIMP32.FLT) - Legacy Host
id: 0e7a0c6e-c9f0-4c8a-b0a3-7c3a1d0a9c01
status: experimental
description: Detects image load of EPSIMP32.FLT by Office processes (should be disabled on modern Office).
tags: [ attack.T1203, attack.T1204.002 ]
logsource:
  category: image_load
  product: windows
detection:
  selection:
    ImageLoaded|endswith: '\EPSIMP32.FLT'
    Image|endswith:
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
      - '\POWERPNT.EXE'
  condition: selection
falsepositives:
  - Stare, niezałatane instalacje Office z włączonym EPS
level: medium

Kontekst ATT&CK i status technik: T1203, T1204.002 oraz T1566.001 w ATT&CK v18.0.


Splunk (SPL)

Office → nietypowe dziecko

index=endpoint sourcetype IN ("Sysmon:ProcessCreate","WinEventLog:Security")
| eval Parent=coalesce(ParentImage,ParentProcessName)
| eval Image=coalesce(Image,NewProcessName)
| where like(lower(Parent), "%\\winword.exe")
   OR like(lower(Parent), "%\\excel.exe")
   OR like(lower(Parent), "%\\powerpnt.exe")
   OR like(lower(Parent), "%\\outlook.exe")
| where like(lower(Image), "%\\cmd.exe")
   OR like(lower(Image), "%\\powershell.exe")
   OR like(lower(Image), "%\\wscript.exe")
   OR like(lower(Image), "%\\cscript.exe")
   OR like(lower(Image), "%\\mshta.exe")
   OR like(lower(Image), "%\\regsvr32.exe")
   OR like(lower(Image), "%\\rundll32.exe")
   OR like(lower(Image), "%\\schtasks.exe")
   OR like(lower(Image), "%\\certutil.exe")
| stats values(CommandLine) as cmd by _time host user Parent Image
| sort - _time

Ładowanie EPSIMP32.FLT (Sysmon EID 7)

index=endpoint sourcetype="Sysmon:ImageLoad"
ImageLoaded="*\\EPSIMP32.FLT" (ProcessImage="*\\WINWORD.EXE" OR ProcessImage="*\\EXCEL.EXE" OR ProcessImage="*\\POWERPNT.EXE")
| table _time host ProcessImage ImageLoaded Signed Status

KQL (Microsoft 365 Defender – Advanced Hunting)

// Office -> suspicious child
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE","OUTLOOK.EXE")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","regsvr32.exe","rundll32.exe","schtasks.exe","certutil.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessCommandLine, AccountName
| order by Timestamp desc
// (Legacy) EPS filter load by Office
DeviceImageLoadEvents
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE")
| where FileName endswith "EPSIMP32.FLT"
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath, SHA256

CloudTrail query (CloudWatch Logs Insights — gdy dokument hostowany w S3)

fields @timestamp, eventName, requestParameters.bucketName as bucket, requestParameters.key as key, sourceIPAddress, userAgent
| filter eventSource = "s3.amazonaws.com"
| filter eventName in ["GetObject","GetObjectVersion"]
| filter key like /(?i)\.(doc|docx|rtf|ppt|pptx|pps|eps)$/ 
| sort @timestamp desc

Pamiętaj: aby widzieć Data Events S3, muszą być włączone dla bukietu.


Elastic / EQL

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

(opcjonalnie — sekwencja z ładowaniem filtra EPS na hostach legacy)

sequence by host.id with maxspan=5m
  [process where process.name in ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE")]
  [image_load where file.name == "EPSIMP32.FLT"]
  [process where process.name in ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","regsvr32.exe")]

Heurystyki / korelacje

  • Korelacja czasowa 0–5 min: zapis plików Office w %TEMP% → uruchomienie lolbin.
  • Office + ImageLoad EPSIMP32.FLT (na starszych hostach) → wysoka waga.
  • EmailEvents ↔ DeviceProcessEvents: załącznik → otwarcie → spawn lolbin.
  • Nietypowe strefy czasowe/IP dla GetObject z S3 lub pobrania dokumentu.
  • Blok EPS w orgu: każdy ImageLoad EPSIMP32.FLT = anomalia konfiguracyjna.

False positives / tuning

  • Legalne dodatki Office (DTP, automatyzacje) mogą spawnować procesy — zastosuj listy wyjątków dla znanych ścieżek/podpisów.
  • W środowiskach, gdzie EPS jest per-policy włączony (np. starsze stacje offline), potwierdzaj kontekst (źródło pliku, nadawca, reputacja).
  • Zmniejsz FP przez kontekst: brak interakcji użytkownika, nietypowe CommandLine, rzadkie child process, procesy sieciowe zaraz po otwarciu dokumentu.

Playbook reagowania (SOC)

  1. Triage alertu: potwierdź łańcuch Office → child → sieć/pliki oraz ewentualny EPSIMP32.FLT.
  2. Izolacja hosta (MDE): Live Response / Isolate device.
  3. Hunting w M365:
    • KQL (sekcja 7) → wylistuj inne hosty/użytkowników z tym samym nadawcą/załącznikiem.
    • EmailEvents / EmailAttachmentInfo: koreluj temat, nadawcę, hash załącznika.
  4. Containment:
    • Quarantine pliku i StopAndQuarantineFile (MDE).
    • W Exchange Online (Compliance): wyszukaj i usuń wiadomości z EPS: New-ComplianceSearch -Name "EPS-bulk" -ExchangeLocation All -ContentMatchQuery 'attachments:*.eps' Start-ComplianceSearch -Identity "EPS-bulk" New-ComplianceSearchAction -SearchName "EPS-bulk" -Purge -PurgeType SoftDelete
  5. Eradication:
    • Upewnij się, że hosty mają zainstalowane poprawki MS15‑099 lub nowsze; sprawdź, czy EPS jest wyłączony (w nowoczesnych Office jest domyślnie).
  6. Recovery: sprawdź trwałość (Run/Services/Tasks); rotacja haseł kont interaktywnych, jeśli były użyte.
  7. Lessons learned: wymuś blokadę załączników EPS na bramkach, włącz szkolenie użytkowników i pre‑filter DMARC/SPF/DKIM.

Przykłady z kampanii / case studies

  • PLATINUM (TwoForOne): pierwsze wykryte użycie CVE‑2015‑2545 (sierpień 2015); później porzucone po patchach.
  • APT16 (Tajwan, 2015): wariant exploita EPS, łańcuch spearphishing + ELMER.
  • EvilPost (Japonia, 2015), SPIVY oraz kampania Danti (2016): konsekwentne używanie EPS w DOCX; omówienia telemetryczne i szczegóły shellcode.
  • FireEye/Mandiant “The EPS Awakens”: opis wykorzystania PostScript do wywołania korupcji pamięci oraz 0‑day w momencie ujawnienia.

Lab (bezpieczne testy) — przykładowe komendy

Tylko w izolowanym środowisku testowym. Celem jest walidacja detekcji, nie eksploatacja luki.

  • Atomic Red Team — T1566.001 (Spearphishing Attachment): ćwicz pipeline pocztowy bez złośliwości (pobranie przykładowego dokumentu/artefaktu), aby sprawdzić korelacje EmailEvents → DeviceProcessEvents.
  • Atomic Red Team — T1204.002 (User Execution: Malicious File): uruchom testy, które symulują uruchomienie nietypowych child process przez aplikacje użytkownika (bez exploitów).
    • Instalacja narzędzi (lab): patrz Invoke‑AtomicRedTeam i dokumentacja uruchamiania lokalnego. IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1'); Install-AtomicRedTeam -getAtomics # Przykład: uruchom scenariusze T1204.002 bez złośliwych payloadów Invoke-AtomicTest T1204.002 -ShowDetailsBrief Po teście wykonaj cleanup zgodnie z instrukcjami atomika.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK):

  • M1051 — Update Software: bezwzględne łatanie Office (MS15‑099 i nowsze).
  • M1054 — Software Configuration: globalna blokada EPS (wspierana przez Microsoft; domyślnie wyłączone od 2017 r., zniesione obejście rejestrem w 2018 r.).
  • M1037 — Filter Network Traffic: blokady na bramkach pocztowych/http, sandboxing załączników.

Powiązane techniki ATT&CK:

  • T1566.001 (wektor wejścia — spearphishing attachment),
  • T1204.002 (wykonanie przez użytkownika),
  • T1203 (exploitation klienta).

Źródła / dalsza literatura

  • NVD — CVE‑2015‑2545 (opis, CVSS v3.1 7.8, KEV) (NVD)
  • Microsoft MS15‑099 — biuletyn bezpieczeństwa (patch, wektor przez EPS) (Microsoft Learn)
  • Microsoft: wsparcie dla EPS wyłączone w Office (od 2017‑04‑11; trwałe wyłączenie obejścia rejestrem od 2018‑05) (Microsoft Support)
  • Kaspersky Securelist (2016): „CVE‑2015‑2545: overview of current threats” — kampanie APT, omijanie ASLR/DEP, EPSIMP32.FLT (securelist.com)
  • Mandiant/FireEye: „The EPS Awakens” — analiza zero‑day (CVE‑2015‑2545) (Google Cloud)
  • CISA — Known Exploited Vulnerabilities Catalog (wpis CVE‑2015‑2545, dodany 2022‑03‑03) (CISA)
  • MITRE ATT&CK: T1203, T1204.002, T1566.001; wersja v18.0 (2025‑10‑28) (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Włącz reguły: Office → child process (cmd/powershell/wscript/mshta/…); EPSIMP32.FLT (legacy).
  • Koreluj EmailEvents ↔ DeviceProcessEvents (okno 0–5 min).
  • Blokuj .eps na bramkach pocztowych i w DLP.
  • Hunt na stacjach z przestarzałym Office; potwierdź brak możliwości wstawiania EPS.
  • W razie incydentu: izolacja hosta, purge wiadomości, unieważnienie tokenów, IOC sweep.

CISO (strategiczne):

  • Wymuszone aktualizacje Office (M1051) oraz polityka „no‑EPS”.
  • Regularne testy kontrolne (Atomic Red Team) dla T1566.001/T1204.002.
  • KPI: MTTR od alertu Office→child, odsetek stacji z zablokowanym EPS, E2E e-mail sandbox rate.
  • Wdrożona polityka filtrowania treści i reputacji nadawcy (DMARC/SPF/DKIM).

Podsumowanie ryzyka: mimo wieku, CVE‑2015‑2545 pozostaje istotny kontekstowo (retro/legacy, archiwa poczty). Najlepszą obroną są: aktualizacje, blok EPS, detekcje łańcucha Office→lolbin i silne kontrole pocztowe.

CVE‑2015‑1641 (Microsoft Office Memory Corruption w RTF) — zdalne wykonanie kodu po otwarciu spreparowanego dokumentu

TL;DR

CVE‑2015‑1641 to błąd obsługi RTF w Microsoft Office (Word/Word Viewer/Word Automation Services), który umożliwia RCE w kontekście użytkownika po otwarciu złośliwego pliku. W ATT&CK mapuje się to przede wszystkim na T1203 (Exploitation for Client Execution), zwykle dostarczane przez T1566.001 (Spearphishing Attachment) i/lub uruchamiane przez T1204.002 (User Execution: Malicious File). Skuteczna obrona opiera się na aktualizacjach, regułach ASR blokujących potomne procesy Office, kontroli aplikacji (WDAC/AppLocker) i analityce parent→child (Office → LOLBin).


Krótka definicja techniczna

CVE‑2015‑1641 to podatność w sposobie, w jaki Microsoft Office przetwarza RTF w pamięci; umożliwia zdalne wykonanie kodu po otwarciu specjalnie przygotowanego dokumentu (np. .rtf). Atak skutkuje uruchomieniem procesu/łańcucha procesów potomnych z rodzicem WINWORD.EXE (lub inną aplikacją Office) i typowo prowadzi do pobrania/uruchomienia ładunku (np. przez cmd.exe, powershell.exe, mshta.exe, rundll32.exe).


Gdzie występuje / przykłady platform

  • Windows / macOS (Word dla Mac 2011) — otwarcie/obsługa RTF przez aplikacje Office.
  • SharePoint (Word Automation Services), Office Web Apps — przetwarzanie dokumentów po stronie serwerowej.
  • M365/Exchange Online — wektor dostarczenia (e‑mail z załącznikiem RTF), detekcja/remediacja po stronie Defender for Office 365 (ZAP, akcje purge).
  • Środowiska hybrydowe (AD + M365) — najczęstszy scenariusz spearphishing + endpoint Windows.

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

Atakujący dostarcza spreparowany dokument RTF. Gdy aplikacja Office przetwarza plik, błąd w obsłudze RTF prowadzi do korupcji pamięci i wykonania arbitralnego kodu w kontekście bieżącego użytkownika. To umożliwia wykonanie stagera i ruch dalszy (np. dowolny LOLBin). Technika jest skuteczna, bo:

  • Wymaga jedynie interakcji użytkownika (otwarcie dokumentu) i często wygląda jak zwykła korespondencja służbowa (T1566.001 + T1204.002).
  • Office jest powszechny, a łańcuch Office → interpretery/LOLBin jest typową ścieżką living‑off‑the‑land.
  • Historycznie podatność była obserwowana “in the wild” w kampaniach APT (np. Sednit/Sofacy) oraz figuruje w KEV, co potwierdza realne wykorzystanie.

6) Artefakty i logi (tabela)

WarstwaŹródło/typID / PoleCo szukać
WindowsSecurity4688 (Process Creation)ParentImage = \WINWORD.EXE/EXCEL.EXE/POWERPNT.EXE + NewProcessName = cmd.exe, powershell.exe, mshta.exe, wscript.exe, rundll32.exe, regsvr32.exe
WindowsSysmon1 (ProcessCreate), 3 (NetworkConnect), 11 (FileCreate), 7 (ImageLoad), 13 (Registry)Łańcuch Office → LOLBin, nietypowe połączenia wychodzące tuż po uruchomieniu potomka, zapisy do %TEMP%/%APPDATA%
MDEAdvanced HuntingDeviceProcessEvents, DeviceNetworkEventsInitiatingProcessFileName w {WINWORD/EXCEL/POWERPNT}, FileName w {cmd/powershell/…}, nietypowe domeny C2
M365Defender for Office 365 / PurviewZAP, New-ComplianceSearchAction -PurgeAlerty o złośliwych załącznikach, raporty EOP, akcje SoftDelete/HardDelete przy remediacji maili.
AWSCloudTrail Lake (opcjonalnie, jeśli SES/WorkMail → S3)PutObject/GetObject (S3 data events)Masowe wrzuty .rtf do skrzynek/bucketów przychodzących; korelować ze wzrostem alertów EOP (jeśli integracja).
K8s audit[nie dotyczy] – podatność dotyczy klienta Office
GCP/Azure[nie dotyczy] – j.w.

Detekcja (praktyczne reguły)

Sigma

title: Office Spawns Suspicious Child Process (CVE-2015-1641 tradecraft)
id: 4c8c6a7b-9d0e-46d0-9a9e-1641office-child-proc
status: experimental
description: Wykrywa uruchamianie podejrzanych procesów potomnych przez aplikacje Office (WINWORD/EXCEL/POWERPNT).
references:
  - https://attack.mitre.org/techniques/T1203/
  - https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-reference
logsource:
  category: process_creation
  product: windows
detection:
  parent_office:
    ParentImage|endswith:
      - '\WINWORD.EXE'
      - '\EXCEL.EXE'
      - '\POWERPNT.EXE'
      - '\WORDVIEW.EXE'
  child_suspicious:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\hh.exe'
      - '\msbuild.exe'
      - '\installutil.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: parent_office and child_suspicious
falsepositives:
  - Legalne dodatki Office/automatyzacje (DLP, AV, integracje korporacyjne)
level: high
tags:
  - attack.t1203
  - attack.execution

(Technika T1203, ASR „Block Office apps from creating child processes”).

Splunk (SPL)

(index=win* (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
 OR (sourcetype="WinEventLog:Security" EventCode=4688))
| eval parent=coalesce(ParentImage, ParentProcessName), child=coalesce(Image, NewProcessName)
| where like(lower(parent), "%\\winword.exe")
   OR like(lower(parent), "%\\excel.exe")
   OR like(lower(parent), "%\\powerpnt.exe")
   OR like(lower(parent), "%\\wordview.exe")
| where match(lower(child), "\\\\(cmd|powershell|wscript|cscript|mshta|rundll32|regsvr32|hh|msbuild|installutil|certutil|bitsadmin)\\.exe$")
| stats earliest(_time) as first_seen, values(CommandLine) as cmd, values(ParentCommandLine) as p_cmd by host, user, parent, child
| convert ctime(first_seen)

KQL (Microsoft 365 Defender – Advanced Hunting)

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE","WORDVIEW.EXE")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe",
                      "rundll32.exe","regsvr32.exe","hh.exe","msbuild.exe","installutil.exe",
                      "certutil.exe","bitsadmin.exe")
| project Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine
| order by Timestamp desc

CloudTrail Lake (SQL) — opcjonalnie (SES/WorkMail→S3)

-- Wymaga włączonych data events dla S3
SELECT eventTime, eventSource, eventName, sourceIPAddress,
       requestParameters.bucketName AS bucket, requestParameters.key AS object
FROM $EDS_EVENT
WHERE eventName IN ('PutObject','GetObject')
  AND requestParameters.key LIKE '%.rtf'
  AND eventTime > TIMESTAMP '2025-11-01 00:00:00';

(Użyte do korelacji fali załączników .rtf z incydentami e‑mail.)

Elastic / EQL

process where
  process.parent.name in ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE","WORDVIEW.EXE") and
  process.name in ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe",
                   "rundll32.exe","regsvr32.exe","hh.exe","msbuild.exe","installutil.exe",
                   "certutil.exe","bitsadmin.exe")

Heurystyki / korelacje

  • Parent→Child: Office → (cmd/powershell/wscript/mshta/rundll32/regsvr32) + sieć w ≤2 min od uruchomienia.
  • Ścieżki plików: tworzenie DLL/EXE/skrótów w %TEMP%, %APPDATA%, Startup, Office\Recent (Sysmon 11 + 1).
  • DNS/HTTP(S): nowe domeny bez reputacji tuż po otwarciu dokumentu.
  • ASR: zdarzenia AsrOfficeChildProcessAudited/Blocked (jeśli reguła włączona).
  • E‑mail → endpoint: korelacja EmailEvents (złośliwy załącznik RTF) z telemetrią procesu na hoście.

False positives / tuning

  • Legalne dodatki Office, wtyczki DLP/AV, integracje (np. eksport do PDF z użyciem procesów systemowych).
  • Narzędzia administracyjne i automatyzacje (np. pakiety do raportowania) — whitelist wg hasha, ścieżki i podpisu.
  • Tuning: wyklucz znane, podpisane ścieżki biznesowe; zostaw reguły ogólne dla cmd/powershell/mshta/... wywoływanych przez Office. Regułę Sigma/kwarantannę zaostrzaj dopiero po tygodniu audytu.

Playbook reagowania (kroki + komendy)

  1. Triag i zawężenie
  • Uruchom zapytania (SPL/KQL powyżej).
  • Piwotuj po ParentImage=WINWORD.EXE i user session.
  • Sprawdź alerty MDO (Defender for Office 365) i retencję ZAP.
  1. Izolacja i skan
  • Izoluj host w EDR/MDE (izolacja sieci).
  • Na hoście: szybki skan AV:
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -Scan -ScanType 2
  1. Higiena skrzynek (Purview/PowerShell) — usuń złośliwe maile:
New-ComplianceSearch -Name "CVE-2015-1641-purge" -ExchangeLocation All \
  -ContentMatchQuery '(attachments:".rtf") AND (Subject:"<ciąg kampanii>" OR From:"<nadawca>")'
Start-ComplianceSearch -Identity "CVE-2015-1641-purge"
New-ComplianceSearchAction -SearchName "CVE-2015-1641-purge" -Purge -PurgeType SoftDelete

(Potwierdzone procedury Purview).

  1. Artefakty
  • Zbierz pliki z %TEMP%/%APPDATA%, Prefetch, $MFT, Sysmon log.
  • Sprawdź autostarty (Run, Startup, zadania).
  1. Remediacja i twardnienie
  • Patch Office/SharePoint/Web Apps (MS15‑033 i nowsze).
  • Włącz/egzekwuj ASR: Block Office apps from creating child processes (d4f940ab-401b-4efc-aadc-ad5f3c50688a).
    Przykład (testowo – AuditMode):
Add-MpPreference -AttackSurfaceReductionRules_Ids d4f940ab-401b-4efc-aadc-ad5f3c50688a `
                 -AttackSurfaceReductionRules_Actions AuditMode

Dokumentacja ASR: referencja/enable.


Przykłady z kampanii / case studies

  • Sednit / Sofacy (APT28) – kampanie z załącznikami RTF wykorzystującymi CVE‑2015‑1641; po otwarciu zrzucały dwa DLL (np. btecache.dll, svchost.dll) i ładowały ładunek Seduploader.
  • Confucius – wykorzystywał podatności Office, w tym CVE‑2015‑1641, do uzyskania wykonania na stacjach ofiar.
  • Microsoft i media branżowe wskazywały na wykorzystanie in‑the‑wild przy wydaniu MS15‑033.

Lab (bezpieczne testy)

Wyłącznie w izolowanym, nieprodukcyjnym środowisku! Celem jest test detekcji, nie eksploatacja.

A. Dymny test ASR (AuditMode)

  1. Ustaw ASR „Block Office apps from creating child processes” w AuditMode (komenda powyżej).
  2. Utwórz w Wordzie prosty makrotest, który uruchamia Notepad (bezpieczny program): Sub TestChild() CreateObject("WScript.Shell").Run "notepad.exe" End Sub
  3. Uruchom makro → sprawdź, czy pojawiły się zdarzenia audytowe ASR/EDR i alert Sigma/SIEM. (Przykładowe demo ASR: Microsoft docs).

B. Heurystyka parent→child (bez makr)
Uruchom winword.exe, a następnie ręcznie zainicjuj proces potomny z linii poleceń (symulacja anomalii):

Start-Process "$env:ProgramFiles\Microsoft Office\root\Office16\WINWORD.EXE"
Start-Sleep -s 5
Start-Process cmd.exe -ArgumentList "/c echo benign" -WindowStyle Hidden

Sprawdź, czy reguły (Sigma/SPL/KQL) flagują zdarzenie.

C. E‑mail flow (MDO)
Wyślij do skrzynki labowej .rtf z nieszkodliwą zawartością i sprawdź ścieżkę skanowania/raporty MDO/ZAP oraz logi Purview (bez złośliwego payloadu).


Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK):

  • M1051 – Update Software (regularne łatki Office/SharePoint/Web Apps).
  • M1038 – Execution Prevention (WDAC/AppLocker; ASR blokujący potomne procesy Office).
  • M1042 – Disable or Remove Feature or Program (wyłącz nieużywane komponenty, ogranicz makra).
  • M1017 – User Training (świadomość spearphishingu).

Powiązane techniki (często współwystępują):

  • T1566.001 – Phishing: Spearphishing Attachment (wektor dostarczenia).
  • T1204.002 – User Execution: Malicious File (użytkownik otwiera plik).
  • T1218 – Signed Binary Proxy Execution (np. rundll32.exe, regsvr32.exe).
  • T1059 – Command and Scripting Interpreter (PowerShell/WSH).
  • T1105 – Ingress Tool Transfer (pobranie kolejnych ładunków).
  • T1547 – Boot or Logon Autostart Execution (utrwalenie po eksploatacji).

Źródła / dalsza literatura

  • NVD – CVE‑2015‑1641 (opis, CVSS, wpis KEV w CISA). (NVD)
  • Microsoft MS15‑033 – biuletyn, lista produktów i opis RTF memory corruption. (Microsoft Learn)
  • ATT&CK T1203 – technika, wersja, modyfikacja 24.10.2025. (MITRE ATT&CK)
  • ATT&CK – wersje/aktualności – v18 (10.2025). (MITRE ATT&CK)
  • SecurityWeek – patch Tuesday z adnotacją „exploited in the wild” (CVE‑2015‑1641). (SecurityWeek)
  • ESET “En Route with Sednit” – przykład kampanii (Seduploader via CVE‑2015‑1641). (web-assets.esetstatic.com)
  • Defender for Office 365 – remediacja maili (ZAP/Purge). (Microsoft Learn)
  • ASR – referencja i włączanie – blokada potomnych procesów Office. (Microsoft Learn)

Checklisty dla SOC / CISO

SOC – operacyjna

  • Monitoring parent→child: Office → (cmd/powershell/mshta/wscript/…) w SIEM.
  • Włącz ASR Block Office apps from creating child processes (najpierw AuditMode, potem Block).
  • Korelacja e‑mail (EOP/MDO) ↔ endpoint (EDR).
  • Hunts: świeże .rtf + nietypowe połączenia po otwarciu dokumentu.
  • Procedura Purview Search+Purge gotowa do masowej remediacji.

CISO – strategiczna

  • Polityka patchowania Office/SharePoint/Web Apps (SLA).
  • Polityka makr, kontrola aplikacji (WDAC/AppLocker).
  • Szkolenia spearphishing/zasady otwierania załączników.
  • Testy okresowe (lab) pod T1203/T1566.001 z metrykami skuteczności.