Archiwa: AI - Strona 62 z 68 - Security Bez Tabu

Tag: AI

Microsoft rozszerza program bug bounty na kod firm trzecich i open source: „In Scope by Default”

Wprowadzenie do problemu / definicja luki

Microsoft ogłosił duże rozszerzenie programu bug bounty: krytyczne podatności w kodzie Microsoftu, firm trzecich oraz open source kwalifikują się do nagród jeśli mają bezpośredni, wykazywalny wpływ na usługi online Microsoftu. Firma nazywa tę zmianę podejściem „In Scope by Default” — wszystkie usługi online są domyślnie objęte programem, a nowe trafiają do scope w momencie premiery. To przesuwa akcent z „kto jest właścicielem kodu” na realny efekt podatności dla klientów.

W skrócie

  • Scope domyślny: wszystkie usługi online Microsoftu są objęte programem; nowe usługi wchodzą do scope od dnia uruchomienia.
  • Kod zewnętrzny też się liczy: krytyczne luki w komponentach third-party i open source kwalifikują się, o ile uderzają w usługi Microsoftu.
  • Gdy „nie ma programu” — i tak płacą: jeśli brak istniejącego bounty dla danego komponentu, Microsoft deklaruje przyznanie nagrody, by domknąć lukę zachęt dla badaczy.
  • Konsekwencje rynkowe: to praktycznie zachęta do full-stack research: łańcuchy zależności, integracje SaaS, biblioteki OS i konfiguracje chmurowe. Potencjalnie krótszy czas wykrycia/naprawy luk „na styku”. (Wniosek na podstawie źródeł.)
  • Kontekst finansowy: w poprzednim roku Microsoft wypłacił >17 mln USD w ramach bounty i inicjatywy Zero Day Quest; tegoroczna edycja ZDQ miała pulę do 5 mln USD.

Kontekst / historia / powiązania

Zmiana została ogłoszona 11 grudnia 2025 r. podczas Black Hat Europe przez Toma Gallaghera (VP Engineering, MSRC). Microsoft wiąże ją z szerokim programem transformacji bezpieczeństwa Secure Future Initiative (SFI), którego celem jest „security above all else”.

Media branżowe (m.in. SecurityWeek, BleepingComputer, The Register) podkreślają, że jest to istotny zwrot: firma nagradza teraz również badania nad błędami poza własnym kodem, jeśli skutki uderzają w usługi Microsoftu (np. łańcuchy zależności w chmurze).

Analiza techniczna / szczegóły luki

Co jest „in scope” teraz?

  • Wszystkie usługi online Microsoftu — domyślnie. Nowe usługi są objęte w dniu premiery.
  • Krytyczne podatności w:
    • kodzie Microsoftu,
    • kodzie third-party (komercyjnym),
    • open source,
      jeżeli mają „bezpośredni i wykazywalny” wpływ na usługi online Microsoftu (np. RCE w bibliotece, z której korzysta usługa).

Microsoft utrzymuje dotychczasowe programy tematyczne (Azure, Identity, M365, Hyper-V itd.) z określonymi widełkami nagród — np. Hyper-V do 250 tys. USD, Identity do 100 tys. USD — ale nowa zasada „In Scope by Default” rozszerza kwalifikowalność o krytyczne przypadki w łańcuchu dostaw oprogramowania.

Zasady i proces

  • Wymóg Responsible Security Research / Rules of Engagement i zgłoszenia przez kanały MSRC.
  • Priorytet dla badań o najwyższym ryzyku (obszary najczęściej atakowane).

Praktyczne konsekwencje / ryzyko

  • Łańcuch dostaw (SBOM → usługa): badacze mogą celować w biblioteki i integracje, które realnie wpływają na usługi Microsoftu (np. zależność npm/PyPI wykorzystywana przez składową usługi). To powinno skrócić „martwe strefy” scope’u, gdzie wcześniej brakowało bodźców ekonomicznych. (Wniosek na podstawie źródeł.)
  • Lepszy coverage „styków”: luki „na brzegach” — API między usługami, federacje tożsamości, łączniki SaaS — mają większą szansę na szybkie wykrycie i nagrodzenie. (Wniosek na podstawie źródeł.)
  • Ryzyko dla organizacji korzystających z Microsoft 365/Azure: spodziewany wzrost odkrywalności błędów zależności może prowadzić do częstszych, ale szybciej łagodzonych biuletynów i zmian konfiguracji. (Wniosek na podstawie źródeł.)

Rekomendacje operacyjne / co zrobić teraz

Dla Blue Team / SecOps

  • Zaktualizuj playbooki na krytyczne CVE w łańcuchu zależności usług Microsoftu; monitoruj biuletyny MSRC i SFI pod kątem szybkich remediacji.
  • Telemetry „na styku”: wzmacniaj obserwowalność w integracjach (OAuth/OIDC, SCIM, webhooki, konektory), aby skrócić MTTD.

Dla Red Team / Badaczy

  • Celuj w komponenty o wysokiej dźwigni: zależności OS/third-party używane przez usługi online Microsoftu; pamiętaj o zasadach ROE i kanałach zgłoszeń MSRC.
  • Sprawdź widełki i istniejące programy (Azure, Identity, M365 itd.) — to ułatwia wycenę i priorytetyzację badań.

Dla PSIRT / GRC

  • Mapuj zależności (SBOM) własnych rozwiązań z usługami Microsoftu (np. Entra ID, Graph, SharePoint Online), aby szybciej ocenić ekspozycję na przyszłe zgłoszenia i łatki. (Wniosek na podstawie źródeł.)
  • Śledź ZDQ — konkurs Zero Day Quest przynosi przyspieszone zgłoszenia w krytycznych obszarach (AI, chmura), co zwykle poprzedza publikacje.

Różnice / porównania z innymi przypadkami

  • Dotąd programy bug bounty Microsoftu miały ściśle zdefiniowany scope per produkt/usługę. Teraz — jeżeli krytyczna luka uderza w usługi online, liczy się efekt, a nie właściciel kodu. To zbliża model do myślenia agresora (wybór najsłabszego ogniwa w łańcuchu), co zauważyły redakcje branżowe.

Podsumowanie / kluczowe wnioski

  • Microsoft systemowo domyka białe plamy w zachętach dla badań nad łańcuchem dostaw: „In Scope by Default” oznacza, że krytyczne luki w kodzie zewnętrznym też mogą zostać nagrodzone, jeśli uderzają w usługi online firmy.
  • Ruch wpisuje się w SFI i trend wzmacniania bezpieczeństwa po stronie usług chmurowych i AI — w tym poprzez Zero Day Quest z pulą do 5 mln USD i rekordowe >17 mln USD wypłat rok do roku.

Źródła / bibliografia

  1. Microsoft MSRC — Evolving our approach to coordinated security research: In scope by default (11 grudnia 2025). (Microsoft)
  2. SecurityWeek — Microsoft Bug Bounty Program Expanded to Third-Party Code (12 grudnia 2025). (SecurityWeek)
  3. Microsoft — Microsoft Bounty Programs (strona programów, widełki nagród). (Microsoft)
  4. BleepingComputer — Microsoft bounty program now includes any flaw impacting its services (grudzień 2025). (BleepingComputer)
  5. The Register — Microsoft now buys bugs, with or without a bounty program (grudzień 2025). (The Register)

Ponad 10 000 obrazów Docker Hub wyciekło tajne dane i klucze — co naprawdę poszło nie tak?

Wprowadzenie do problemu / definicja luki

10 grudnia 2025 r. ujawniono wyniki badania zespołu Flare: w samym listopadzie 2025 r. 10 456 obrazów na Docker Hub zawierało wrażliwe „sekrety” — od kluczy API i tokenów chmurowych, po poświadczenia baz danych i klucze do modeli LLM. Część z nich należała do ponad 100 organizacji, w tym do spółki z listy Fortune 500 oraz dużego banku. Co gorsza, aż 42% z tych obrazów miało ≥5 sekretów jednocześnie. Źródłem wielu wycieków były konta „shadow IT” — prywatne lub kontraktorskie, poza korporacyjnym nadzorem.

Serwis BleepingComputer podkreśla także, że ~25% deweloperów usuwało przypadkowo ujawnione dane z obrazów w ciągu 48 godzin, ale w 75% przypadków klucze nie były rotowane — więc nadal mogły być nadużywane. Najczęściej wyciekały klucze do usług AI (OpenAI, Hugging Face, Anthropic, Gemini, Groq) — ok. 4000 kluczy.

W skrócie

  • Skala: 10 k+ obrazów z sekretami w 1 miesiąc skanowania.
  • Ofiary: 100+ firm (SMB + kilka dużych), w tym bank, Fortune 500.
  • Rodzaje sekretów: AI/LLM API, klucze chmurowe (AWS/Azure/GCP), tokeny CI/CD, DB creds, SSH.
  • Główne przyczyny: pliki .env, twardo zakodowane tokeny w kodzie/konfigach, manifesty obrazów, „shadow IT”.
  • Błąd naprawczy: usunięcie z obrazu ≠ unieważnienie klucza; rotacja kluczy krytyczna.

Kontekst / historia / powiązania

Problem nie jest nowy. Badanie akademickie z 2023 r. pokazało, że ~8,5% z 337 171 obrazów Docker Hub zawierało sekrety (m.in. 52 107 kluczy prywatnych), a tysiące hostów faktycznie używało wyciekłych kluczy TLS/SSH — czyli nie chodzi tylko o „ryzyko teoretyczne”.

W 2025 r. GitGuardian raportował 100 000 ważnych sekretów w 15 mln obrazów — potwierdzając, że skala „secret sprawl” w konteneryzacji rośnie szybciej niż praktyki higieny kluczy.

Analiza techniczna / szczegóły luki

Główne wektory ujawnienia:

  • Pliki .env kopiowane do obrazu (często z danymi do DB/chmury).
  • Twarde zakodowanie tokenów w plikach źródłowych, config.json, YAML (np. pipeline’y), a nawet manifesty obrazów.
  • Konta „shadow IT” (osobiste/kontraktorskie), które omijają polityki skanowania i DLP.

Kategorie sekretów najczęściej spotykane w listopadzie 2025:

  • AI/LLM (OpenAI/HF/Anthropic/Gemini/Groq) — prawie 4000 kluczy,
  • Chmura (AWS/Azure/GCP),
  • Bazy danych (Mongo/Postgres/…),
  • SCM/CI (GitHub/NPM/Docker),
  • Płatności/komunikacja (Stripe/SMTP/Slack/Telegram).

Dlaczego to groźne technicznie? Sekrety w obrazie propagują się do każdego środowiska, do którego obraz trafi (dev/test/prod). Ich użycie często omija MFA i klasyczne kontrole perymetrowe — atakujący „autentykuje się” zamiast „hakować”.

Praktyczne konsekwencje / ryzyko

  • Natychmiastowy dostęp do chmury/CI/CD/DB przy pobraniu obrazu (lub przez scraperów skanujących rejestry).
  • Łańcuch dostaw: przejęte tokeny CI/CD → modyfikacja artefaktów → eskalacja u klientów.
  • Ominięcie detekcji: legalny ruch z ważnymi kluczami trudniej odróżnić od działań uprawnionych.
  • Dług żywotności kluczy: brak rotacji po „wyczyszczeniu” obrazu = trwała ekspozycja.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast: reagowanie na incydent

  1. Zidentyfikuj wszystkie publiczne obrazy i ich warstwy (w tym manifesty). Skanuj pod kątem sekretów: trivy, gitleaks, ggshield, dockle (zautomatyzuj w CI).
  2. Wycofaj/rotuj każdy znaleziony sekret (klucze API, tokeny, hasła), unieważnij sesje i odwołaj tokeny OIDC/PAT.
  3. Audyt aktywności dla kont chmurowych/SCM (CloudTrail, GitHub Audit, CI logs) — szukaj nadużyć po dacie publikacji obrazu.
  4. Zmień wszystkie obrazy-bazy na obrazy bez sekretów, wypchnij nowe tagi i odwołaj stare z rejestru (policy + retention).

Na stałe: higiena sekretów

  • Nie umieszczaj sekretów w obrazie (ani w ENV, ani w warstwach). Używaj BuildKit secrets / --secret, multi-stage builds, .dockerignore.
  • Sejf na sekrety: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault; krótkoterminowe i scopowane poświadczenia (STS/OIDC).
  • „Shift-left” skanowanie: commit → PR → build → image → rejestr (policy: „no secret, no merge/push”).
  • Kontrola „shadow IT”: obowiązkowe konta organizacyjne, SSO, discovery kont deweloperskich, monitorowanie namespace’ów.
  • SBOM + podpisywanie (Sigstore/cosign) i atestacje: potwierdzaj pochodzenie i polityki builda.
  • Rotacja okresowa i least privilege dla wszystkich tokenów (GitHub PAT, chmura, dostawcy).
    Rekomendacje powyżej wynikają bezpośrednio z analizy Flare i obserwacji, że samo usunięcie sekretu z obrazu nie wystarcza — rotacja jest kluczowa.

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

W odróżnieniu od wcześniejszych badań akademickich (2023), które pokazały problem strukturalny i jego zasięg historyczny, obecne wnioski Flare dotyczą świeżych, miesięcznych danych i wskazują silny wzrost udziału kluczy AI/LLM jako najczęściej ujawnianych sekretów — co koreluje z gwałtowną adopcją AI w SDLC w 2024–2025.

Raport GitGuardian z 2025 r. (100 000 ważnych sekretów w 15 mln obrazów) dodatkowo unaocznia, że problem nie ogranicza się do pojedynczego miesiąca czy rejestru — to systemowy „secret sprawl” w całym ekosystemie kontenerów.

Podsumowanie / kluczowe wnioski

  • Sekrety w obrazach to nie błąd kosmetyczny, lecz gotowa ścieżka ataku („authenticate-in”).
  • Czas reakcji bez rotacji kluczy jest złudny — wyciekłe, ale nadal ważne tokeny mogą krążyć miesiącami.
  • Najczęstszy grzech: pliki .env i twarde tokeny w kodzie/konfigach + brak polityk dla kont osobistych.
  • Plan minimum: pełna automatyzacja skanowania + sejf na sekrety + krótkoterminowe, ograniczone uprawnienia + stała rotacja.

Źródła / bibliografia

  • Flare — Thousands of Exposed Secrets Found on Docker Hub (10.12.2025). Dane źródłowe, metodologia, statystyki listopad 2025. (flare.io)
  • BleepingComputer — Over 10,000 Docker Hub images found leaking credentials, auth keys (10.12.2025). Artykuł przeglądowy z dodatkowymi przykładami i liczbami. (BleepingComputer)
  • GitGuardian — Uncovering 100,000 Valid Secrets in DockerHub (15.05.2025). Kontekst i skala problemu w 2025 r. (GitGuardian Blog)
  • ArXiv — Secrets Revealed in Container Images: An Internet-wide Study on Occurrence and Impact (07.2023). Badanie akademickie, dane historyczne o sekrecie w obrazach. (arXiv)

Google łata „GeminiJack” — zero-clickową podatność w Gemini Enterprise, która mogła ujawniać dane firmowe

Wprowadzenie do problemu / definicja luki

Google załatało krytyczną podatność w Gemini Enterprise nazwaną „GeminiJack”. To zero-clickowa, pośrednia injekcja promptów (indirect prompt injection), która umożliwiała atakującym bez udziału użytkownika wykradanie wrażliwych danych z usług Google Workspace (Gmail, Docs, Calendar i inne) — wystarczył udostępniony dokument, zaproszenie kalendarza albo e-mail zawierający ukryte instrukcje dla agenta AI. Google potwierdziło wdrożenie mitigacji po zgłoszeniu przez Noma Security.

W skrócie

  • Wejście: Udostępniony artefakt (Docs/Calendar/Gmail) z ukrytymi instrukcjami.
  • Wyzwalacz: Zwykłe zapytanie pracownika do Gemini Enterprise (np. „pokaż nasze budżety”).
  • Działanie: RAG pobiera „zatruty” artefakt, LLM traktuje ukryty tekst jak polecenia i agreguje dane z wielu źródeł, następnie osadza je w zewnętrznym znaczniku obrazu, co skutkuje cichą eksfiltracją podczas ładowania obrazka.
  • Interakcja użytkownika: 0 kliknięć, brak ostrzeżeń i typowych alarmów DLP/AV.
  • Status: Google wdrożyło zmiany architektoniczne ograniczające wektor — m.in. separację Vertex AI Search od Gemini Enterprise i RAG.

Kontekst / historia / powiązania

Badanie opublikowało Noma Security, które wykazało, że problem dotyczył Gemini Enterprise, a wcześniej Vertex AI Search. Media branżowe (SecurityWeek, Dark Reading, ISMG) potwierdziły szczegóły i informację o poprawkach Google. Podatność wpisuje się w szerszą klasę AI-native zagrożeń dla platform z federowanym dostępem i RAG.

Analiza techniczna / szczegóły luki

  1. Zatrucie treści (content poisoning):
    Atakujący tworzy wiarygodny artefakt (np. Q4 Budget Planning) z niewidocznymi instrukcjami (HTML/CSS, minimalny font, biały na białym itp.) nakazującymi agentowi m.in. wyszukiwać frazy typu „confidential”, „API key”, „salary”, „acquisition”. Artefakt trafia do indeksu wiedzy organizacji.
  2. Normalne użycie AI przez pracownika:
    Użytkownik zadaje rutynowe pytanie Gemini Enterprise. Silnik RAG pobiera kontekst, w tym „zatruty” dokument. LLM nie odróżnia instrukcji od dowodu/treści i wykonuje polecenia.
  3. Eksfiltracja przez znacznik obrazu:
    Wynik zawiera zewnętrzny <img> z parametrami niosącymi zebrane dane. Podczas renderowania przeglądarka wykonuje żądanie HTTP do serwera napastnika — to boczne wyprowadzenie danych poza kontrolowane kanały. Tradycyjne narzędzia nie podnoszą alertów, bo ruch wygląda „normalnie”.
  4. Zmiany po stronie Google:
    Po zgłoszeniu Google przebudowało interakcję między Gemini Enterprise, Vertex AI Search i RAG — separując komponenty, aby ograniczyć możliwość wciągania niezaufanej treści jako instrukcji.

Praktyczne konsekwencje / ryzyko

  • Szeroki zasięg eksfiltracji: potencjalnie lata korespondencji e-mail, kompletne historie kalendarza, całe repozytoria dokumentów — wszystko, do czego ma dostęp agent.
  • Brak sygnałów ostrzegawczych: brak kliknięć, brak typowych IOC, brak alarmów DLP. Ryzyko „cichej porażki”.
  • Nowa powierzchnia ataku: AI z uprawnieniami do danych staje się wysokowartościowym pojedynczym punktem awarii.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (0–7 dni):

  1. Przegląd integracji i uprawnień Gemini Enterprise/Workspace: minimalne zakresy, ograniczenie źródeł RAG do zaufanych repozytoriów.
  2. Wymuś blokadę zewnętrznych połączeń w wynikach AI (np. filtrowanie/stripowanie <img>/zewn. URL) na warstwie proxy/CSP; rozważ blokadę zdalnego ładowania obrazów w interfejsach, które renderują odpowiedzi AI. (Wnioski z wektora <img>).
  3. Higiena treści: oznaczanie i kwarantanna artefaktów zewnętrznych (Docs/Calendar/Email) zanim trafią do indeksu AI; automatyczne reguły flagujące „niewidzialny” tekst/HTML. (Wynika z mechaniki ataku).
  4. Rotacja sekretów (API keys/hasła) i przegląd logów pod kątem anomalii żądań HTTP do nieznanych domen po akcjach AI.

Krótkoterminowo (1–4 tygodnie):

  1. Segmentacja dostępu AI („blast radius mapping”) i least privilege dla konektorów; osobne projekty/tenants dla działów o podwyższonej wrażliwości.
  2. Separacja instrukcji od dowodów w pipeline RAG (policy: „instructions-vs-evidence”); walidacja/trust score każdej pozycji kontekstu (proweniencja).
  3. Monitoring runtime pod kątem prompt-injection/exfiltracji (wzorce <img>, dane w query stringach, nienaturalne zapytania typu „confidential”, „API key”, itp.).
  4. „Human-in-the-loop” dla akcji o skutkach zewnętrznych (wysyłka wiadomości, modyfikacja danych, dostępy).

Średnioterminowo:

  1. Red teaming AI (scenariusze e-mail/chat z ukrytym HTML/CSS), testy odporności RAG i zasilanych konektorów.
  2. Polityki CSP/egress control dedykowane dla komponentów renderujących odpowiedzi AI (whitelisting domen obrazów, blokada data exfil via URL). (Wynika z wektora eksfiltracji).
  3. Rejestry proweniencji treści oraz etykietowanie zaufania (content provenance) przed włączeniem do indeksu „organizational knowledge”.

Różnice / porównania z innymi przypadkami

  • GeminiJack vs. klasyczne prompt-injection: tu użytkownik niczego nie klika i nawet nie widzi złośliwego polecenia; triggerem jest standardowe wyszukiwanie w RAG.
  • Na tle wcześniejszych odkryć (np. „Gemini Trifecta” Tenable): wspólnym mianownikiem jest możliwość przekształcenia AI w wektor ataku oraz wycieki danych wskutek błędów separacji kontekstu i uprawnień; jednak GeminiJack jest bardziej „bezklikowy” i architektoniczny, bo opiera się na federacji danych i renderowaniu odpowiedzi.

Podsumowanie / kluczowe wnioski

  • AI z dostępem do danych = nowa brama dostępu. Jeśli AI „czyta” treści, musi odróżniać instrukcje od dowodów/treści i nie wolno jej bezkrytycznie wykonywać ukrytych poleceń z artefaktów.
  • Eksfiltracja może wyglądać jak zwykłe ładowanie obrazka. Kontroluj egress i sanitację HTML w odpowiedziach AI.
  • Google zareagowało i przebudowało architekturę po zgłoszeniu (separacja VAIS od Gemini Enterprise/RAG), ale klasa ryzyka pozostaje dla wszystkich środowisk RAG/agentów.

Źródła / bibliografia

  • SecurityWeek: „Google Patches Gemini Enterprise Vulnerability Exposing Corporate Data” (10 grudnia 2025) — potwierdzenie mitigacji po stronie Google. (SecurityWeek)
  • Noma Security (Noma Labs): „Hacking Google Gemini Enterprise with an Indirect Prompt Injection / GeminiJack FAQ” — szczegóły techniczne i zalecenia. (noma.security)
  • Dark Reading: „Gemini Enterprise No-Click Flaw Exposes Sensitive Data” (9 grudnia 2025) — opis wektora i zmian architektonicznych. (Dark Reading)
  • ISMG / BankInfoSecurity: „Google Patches AI Flaw That Turned Gemini Into a Spy” (9 grudnia 2025) — mechanizm <img> i brak sygnałów w DLP. (bankinfosecurity.com)
  • (Kontekst porównawczy) Tenable Research: „The Trifecta: three new Gemini vulnerabilities…” (wrzesień 2025). (Tenable®)

Microsoft łata 57 luk (w tym 3 zero-day). Co wiemy o grudniowym Patch Tuesday 2025?

Wprowadzenie do problemu / definicja luki

Grudniowy Patch Tuesday (9 grudnia 2025) domyka rok paczką poprawek Microsoftu. Firma załatała 57 podatności, w tym trzy zero-day (jedna aktywnie wykorzystywana) — liczby te mogą się minimalnie różnić w zależności od metodologii liczenia poszczególnych serwisów (56–57 CVE). Najpoważniejsza z nich to CVE-2025-62221 w Windows Cloud Files Mini Filter Driver, która umożliwia podniesienie uprawnień do SYSTEM.

W skrócie

  • Liczba poprawek: 57 wg SecurityWeek/BleepingComputer; część analiz operuje liczbą 56 CVE (różnice w wliczaniu komponentów Chromium/Edge/Mariner).
  • Zero-day (3):
    • CVE-2025-62221 – Cloud Files Mini Filter (EoP), aktywnie wykorzystywana.
    • CVE-2025-64671 – GitHub Copilot for JetBrains (RCE), publicznie ujawniona.
    • CVE-2025-54100 – PowerShell (RCE/command injection), publicznie ujawniona.
  • Najwięcej klas: podniesienie uprawnień (EoP) oraz RCE (w tym Office/Outlook).

Kontekst / historia / powiązania

Końcówka 2025 r. stoi pod znakiem licznych EoP po stronie Windows oraz rosnącej liczby błędów w ekosystemie narzędzi AI/IDE (przykład: Copilot dla JetBrains z podatnością na cross-prompt injection prowadzącą do command injection). Trend ten był sygnalizowany w analizach ZDI oraz mediów branżowych przez cały rok.

Analiza techniczna / szczegóły luki

1) CVE-2025-62221 – Windows Cloud Files Mini Filter Driver (EoP)

  • Typ: Use-After-Free w sterowniku mini-filtra Cloud Files.
  • Skutek: lokalne podniesienie uprawnień do SYSTEM; idealny łącznik w łańcuchach RCE→EoP.
  • Status: aktywnie wykorzystywana na wolności; brak szczegółów TTP od Microsoftu.

Dodatkowo Microsoft załatał pokrewne EoP w tym samym komponencie (np. CVE-2025-62454), które są „likely to be exploited”. Wskazuje to na szerszą klasę błędów w Cloud Files.

2) CVE-2025-64671 – GitHub Copilot for JetBrains (RCE)

  • Przyczyna: command injection wyzwalany m.in. przez cross-prompt injection w nieufnych plikach lub serwerach MCP; możliwe do wykorzystania lokalnie, ale realnie z wektorem socjotechnicznym.

3) CVE-2025-54100 – PowerShell (RCE)

  • Przyczyna: nieprawidłowa neutralizacja danych z sieci; Invoke-WebRequest mógł wykonywać skrypt osadzony w pobieranej stronie.
  • Zmiana: dodano ostrzeżenie i rekomendację użycia -UseBasicParsing.

Office/Outlook i inne komponenty

  • Office RCE: m.in. CVE-2025-62554 i CVE-2025-62557 (wektor Preview Pane).
  • Outlook RCE: CVE-2025-62562, w specyficznych warunkach oceniona jako krytyczna.
  • Azure/AMA, RRAS, ReFS: poprawki obejmują też AMA (RCE), RRAS (RCE/Info Disclosure) i ReFS (RCE).

Praktyczne konsekwencje / ryzyko

  • Eskalacja uprawnień (zwłaszcza przez CVE-2025-62221) znacząco obniża barierę przejścia z początkowego footholda (np. makro, złośliwy skrót .LNK, exploit w przeglądarce) do pełnej kompromitacji hosta.
  • Łańcuchy z AI/IDE: błąd w Copilot for JetBrains pokazuje, że prompt injection może być punktem wejścia do command injection w lokalnym środowisku deweloperskim.
  • PowerShell jako narzędzie ofensywne: podatność łączy się z powszechnymi TTP (living-off-the-land), zwiększając ryzyko „cichego” wykonania kodu podczas automatyzacji/parsingu treści web.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytetyzuj wdrożenie poprawek dla Windows/Office oraz CVE-2025-62221 (Cloud Files), CVE-2025-64671 (Copilot for JetBrains) i CVE-2025-54100 (PowerShell).
  2. Stacje deweloperskie:
    • Wyłącz auto-approve komend w terminalu IDE.
    • Ogranicz zaufanie do plików/serwerów MCP; egzekwuj polityki „trusted workspace”.
  3. PowerShell hardening:
    • Wymuś Constrained Language Mode tam, gdzie to możliwe; monitoruj użycie Invoke-WebRequest i wymagaj -UseBasicParsing.
    • Zbieraj i koreluj logi Script Block/Module Logging.
  4. Higiena Windows:
    • Włącz Attack Surface Reduction (ASR), Credential Guard i bieżące reguły Defendera.
    • Segmentuj uprawnienia administratorów lokalnych, minimalizuj konta z prawami instalacji sterowników/filtrów. (Wnioski zgodne z analizami ZDI/DR dot. przewagi EoP).
  5. Office/Outlook:
    • Ogranicz Preview Pane i zablokuj automatyczne przetwarzanie zawartości zewnętrznej.
    • Wdróż reguły transportowe DLP/AV dla załączników typowych w atakach socjotechnicznych.

Różnice / porównania z innymi przypadkami

  • Rozbieżność 56 vs 57 CVE: Tenable/ZDI wskazują 56 (bez części elementów Chromium/Edge/Mariner), podczas gdy media (SecurityWeek/BleepingComputer/Dark Reading) raportują 57 – to różnica metodologiczna, nie merytoryczna. Ważniejsze są trzy zero-day i ich priorytety.
  • Kontynuacja trendu: podobnie jak w poprzednich miesiącach, dominują EoP i komponenty Office/Outlook; październik/listopad również zawierały głośne luki łączone w łańcuchy ataków.

Podsumowanie / kluczowe wnioski

  • Patch now: załataj CVE-2025-62221 (aktywnie wykorzystywana), CVE-2025-64671 (Copilot/JetBrains) i CVE-2025-54100 (PowerShell).
  • Zadbaj o stacje dev i PowerShell: wyłącz automaty, które mogą „dokleić” komendy; loguj i ograniczaj PowerShell.
  • Traktuj EoP jako „must-fix”: to spoiwo dla większości udanych łańcuchów ataku w Windows w 2025 r.

Źródła / bibliografia

  • SecurityWeek: „Microsoft Patches 57 Vulnerabilities, Three Zero-Days” (09.12.2025). (SecurityWeek)
  • BleepingComputer: „Microsoft December 2025 Patch Tuesday fixes 3 zero-days, 57 flaws” (09.12.2025). (BleepingComputer)
  • Trend Micro ZDI: „The December 2025 Security Update Review” (09.12.2025). (zerodayinitiative.com)
  • Tenable: „Microsoft’s December 2025 Patch Tuesday Addresses 56 CVEs” (09.12.2025). (Tenable®)
  • Dark Reading: „Microsoft Fixes Exploited Zero Day in Light Patch Tuesday” (09.12.2025). (Dark Reading)

LG Uplus: wyciek danych z aplikacji głosowej ixi-O po błędzie cache. Co dokładnie się stało i jak się zabezpieczyć?

Wprowadzenie do problemu / definicja luki

LG Uplus (LG U+), jeden z największych operatorów telekomunikacyjnych w Korei Południowej, zgłosił incydent naruszenia poufności danych w swojej aplikacji do połączeń głosowych z funkcjami AI — ixi-O. Błąd w konfiguracji cache spowodował tymczasowe ujawnienie fragmentów danych połączeń 36 użytkowników innym osobom korzystającym z aplikacji. Według spółki, nie był to atak hakerski, lecz błąd techniczny wykryty i usunięty po około kilkunastu godzinach.

W skrócie

  • Skala: dane 36 użytkowników ujawnione 101 innym osobom; czas ekspozycji: 2 grudnia, ok. 20:00 – 3 grudnia, 10:59 (czasu KST).
  • Zakres danych: numery telefonów odbiorców, znaczniki czasu rozmów, skróty/summary rozmów generowane przez AI (voice-to-text/ASR + podsumowanie). Brak ekspozycji PESEL-owych odpowiedników, danych finansowych itp.
  • Przyczyna: błąd konfiguracji cache wdrożony podczas aktualizacji usługi (service improvement).
  • Zgłoszenie: do koreańskiego organu ochrony danych PIPC w sobotę, 6 grudnia.
  • Aplikacja ixi-O: asystent rozmów z rozpoznawaniem mowy w czasie rzeczywistym i automatycznymi podsumowaniami; szerzej promowany od listopada 2025 r.

Kontekst / historia / powiązania

Incydent wpisuje się w serię głośnych naruszeń w koreańskim sektorze telco i e-commerce w 2025 r. Jesienią LG Uplus przyznał się do osobnego zdarzenia bezpieczeństwa (wtedy o charakterze cyberataku) — po wcześniejszych atakach na SK Telecom i KT. Regulatorzy nałożyli kary i zobowiązania naprawcze na operatorów, a rynek pozostaje wyczulony na każdy kolejny incydent.

Równolegle Korea mierzy się z dużą aferą wycieku danych w Coupang (33,7 mln kont), co podbija presję społeczną i regulacyjną na branżę w zakresie zarządzania ryzykiem i przejrzystości komunikacji.

Analiza techniczna / szczegóły luki

Z dostępnych komunikatów wynika, że do ujawnienia doszło w następstwie zmiany konfiguracji cache podczas aktualizacji usługi ixi-O. Skutkiem była błędna kanonikalizacja/segmentacja kluczy cache powiązanych z sesją użytkownika lub identyfikatorem zasobu (np. rekordów rozmowy), co doprowadziło do niewłaściwego współdzielenia odpowiedzi między użytkownikami, zwłaszcza tymi, którzy instalowali lub reinstalowali aplikację w oknie czasowym incydentu. Ekspozycja objęła m.in. numery odbiorców, znaczniki czasu i streszczenia rozmów – czyli wrażliwe metadane/treści konwersacyjne przetwarzane przez pipeline ASR+NLP.

Warto podkreślić, że według LG Uplus nie stwierdzono ingerencji zewnętrznej (hackingu), a problem miał charakter błędu wdrożeniowego (misconfiguration) usuniętego po identyfikacji źródła. Czas wykrycia (ok. 10:00, 3 grudnia) sugeruje działanie wewnętrznych mechanizmów monitoringu lub zgłoszenia użytkowników.

Praktyczne konsekwencje / ryzyko

  • Ryzyko wtórnej identyfikacji i nadużyć: fragmenty treści i metadane rozmów (kto, kiedy, do kogo) mogą umożliwić profilowanie relacji lub kontekstu biznesowego/medycznego.
  • Ryzyko prawne: potencjalna ocena naruszenia przez PIPC, obowiązki powiadomienia osób i wdrożenia środków zapobiegawczych (co firma deklaruje, że realizuje).
  • Ryzyko reputacyjne: ixi-O to produkt promowany jako innowacyjny (ASR + podsumowania). Ujawnienie treściowych elementów rozmów uderza bezpośrednio w zaufanie do funkcji AI w kanałach voice.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników ixi-O / klientów LG U+

  1. Sprawdź komunikat od LG U+ (SMS/telefon) i w razie objęcia incydentem zażądaj szczegółów: zakres, czas, działania naprawcze.
  2. Przejrzyj historię połączeń i logi aplikacji (jeśli dostępne). Usuń zbędne zapisy, rozważ zmianę ustawień prywatności i retencji.
  3. Ostrożnie z phishingiem podszywającym się pod LG U+ i „rekompensaty” (trend obserwowany po głośnych wyciekach jak Coupang).

Dla zespołów technicznych (praktyki „blame-aware”)

  1. Twarde izolowanie cache per-tenant/per-user: klucze z przestrzeniami nazw (namespaces), tokenizacja sesji, konsekwentny cache busting po deployu.
  2. Pre-deployment „safety net”: circuit breaker na funkcje zwracające dane wrażliwe, shadow traffic i testy kanarkowe z walidacją, czy odpowiedzi nie „krzyżują się” między kontami.
  3. WAF + DLP na warstwie API: detekcja anomalii w polach odpowiedzi (np. NFA na numerach MSISDN), blokada odpowiedzi zawierających identyfikatory niezgodne z kontekstem żądania.
  4. Zgodność z privacy-by-design: minimalizacja danych w odpowiedzi (np. maskowanie MSISDN), szyfrowanie w spoczynku i w tranzycie, krótkie TTL cache dla danych konwersacyjnych.
  5. Runbook „AI voice”: osobny DPIA i testy prompt injection/ASR hallucinations nie zastąpią testów integralności strumienia danych — potrzebne metryki spójności i integralności indeksów nagrań/tekstów.

Różnice / porównania z innymi przypadkami

  • Błąd konfiguracji vs. atak zewnętrzny: ixi-O — błąd cache przy aktualizacji; wcześniejsze przypadki w telekomach (SKT/KT/jesienne LG U+) miały charakter celowanych cyberataków i zakończyły się karami/regulacyjnymi nakazami.
  • Skala: tu — 36 osób i 101 nieuprawnionych podglądów; w innych głośnych sprawach — miliony rekordów (np. Coupang 33,7 mln).
  • Dane treściowe vs. identyfikatory: ekspozycja skrótów rozmów i metadanych (wrażliwe kontekstowo) może być groźniejsza niż „same” dane kontaktowe — bo ujawnia charakter interakcji.

Podsumowanie / kluczowe wnioski

  • Źródłem incydentu ixi-O był błąd cache w trakcie aktualizacji, nie atak.
  • Ujawniono metadane i treściowe podsumowania rozmów 36 osób — to wrażliwy zakres na poziomie prywatności.
  • W świetle serii naruszeń w koreańskim telco i e-commerce, „higiena wdrożeń” (deploy safety) i izolacja cache muszą stać się kontrolami pierwszej kategorii.
  • Firmy korzystające z ASR/NLP w czasie rzeczywistym powinny wdrożyć dodatkowe testy integralności strumienia danych i mechanizmy fail-closed podczas release’ów.

Źródła / bibliografia

  1. The Korea Times: „Call data of 36 users on LG Uplus’ AI call app leaked…”, szczegóły czasu, zakresu i zgłoszenia do PIPC. (The Korea Times)
  2. Korea JoongAng Daily: „LG U+ reports leak of 36 users’ call data over technical error”, potwierdzenie przyczyny (cache) i liczby użytkowników. (Korea Joongang Daily)
  3. The Chosun (EN): „LG Uplus Reports AI Call App Data Leak”, streszczenie i liczby. (조선일보)
  4. The Korea Herald: kontekst produktu ixi-O (funkcje ASR i podsumowania). (Korea Herald)
  5. Reuters: tło regulacyjne/rynkowe po incydentach w telco i Coupang (kary, skala). (Reuters)

Bliźniacy z Virginii aresztowani za skasowanie ~96 rządowych baz FOIA. Co wiemy i jak się przed tym bronić

Wprowadzenie do problemu / definicja luki

3–4 grudnia 2025 r. w stanie Wirginia aresztowano braci bliźniaków, Muneeba i Sohaiba Akhterów (34 l.), którym zarzucono nadużycie uprawnień wykonawcy federalnego do skasowania ok. 96 baz danych z informacjami rządowymi – m.in. rejestrów wniosków FOIA (Freedom of Information Act) oraz danych śledczych kilku agencji. Według Departamentu Sprawiedliwości, do incydentu miało dojść w lutym 2025 r., a zatrzymania dokonano 3 grudnia.

W skrócie

  • Typ zdarzenia: sabotaż/insider threat po stronie podwykonawcy (byli/zwalniani pracownicy).
  • Skala: ~96 baz danych związanych z obsługą FOIA i sprawami śledczymi (w tym systemy powiązane z DHS).
  • Wektor: pozostawione aktywne konto i uprawnienia po rozmowie HR dot. zakończenia współpracy.
  • Maskowanie śladów: zapytania do narzędzia AI o instrukcje czyszczenia logów (SQL Server/Windows).
  • Tło sprawców: wcześniejsze wyroki za włamania (2015 r., m.in. Departament Stanu).

Kontekst / historia / powiązania

Akhterowie byli już wcześniej skazani w 2015 r. za spiskowanie w celu uzyskania nieautoryzowanego dostępu do systemów rządowych i prywatnych. Mimo tej historii mieli pracować przy kontrakcie federalnym; według relacji prasowych działania destrukcyjne nastąpiły tuż po zakomunikowaniu im przez HR zakończenia współpracy, gdy dostęp nie został natychmiast wyłączony. Sprawa unaocznia klasyczny problem offboardingu w ekosystemie wykonawców i podwykonawców administracji publicznej.

Analiza techniczna / szczegóły luki

Publicznie dostępne dokumenty i relacje wskazują na następujące elementy techniczne:

  • Uprawnienia i tożsamość: wykorzystanie niewycofanego konta oraz nadanych wcześniej ról/permission sets do ingerencji w produkcyjne instancje baz danych. Wątek ten pada w materiałach prasowych i streszczeniach akt sprawy.
  • Zakres szkód: usunięto ~96 baz (SQL) związanych z FOIA i sprawami dochodzeniowymi; co najmniej jedna baza należała do środowiska związanego z DHS.
  • Antyforensics: w minutę po skasowaniu jednej z baz (DHS) padło zapytanie do narzędzia AI o czyszczenie logów SQL Server/Windows Server 2012, co może świadczyć o próbie utrudnienia dochodzenia (time correlation).
  • Łańcuch zdarzeń: według DOJ – nadużycie pozycji wykonawcy federalnego, kradzież/wyprowadzenie danych i sabotaż systemów w lutym 2025 r.; aresztowania 3 grudnia, akt oskarżenia ogłoszony 4 grudnia.

Praktyczne konsekwencje / ryzyko

  • Dostępność i przejrzystość państwa: utrata/zakłócenie obsługi wniosków FOIA wpływa na jawność życia publicznego i terminowość odpowiedzi organów.
  • Ryzyko prawne i zgodność: potencjalne naruszenie przepisów dot. przechowywania dokumentacji publicznej, retencji danych i łańcucha dowodowego (agencje śledcze).
  • Koszty odtworzenia: przy RPO/RTO > 0 może dojść do utraty danych między backupami, długich przestojów oraz konieczności ręcznego odtworzenia rekordów. (Wniosek analityczny na bazie opisanej skali kasacji).
  • Reputacja i zaufanie: sabotaż dokonany przez wykonawcę podważa zaufanie do całego łańcucha dostaw IT w sektorze publicznym.

Rekomendacje operacyjne / co zrobić teraz

Dla instytucji publicznych i wykonawców:

  1. Zero-delay offboarding: automatyczne, atomowe odebranie dostępu (IdP/PAM/DB) w trakcie rozmowy offboardingowej; “break glass” tylko z rejestracją i zgodą 4-oczu.
  2. Zasada najmniejszych uprawnień + JIT: role time-boxed, dostępy Just-In-Time do środowisk prod, bound by ticket.
  3. Kontrola zmian w DB: egzekwowanie DDL/DML przez change data capture, database activity monitoring (DAM), wymóg trybu SAFE/DRY RUN dla destrukcyjnych poleceń i approval gates dla DROP DATABASE.
  4. Backupy niezmienialne: kopie immutable/WORM (S3 Object Lock, Azure Immutable Blob) + air-gap; regularne testy przywracania (game days) i wskaźniki RPO/RTO na poziomie wymagań FOIA.
  5. Detekcja antyforensics: reguły SIEM/EDR na wzorce „czyszczenia logów” wkrótce po operacjach DDL/DROP; korelacja czasowa z IdP (login), CMDB i HRMS (status pracownika).
  6. Segregacja obowiązków: osobne konta do administrowania, osobne do pracy deweloperskiej; MFA hardware dla kont uprzywilejowanych; rotacja tajemnic (PAM) po każdym zdarzeniu HR.
  7. Kontrakty i due diligence: weryfikacja dostawców (background checks), clause’y o natychmiastowej deprowizji i karach umownych; audyty uprawnień kwartalnie.
  8. Kill switch w środowisku DB: polityki, które automatycznie blokują destrukcyjne operacje, gdy status pracownika = „terminated” w HRMS.

Dla zespołów PR/FOIA/Legal: przygotujcie plan ręcznego odtwarzania rekordów FOIA z kopii offline i logów transakcyjnych; komunikaty dla wnioskodawców dot. możliwych opóźnień.

Różnice / porównania z innymi przypadkami

  • Insider vs. APT: w przeciwieństwie do ataków APT, tu wektor to legalny dostęp wykonawcy (insider). Skuteczność obrony zależy więc bardziej od governance i procesów HR/IdP niż od klasycznej detekcji perymetrycznej.
  • Motyw sabotażu po offboardingu: schemat podobny do innych incydentów „last-day sabotage”, ale rzadko spotyka się tak dużą liczbę skasowanych baz w sektorze publicznym. (Wniosek na bazie przeglądu sprawy i relacji prasowych).

Podsumowanie / kluczowe wnioski

  • Kluczowe było opóźnienie w deprowizji dostępu po rozmowie HR – to wystarczyło, by w krótkim czasie skasować dziesiątki baz krytycznych dla przejrzystości państwa (FOIA) i działań śledczych.
  • Próba maskowania śladów z użyciem narzędzi AI to dziś realny pattern antyforensics – warto mieć na to gotowe reguły detekcyjne.
  • Silne procesy offboardingu, PAM, immutable backupy i automatyka w IdP to najskuteczniejsze „tarcze” na podobne przypadki.

Źródła / bibliografia

  • U.S. Department of Justice – komunikat o aresztowaniu (3–4 grudnia 2025 r.). (Department of Justice)
  • The Record (Recorded Future News): „Virginia brothers charged with hacking, deleting federal databases holding FOIA info” (4 grudnia 2025 r.). (The Record from Recorded Future)
  • CyberScoop: „Twins with hacking history charged in insider data breach…” (3 grudnia 2025 r.). (CyberScoop)
  • BleepingComputer: „Contractors with hacking records accused of wiping 96 govt databases” (4 grudnia 2025 r.). (BleepingComputer)
  • Axios: „Virginia brothers arrested for allegedly tampering with government databases” (3 grudnia 2025 r.). (Axios)

Fałszywe zaproszenia „Calendly” podszywają się pod topowe marki. Celem: przejęcie kont menedżerów reklam (Google Ads/Facebook)

Wprowadzenie do problemu / definicja luki

Trwa ukierunkowana kampania phishingowa wykorzystująca fałszywe zaproszenia do spotkań w stylu Calendly, która podszywa się pod rozpoznawalne marki (m.in. LVMH, Lego, Mastercard, Uber, Unilever, Disney). Atak ma na celu kradzież sesji i haseł do Google Workspace oraz przejęcie kont menedżerów reklam (Google Ads MCC) i/lub Facebook Business — co umożliwia szybkie uruchamianie malvertisingu i dalsze łańcuchy ataków. Kampanię jako pierwsi rozebrali badacze Push Security; szczegóły opisał też BleepingComputer.

W skrócie

  • Wejście w relację: przestępcy zaczynają od profesjonalnie przygotowanego wątku rekrutacyjnego (podszycie pod realnego pracownika), dopiero potem wysyłają link do „umówienia rozmowy” (fałszywy Calendly).
  • Kradzież sesji: po CAPTCHA ofiara trafia na AiTM (Attacker-in-the-Middle) lub wariant Browser-in-the-Browser (BitB), który wyłudza dane/ciasteczka logowania do Google/Facebooka i obchodzi 2FA.
  • Cel finansowy i zasięgowy: przejęte MCC daje kontrolę nad wieloma kontami klientów i budżetami — idealne do malvertisingu i „watering hole” z precyzyjnym targetowaniem.
  • Obserwowane TTPs: blokady VPN/proxy, blokowanie DevTools, parametryzacja pod domenę ofiary, rotacja dziesiątek URL-i, hosting na Odoo/Kartra.

Kontekst / historia / powiązania

Wykorzystywanie legalnych usług (calendaring, formularze, SaaS) w phishingu nie jest nowe; podobne wektory z Calendly raportowano już wcześniej. Nowością jest skala podszywania pod marki i skupienie na ekosystemach reklamowych (MCC/Business Manager), co współgra z równoległymi kampaniami malvertisingu obserwowanymi przez Push Security w Google Search.

Analiza techniczna / szczegóły luki

Łańcuch ataku:

  1. Mail „od rekrutera” znanej marki → 2) „Zaproszenie Calendly” → 3) CAPTCHA → 4) AiTM strona logowania (Google/Facebook) → 5) przechwycenie sesji i eskalacja do kont reklamowych. W nowszych próbkach użyto BitB (fałszywe okno logowania, które sprawia wrażenie prawdziwego, wraz z „prawdziwym” URL-em w pasku pop-upu).

Techniki anty-analizy:

  • whitelisting domen e-mail ofiary (zablokowanie funkcji dla „nieautoryzowanych” domen),
  • blokowanie ruchu z VPN/proxy,
  • blokowanie otwarcia DevTools,
  • szybkie gaszenie i rotacja hostów (Odoo/Kartra).

Dlaczego BitB jest skuteczny: imituje natywne okno logowania (SSO) w przeglądarce, przez co ofiara często ufa wyglądowi i nie weryfikuje rzeczywistego origin/URL. (Patrz: materiały wyjaśniające BitB).

Praktyczne konsekwencje / ryzyko

  • Spalenie budżetów reklamowych w godziny, utrata dostępu do kont klientów/agencji, zły PR i chargebacki.
  • Malvertising w skali (precyzyjne targetowanie po kraju, domenie, urządzeniu) — „watering hole” do AiTM/malware/ClickFix.
  • Ryzyko wtórne: jeśli Google Workspace pełni rolę IdP/SSO, kompromitacja konta reklamowego może być trampoliną do danych i aplikacji całej organizacji.

Rekomendacje operacyjne / co zrobić teraz

Google Ads (MCC)

  • Włącz powiadomienia/alerty w Manager Account (np. gdy dodawane jest nowe konto/UZ), monitoruj nietypowe linkowania, ustaw reguły SIEM/SOAR na te zdarzenia.
  • Wymuś klucze sprzętowe (FIDO2/WebAuthn) dla kont o wysokiej wartości; AiTM obchodzi kody 2FA, ale hardware keys znacząco podnoszą poprzeczkę. (Rekomendacja także w materiałach branżowych).
  • Zasada „tylko z zakładek”: dostęp do Ads/Business Managera wyłącznie z firmowych zakładek/SSO portal, nigdy z reklamy czy wyników wyszukiwania. Blokuj sponsorowane wyniki dla słów typu „google ads login”.
  • Least privilege: zrewiduj role w MCC/Business Manager, włącz zatwierdzanie dodawania użytkowników/kont, logi zmian i dzienniki rozliczeń.

Higiena przeglądarki i hardening

  • Wykrywaj BitB/AiTM: szkolenia (przeciągnij okno pop-upu do krawędzi — jeśli to wciąż „wewnątrz karty”, to BitB), egzekwuj pokazywanie pełnych URL/origin, ostrzegaj przed pop-upami logowania w „nieoczekiwanych” domenach.
  • EDR/rozszerzenia bezpieczeństwa z detekcją anomalii w DOM i blokadą złośliwych skryptów; polityki blokujące uruchamianie DevTools nie powinny wyłączać telemetrii bezpieczeństwa.
  • Zasady sieciowe: blokuj kategorie hostingu współdzielonego używane w kampanii (np. Odoo/Kartra) jeśli nieużywane biznesowo; w przeciwnym razie — sandbox/isolated browsing.

Procesy SOC/IR

  • Playbook „MCC takeover”: natychmiastowe wylogowanie wszystkich sesji, reset kluczy/2FA, weryfikacja metod płatności, przegląd delegacji i linkowań kont, pauza wszystkich kampanii do czasu oceny szkód.
  • Threat hunting: szukaj świeżych logowań z nieznanych AS, nagłych zmian w kampaniach/limitach, dodanych użytkowników/aplikacji OAuth. (Push Security wskazuje, że IoC-based detections są tu mało skuteczne — liczy się TTP/behaviour).

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

W porównaniu z „zwykłym” phishingiem na konta reklamowe, obecna kampania:

  • Mocniej personalizuje socjotechnikę (podszycie pod konkretnego rekrutera, wieloetapowa rozmowa).
  • Używa AiTM/BitB do ominięcia 2FA i przejęcia sesji, a nie tylko hasła.
  • Łączy wektor e-mail (Calendly) z malvertisingiem w Google Search, co poszerza lejek ofiar.

Podsumowanie / kluczowe wnioski

  • To nie „kolejny” kalendarzowy phish — to spięcie socjotechniki z nowoczesnymi TTP (AiTM/BitB), ukierunkowane na kontrolę nad budżetami reklamowymi i zasięgami.
  • Agencje i działy performance powinny traktować konta MCC/Business Manager jak kontrolowane uprzywilejowane — z hardware MFA, alertami i ciągłym nadzorem zmian.
  • Zasada zero zaufania dla linków do logowania: tylko zakładki lub wewnętrzny portal SSO.

Bonus: mini-checklista dla SOC/IT (do wdrożenia dziś)

  • Wymuś FIDO2 na wszystkich kontach MCC/Business Manager.
  • Skonfiguruj alerty MCC i reguły w SIEM (dodanie konta, nowy user, zmiany płatności).
  • Zablokuj sponsorowane wyniki dla „login” w przeglądarkach firmowych/DNS.
  • Przeprowadź szkolenie BitB + procedurę „przeciągnij pop-up do krawędzi”.
  • Dodaj kontrolę odcięcia sesji i resetu 2FA dla incydentów Ads/Business.

Źródła / bibliografia

  1. BleepingComputer — „Fake Calendly invites spoof top brands to hijack ad manager accounts”, 2 grudnia 2025. (BleepingComputer)
  2. Push Security — „Uncovering a Calendly-themed phishing campaign targeting business ad manager accounts”, 2 grudnia 2025. (Push Security)
  3. Push Security — „Analysing a malvertising attack targeting business Google accounts”, 2 grudnia 2025. (Push Security)
  4. Google Ads Help — „About notifications in manager accounts (MCC)”. (Google Help)
  5. Bolster — „Browser-in-the-Browser (BitB) phishing attacks — wyjaśnienie”. (Bolster AI)