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ą:
Wydawać nowe access tokeny, nawet po wygaśnięciu poprzednich.
Przeglądać/eksportować dane CRM przez API (np. obiekty Lead, Contact, Case, Opportunity).
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:
Inwentaryzuj i tymczasowo ogranicz wszystkie Connected Apps Gainsight (CS, PX, itp.) — sprawdź OAuth scopes, IP Relaxation, Permitted Users, Session Policies.
Wymuś rotację: odłącz i ponownie autoryzuj integracje po oficjalnym przywróceniu; przeprowizjonuj klucze API/sekrety i zmień client secrets po stronie Gainsight.
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).
Zastosuj polityki: High Assurance Sessions dla wrażliwych obiektów, Transaction Security Policies dla masowych zapytań API, MFA/step-up dla administracji integracjami.
Zasada najmniejszych uprawnień: ogranicz scopes i profile integracji; rozdziel instancje/projekty dla środowisk (prod/sandbox).
DLP i monitoring: reguły DLP na eksport CSV/Reports, alerty na nietypową objętość API.
Higiena tokenów: krótszy TTL refresh tokenów, cykliczna rotacja, bez przechowywania sekretów w ticketach/jira/confluence; redakcja danych w zgłoszeniach.
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.
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)
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:
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-0111 – authenticated 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ł.
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
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.)
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).
Rate-limiting i ochrona przed brute force na endpointzie /global-protect/login.esp (CAPTCHA po nieudanych próbach, progressive backoff, blokady IP).
Monitoruj sygnatury JA4t/TLS wskazane przez GreyNoise w regułach NIDS/SIEM; koreluj z logami failed-auth.
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.
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żę.)
Higiena haseł i polityki kont: wymuś rotację haseł po wykryciu anomalii, włącz ochronę przed reuse, sprawdzaj przeciw bazom wycieków (np. HIBP).
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
GreyNoise: Palo Alto Scanning Surges 40X in 24 Hours, Marking 90-Day High (19 listopada 2025). (greynoise.io)
BleepingComputer: GlobalProtect VPN portals probed with 2.3 million scan sessions (20 listopada 2025). (Bleeping Computer)
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).
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):
Ofiara trafia na domenę przynęty (np. previewdoc[.]us) i przechodzi Cloudflare Turnstile.
Strona stylizowana na podgląd PDF/Adobe zachęca do „Sign in with Microsoft”.
Po kliknięciu renderowane jest okno BitB – pasek adresu i ramka imitują Edge/Windows lub Safari/macOS (dopasowanie do platformy ofiary).
Wewnątrz okna ładuje się realny przepływ logowania Microsoft, ale przez reverse-proxy/Sneaky AiTM, który podkrada hasło + token sesyjny.
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):
Wymuś phishing-resistant MFA (FIDO2/WebAuthn) dla kont uprzywilejowanych i wrażliwych ról; ogranicz SMS/OTP. (Kontekst: AiTM/BitB atakują sesję).
SSO/MFA policy hardening: step-up dla ryzykownych sygnałów, blokada starszych metod (legacy), wymuszenie device compliance.
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.
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):
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).
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[.]*.
Telemetria przeglądarkowa/EDR: wykrywanie osadzonych „okien” z atrybutami nietypowymi dla natywnego pop-upa; alerty na Cloudflare Turnstile → Microsoft login w krótkiej sekwencji.
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
BleepingComputer – Sneaky2FA PhaaS kit now uses redteamers’ Browser-in-the-Browser attack (19 listopada 2025). (BleepingComputer)
Push Security – Analyzing the latest Sneaky2FA Browser-in-the-Browser phishing page (18 listopada 2025). (Push Security)
Sekoia – Sneaky 2FA: exposing a new AiTM Phishing-as-a-Service (16 stycznia 2025). (Sekoia.io Blog)
Sekoia – Global analysis of Adversary-in-the-Middle phishing threats (11 czerwca 2025). (Sekoia.io Blog)
mr.d0x – Browser In The Browser (BITB) Attack (15 marca 2022). (mrd0x.com)
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
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.
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.
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
University of Vienna – komunikat prasowy o luce i mitigacji. (Universität Wien)
SBA Research – notatka o badaniu i potwierdzeniu wdrożonych zabezpieczeń. (sba-research.org)
WIRED – artykuł z technicznymi szczegółami (tempo enumeracji, statystyki profili, powtórzenia kluczy) oraz stanowiskiem WhatsApp. (WIRED)
The Register – relacja z komentarzami badaczy i inżyniera WhatsApp (stan po wdrożeniu środków anty-scrapingowych). (The Register)
Repozytorium GitHub projektu whatsapp-census (opis i materiały badania). (GitHub)
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).
Nagłe crashe Flash niedługo przed nietypowym procesem‑dzieckiem.
Proxy/NGFW/DNS
Dostęp HTTP/S do *.swf, MIME application/x-shockwave-flash
url, mime, user_agent, referrer
Koreluj z kliknięciami z e‑maila (M365).
M365 Defender
EmailUrlInfo, UrlClickEvents
Url, UrlDomain, kliknięcia Safe Links
Łącz URL .swf z hostami, które uruchomiły procesy Flash.
MITRE ATT&CK (kontekst)
APT3 + SHOTPUT
Profilowanie, dostarczenie backdoora
Do korelacji z TTP grupy.
AWS (opcjonalnie)
CloudTrail Lake (S3 Data Events)
GetObject na kluczach %.swf
Wymaga włączonych data events.
CDN
CloudFront Access Logs / Athena
cs-uri-stem like '%.swf', sc-content-type
Przy 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
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)
Zablokuj źródło: domenę/URL z .swf w proxy/DNS firewall; wypchnij blokadę przez EDR.
Izoluj host z alertem (EDR quarantine).
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).
Hunting rozprzestrzenienie: użyj zapytań (SPL/KQL/EQL powyżej) w horyzoncie 7–30 dni.
Patch & harden: potwierdź brak Flash w flocie (wycofanie EOL), wymuś aktualizacje przeglądarek.
Eradykacja: usuń artefakty, przeinstaluj przeglądarkę, unieważnij poświadczenia pozyskane po kompromitacji.
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.
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:
Initial Access: spearphishing z załącznikiem zawierającym EPS (T1566.001).
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+).
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.
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.).
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 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.
(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.
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)
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.
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)
Ustaw ASR „Block Office apps from creating child processes” w AuditMode (komenda powyżej).
Utwórz w Wordzie prosty makrotest, który uruchamia Notepad (bezpieczny program): Sub TestChild() CreateObject("WScript.Shell").Run "notepad.exe" End Sub
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):
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).