Archiwa: SIEM - Strona 45 z 61

Microsoft ostrzega: agentowe funkcje AI w Windows 11 wprowadzają nowe ryzyka bezpieczeństwa

Wprowadzenie do problemu / definicja luki

Microsoft rozpoczął testy eksperymentalnych funkcji agentowych w Windows 11 (m.in. agent workspace i Copilot Actions). Firma jednocześnie ostrzega, że nieprawidłowe zabezpieczenie agentów może przynieść więcej szkód niż korzyści—w tym eksfiltrację danych i instalację złośliwego oprogramowania. Funkcje te są wyłączone domyślnie i przeznaczone dla świadomych ryzyk użytkowników/administratorów.

W skrócie

Agent workspace to odizolowana przestrzeń systemowa, w której agent działa na własnym koncie i z ograniczonym dostępem do plików/aplikacji; dostęp rozszerzany jest wyłącznie za zgodą użytkownika.
Najistotniejsze nowe wektory to cross-prompt injection (XPIA), błędy uprawnień oraz brak containmentu działań agenta. Microsoft definiuje zasady bezpieczeństwa i prywatności (m.in. least privilege, nadzór i audyt niepodważalny) jako warunek korzystania z funkcji.
Copilot Actions zaczęło trafiać do Windows Insiders 17 listopada 2025 r. i korzysta z agent workspace do działań na lokalnych plikach.
Windows wzmacnia także warstwę protokołu Model Context Protocol (MCP)—z kontrolami proxy, autoryzacją narzędzi i wymogiem podpisu kodu—aby ograniczać ryzyka agentów i „tool poisoning”.

Kontekst / historia / powiązania

Artykuł SecurityWeek z 24 listopada 2025 r. podsumowuje komunikaty Microsoftu: agent workspace działa w osobnej sesji Windows równolegle do sesji użytkownika, a włączenie funkcji tworzy konta agentów i umożliwia aplikacjom agentowym (np. Copilot) żądanie dostępu do folderów użytkownika (Dokumenty, Pobrane, Pulpit, Muzyka, Obrazy, Wideo).
Dokumentacja Microsoftu (zaktualizowana 17–18 listopada 2025 r.) rozwija zasady bezpieczeństwa, transparentności i kontroli użytkownika, a wpis na Windows Insider Blog potwierdza stopniowy rollout Copilot Actions w kanale Insider.
Równolegle, w maju 2025 r. Microsoft ogłosił wzmacnianie MCP jako warstwy interoperacyjnej dla agentów—z akcentem na proxy egzekwujące polityki, audyt i centralny rejestr serwerów MCP spełniających kryteria bezpieczeństwa.

Analiza techniczna / szczegóły luki

Izolacja i tożsamość

Każdy agent działa na oddzielnym koncie standardowym; umożliwia to odrębne polityki i jasne granice uprawnień. Działania agenta są odróżnialne od działań użytkownika.
Agent workspace to „lekka” sesja równoległa, zapewniająca runtime isolation i ograniczoną widoczność pulpitu użytkownika; efektywniejsza niż pełna maszyna wirtualna, ale oparta o uznane granice bezpieczeństwa Windows.

Uprawnienia i dostęp do danych

Dostęp do plików jest grantowany explicite; początkowo agent może sięgać tylko do znanych folderów użytkownika i zasobów dostępnych dla wszystkich kont. Rozszerzenia wymagają autoryzacji.

Nadzór i audyt

Microsoft wymaga możliwości nadzoru planu i kroków agenta, dodatkowych potwierdzeń przy wrażliwych operacjach oraz logów odpornych na manipulacje (tamper-evident audit log).

Nowe wektory ataku (przykłady)

Cross-Prompt Injection (XPIA): złośliwa treść w dokumentach/elementach UI może nadpisać instrukcje agenta i skutkować np. eksfiltracją danych lub instalacją malware.
Tool/MCP poisoning i luki autoryzacji: niezweryfikowane serwery MCP, słabe uwierzytelnienie lub wycieki poświadczeń agenta mogą prowadzić do przejęcia pełnej kontroli (RCE) przez błędnie zdefiniowane narzędzia.

Praktyczne konsekwencje / ryzyko

Dla SOC/Blue Team oznacza to nową klasę „użytkowników nie-ludzkich” działających w systemie i wykonujących akcje na danych lokalnych, aplikacjach i usługach. Błędy konfiguracji (zbyt szerokie uprawnienia), brak audytu lub brak rozdzielenia tożsamości mogą umożliwić:

eskalację uprawnień przez agenta lub jego narzędzia,
nieautoryzowany dostęp do danych wrażliwych i ich wypływ,
trwałą persystencję i lateral movement w sieci przez łańcuch agent → narzędzie → aplikacja.
Ryzyka te Microsoft samodzielnie wymienia jako kluczowe i adresuje mechanizmami least-privilege, kontroli użytkownika i izolacji w Windows 11.

Rekomendacje operacyjne / co zrobić teraz

Włączaj funkcje agentowe tylko celowo (domyślnie są wyłączone). Zanim włączysz „Experimental agentic features”, zdefiniuj scopingi uprawnień i ownera agenta.
Tożsamość i dostęp
- Traktuj konta agentów jak konta techniczne: least-privilege, brak praw admina, TTL dla przyznanych dostępów, regularny przegląd ACL.
Segmentacja i hardening
- Ogranicz dostęp agent workspace do minimalnego zestawu folderów/aplikacji; rozważ aplikacje instalowane „per-user”, by nie dziedziczyły ich wszystkie konta.
Nadzór i audyt
- Wymuś HITL dla wrażliwych operacji; integruj logi agenta z SIEM; ustaw alerty na działania wysokiego ryzyka (masowe kopiowanie/archiwizacje, instalacje binariów, modyfikacje polityk).
Higiena treści i XPIA
- Skany i sanitizacja otwieranych przez agentów dokumentów/stron; ogranicz automatyczne wykonywanie „planów” na treściach pochodzących z niezaufanych źródeł. (Microsoft podkreśla XPIA jako zagrożenie nr 1 dla agentów).
Łańcuch narzędzi (MCP)
- Dopuszczaj wyłącznie podpisane i zweryfikowane serwery MCP; egzekwuj autoryzację client–tool i rejestrowanie akcji przez warstwę proxy. Unikaj „dzikich” narzędzi bez deklaracji uprawnień.
Testy bezpieczeństwa
- Zaplanuj red teaming agentów: scenariusze XPIA, „tool poisoning”, wycieki tokenów; testuj przechwytywanie i weryfikację działań przez audyt.

Różnice / porównania z innymi przypadkami

W porównaniu z klasycznymi asystentami (bez zdolności działania w systemie) oraz z automatyzacjami typu RPA, agenci Windows:

działają bliżej powierzchni ataku endpointu (klikają, piszą, przewijają jak użytkownik),
operują w osobnej sesji i na odrębnym koncie (co daje lepszy containment niż typowe uruchamianie pod kontem użytkownika),
wspierają centralne zasady (proxy MCP, podpis kodu, rejestr serwerów), co zbliża je do modeli „zero trust” dla narzędzi.

Podsumowanie / kluczowe wnioski

Agentowe AI w Windows 11 to duży skok funkcjonalny—i równie duży skok ryzyka.
Microsoft dostarcza ramy bezpieczeństwa: izolacja sesji, osobne konta, least-privilege, autoryzacja, audyt—ale konfiguracja i governance pozostają po stronie organizacji.
Kluczem jest świadome włączenie funkcji, ścisłe scope’owanie uprawnień, monitoring i testy ofensywne pod kątem XPIA i łańcucha narzędzi.

Źródła / bibliografia

SecurityWeek — Microsoft Highlights Security Risks Introduced by New Agentic AI Feature (24 listopada 2025). (SecurityWeek)
Microsoft Support — Experimental Agentic Features (akt. 17 listopada 2025). (Microsoft Support)
Microsoft Learn — Securing AI agents on Windows (akt. 18 listopada 2025). (Microsoft Learn)
Windows Experience Blog — Securing the Model Context Protocol (19 maja 2025). (Windows Blog)
Windows Insider Blog — Copilot Actions begins rolling out to Windows Insiders (17 listopada 2025). (Windows Blog)

WhatsApp: luka w API pozwoliła zeskrobać 3,5 mld kont. Co to oznacza dla prywatności?

Wprowadzenie do problemu / definicja luki

Zespół badawczy z Uniwersytetu Wiedeńskiego wykazał, że mechanizm contact discovery w WhatsApp (czyli sprawdzanie, czy dany numer jest zarejestrowany) można było automatycznie „odpytywać” na masową skalę, bez skutecznych limitów zapytań. To umożliwiło enumerację numerów i zbudowanie katalogu ok. 3,5 mld kont wraz z publicznie dostępnymi metadanymi profili (np. zdjęcie, opis „O mnie”, znacznik konta firmowego). Meta (właściciel WhatsAppa) po zgłoszeniu wprowadziła dodatkowe ograniczenia tempa zapytań (rate limiting).

W skrócie

Zakres: możliwa enumeracja ~3,5 mld numerów powiązanych z kontami WhatsApp i pobranie publicznych danych profili.
Wektor: nadużycie funkcji contact discovery przez automatyczne testowanie dużych zakresów numerów (brak skutecznego rate limiting).
Status naprawy: Meta wdrożyła dodatkowe zabezpieczenia po zgłoszeniu badaczy.
E2EE: Szyfrowanie wiadomości end-to-end nie zostało złamane, ale ekspozycja numerów i metadanych zwiększa ryzyko nadużyć (phishing, doxing, OSINT).

Kontekst / historia / powiązania

Enumeracja poprzez „sprawdzanie dostępności” numeru to znany problem projektowy w aplikacjach opartych o telefon jako identyfikator. Podobne zjawiska obserwowano w przeszłości w innych komunikatorach i serwisach społecznościowych; ostrzegano też, że telefon jako główny identyfikator ułatwia łączenie tożsamości i tworzenie baz OSINT. Sprawa WhatsAppa jest jednak wyjątkowa skalą — badacze mówią o „najszerszej ekspozycji numerów telefonów w historii”.

Analiza techniczna / szczegóły luki

Badacze generowali i testowali masowo zakresy numerów telefonów z wielu krajów. Każde zapytanie do mechanizmu contact discovery pozwalało ustalić, czy numer jest kontem WhatsApp — a jeśli tak, zaciągnąć publicznie udostępnione dane profilu (np. avatar, opis, znacznik „Business”), znaczniki czasu i inne elementy. Brak twardych limitów zapytań umożliwiał bardzo szybkie tempo enumeracji. Po odpowiedzialnym ujawnieniu Meta uszczelniła ograniczenia (rate limiting), utrudniając masowe skanowanie.

Dlaczego to działa?

WhatsApp musi odpowiedzieć, czy kontakt istnieje — inaczej nie da się wygodnie budować list znajomych.
Jeśli endpoint odpowiada bez adekwatnych limitów i heurystyk anty-automatyzacyjnych, napastnik może „przelecieć” ogromne przestrzenie numeracji.
Każdy dodatkowy bit publicznej informacji (avatar, opis) zwiększa entropię identyfikacyjną i wartość danych dla ataków socjotechnicznych.

Praktyczne konsekwencje / ryzyko

Targetowany phishing/Smishing: precyzyjne listy numerów WhatsApp, z lokalizacją krajową i metadanymi profilu, ułatwiają kampanie podszywania.
Doxing i nękanie: skojarzenie numeru z wizerunkiem i statusem konta pomaga w identyfikacji osoby.
Fraudy „na firmę”: oznaczenia Business mogą prowadzić do podszywania się pod firmy/klientów w łańcuchach dostaw.
OSINT na masową skalę: budowa grafów społecznych i wzbogacanie baz marketingowych/szpiegowskich.

Uwaga: według Meta, treść komunikacji pozostała zaszyfrowana E2E; mówimy o wycieku informacji o kontach/identyfikatorach, nie o odszyfrowaniu rozmów.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników:

Ustawienia prywatności → ogranicz widoczność zdjęcia profilowego, „O mnie”, statusu i informacji „Kto może zobaczyć…?” do „Moje kontakty” lub „Nikt”.
Rozważ oddzielenie numeru do komunikatorów od numeru „urzędowego”/bankowego.
Weryfikuj wiadomości: nie klikaj linków z nieznanych źródeł; potwierdzaj tożsamość innym kanałem.
Zgłaszaj nadużycia w aplikacji; blokuj nieznane numery.

Dla firm/SOC:

Polityka BYOD/komunikatorów: ograniczaj użycie numerów pracowników jako oficjalnych identyfikatorów; rozważ konta firmowe z kontrolami prywatności.
Reguły detekcji: w SIEM/SOAR dodaj wzorce smishingu i kampanii podszywania z WhatsApp (URL shortenery, popularne domeny phishingowe).
Szkolenia phishingowe ukierunkowane na WhatsApp/sms.
DLP/OSINT: monitoruj paste’y i rynki danych pod kątem list „WhatsApp leads”.
Weryfikacja klientów: w procesach obsługi klienta nie polegaj wyłącznie na identyfikacji numerem/WhatsApp.

Różnice / porównania z innymi przypadkami

Projekt vs. exploit: To nie był „remote code execution”, lecz problem projektowy (design flaw) + niedostateczny rate limiting — podobnie jak znane w przeszłości wycieki z mechanizmów „czy ten e-mail istnieje?”.
Unikalna skala: rzadko spotykamy możliwość enumeracji globalnej bazy użytkowników popularnego komunikatora w tak krótkim czasie.

Podsumowanie / kluczowe wnioski

WhatsApp naprawił lukę po zgłoszeniu, jednak numer telefonu jako identyfikator pozostaje podatnym punktem wielu usług.
Organizacje powinny zakładać, że „publiczne metadane” (avatar, opis, obecność w usłudze) mogą zostać zebrane hurtowo i wykorzystane w atakach.
Twarde rate limiting + heurystyki anty-botowe + telemetryjne sygnały nadużyć to obowiązek przy funkcjach „discovery”.

Źródła / bibliografia

BleepingComputer: „WhatsApp API flaw let researchers scrape 3.5 billion accounts” (22 listopada 2025). (BleepingComputer)
University of Vienna — komunikat o badaniach (listopad 2025). (Universität Wien)
WIRED: „A Simple WhatsApp Security Flaw Exposed 3.5 Billion Phone Numbers” (listopad 2025). (WIRED)
SecurityWeek: „Vulnerability Allowed Scraping of 3.5 Billion WhatsApp Accounts” (20 listopada 2025). (SecurityWeek)
CSO Online: „WhatsApp flaw allowed discovery of the 3.5 billion mobile numbers…” (listopad 2025). (csoonline.com)

CVE-2025-0111 — PAN‑OS: Authenticated File Read w interfejsie zarządzania (web)

TL;DR

Luka CVE‑2025‑0111 pozwala uwierzytelnionemu napastnikowi z dostępem sieciowym do interfejsu zarządzania PAN‑OS odczytywać pliki systemowe czytelne przez użytkownika nobody. Ryzyko rośnie przy wystawieniu interfejsu na Internet (np. port 4443 na interfejsie dataplane z profilem management). Producent udostępnił wydania naprawcze oraz sygnatury Threat ID 510000/510001 (pakiet Apps&Threats ≥ 8943). W praktyce: załataj, ogranicz źródła IP do zaufanych, sprawdź, czy nie doszło do łańcuchowej eksploatacji z CVE‑2025‑0108/CVE‑2024‑9474, i zrotuj sekrety, jeśli masz podejrzenie naruszenia.

Krótka definicja techniczna

Authenticated File Read w portalu zarządzania PAN‑OS: błąd kontroli ścieżki (CWE‑73), który umożliwia po zalogowaniu oraz z dostępem sieciowym do UI odczyt plików z systemu plików urządzenia, o ile są one czytelne przez konto systemowe nobody. To naruszenie poufności bez bezpośredniego wpływu na integralność/ dostępność.

Gdzie występuje / przykłady platform

Fizyczne NGFW (PA‑Series) oraz VM‑Series (on‑prem/ESXi, AWS/Azure/GCP) — jeśli interfejs zarządzania dostępny z niezaufanej sieci.
CN‑Series (Kubernetes) — gdy profil management nadany interfejsowi dataplane/Service LB i port mgmt (typ. 4443) dostępny publicznie.
Nie dotyczy: Cloud NGFW i Prisma Access.

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

Wadliwa walidacja/normalizacja ścieżek w webowym interfejsie zarządzania PAN‑OS pozwala po pomyślnym uwierzytelnieniu wykonywać zapytania skutkujące odczytem plików (zakres: pliki czytelne przez nobody). Skuteczność ataku rośnie, gdy:

Interfejs mgmt jest osiągalny z Internetu (bez filtrów źródeł); 2) napastnik dysponuje ważnymi poświadczeniami (np. uzyskanymi inną techniką); 3) podatność jest łączona w łańcuch z innymi błędami (np. CVE‑2025‑0108 i CVE‑2024‑9474), co obserwowano w praktyce. Ujawnione pliki mogą zawierać metadane/konfiguracje ułatwiające eskalację i dalsze działania (rekonesans, wyciek).

Status i ocena producenta: CVSS‑BT 7.1 (HIGH), Exploitation: ATTACKED. Producent wydał poprawki dla gałęzi 10.1, 10.2, 11.1, 11.2 oraz wskazał, że starsze EoL (9.x/10.0/11.0) uznaje się za podatne i nie będą łatane.

Artefakty i logi

Źródło/warstwa	Typ/plik/log	Wskaźniki/klucze	Uwagi
PAN‑OS Threat log	Sygnatury Threat ID 510000/510001	`threatid`, `action`, `src`, `dst`, `app`, `rule`	Wydane w Apps&Threats ≥ 8943 — blokada/alert prób eksploatacji.
PAN‑OS System log	Zdarzenia logowania/administracji	anomalne logowania do UI, zmiany w profilu mgmt	Do korelacji z dostępem z zewnętrznych ASN.
PAN‑OS web‑server access (mp‑log)	Dostępy do `/php/*` / UI	Nietypowe źródła, wzorce żądań	W praktyce forwardowane przez syslog lub inspekcja na urządzeniu.
PAN‑OS Traffic log	Ruch do portów 443/4443 na IP zarządzania	`dst_port in (443,4443)`, `action=allow`, źródła spoza RFC1918	Służy do wykrywania ekspozycji/nieautoryzowanych źródeł.
AWS CloudTrail	AuthorizeSecurityGroupIngress, CreateLoadBalancerListeners	Otworzenie 443/4443 na `0.0.0.0/0`	Wczesny sygnał błędnej ekspozycji UI w chmurze.
K8s audit	`create`/`patch` Service/Ingress	Service typu LoadBalancer/NodePort eksponujący 4443	Dot. CN‑Series/środowisk PoC.
M365/Entra	[brak danych]	—	Nie dotyczy tej luki.
Windows (EID)	[brak danych]	—	Nie dotyczy — luka po stronie urządzenia PAN‑OS.

Detekcja (praktyczne reguły)

Sigma — wykrycie sygnatur producenta (Threat log)

title: PAN-OS CVE-2025-0111 — Threat ID detection
id: 0d6b9c2a-5d0e-4e77-98a7-24d0a1c9a111
status: experimental
logsource:
  product: pan-os
  service: threat
detection:
  sel_ids:
    threatid|endswith:
      - '510000'
      - '510001'
  sel_text:
    threatname|contains: 'CVE-2025-0111'
  condition: sel_ids or sel_text
fields:
  - src
  - dst
  - app
  - rule
  - action
  - threatid
level: high
tags:
  - cve.CVE-2025-0111
  - attack.T1190

Sigma — dostęp do UI zarządzania z Internetu (Traffic log)

title: PAN-OS Management UI from External IPs (443/4443)
id: 3b1aaf9e-1f76-4e4d-9b86-b3c59a4d4443
status: experimental
logsource:
  product: pan-os
  service: traffic
detection:
  sel:
    action: 'allow'
    dst_port|in:
      - 443
      - 4443
  not_internal_src:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: sel and not not_internal_src
fields:
  - src_ip
  - dst_ip
  - rule
  - app
  - vsys
level: medium
tags:
  - hardening.exposure

Splunk (SPL)

Wykrycie Threat ID / prób eksploatacji:

(index=pan* sourcetype=pan:threat)
| eval threatid_str=tostring(threatid)
| where threatid_str IN ("510000","510001") OR like(threat_name, "%CVE-2025-0111%")
| stats count min(_time) as first_seen max(_time) as last_seen by src dst app rule action threatid threat_name vsys

Dostęp do UI mgmt z Internetu:

(index=pan* sourcetype=pan:traffic action=allowed)
  (dest_port IN (443,4443))
  NOT (cidrmatch("10.0.0.0/8", src_ip) OR cidrmatch("172.16.0.0/12", src_ip) OR cidrmatch("192.168.0.0/16", src_ip))
| lookup firewall_mgmt_ips ip as dest_ip OUTPUTNEW device role
| search role="mgmt"
| stats dc(src_ip) as uniq_sources values(src_ip) as sources count by dest_ip rule app vsys

KQL (Microsoft Sentinel / AMA + CEF)

// Threat IDs 510000/510001 (CEF -> DeviceEventClassID)
CommonSecurityLog
| where DeviceVendor =~ "Palo Alto Networks"
| where DeviceEventClassID in ("510000","510001") or AdditionalExtensions contains "CVE-2025-0111"
| summarize count(), min(TimeGenerated), max(TimeGenerated) by SourceIP, DestinationIP, DeviceEventClassID, Activity, DeviceAction

// Ruch do UI mgmt z Internetu (443/4443) -> wymaga listy IP mgmt w watchliście
let MgmtIPs = dynamic(["198.51.100.10","203.0.113.5"]); // przykład
CommonSecurityLog
| where DeviceVendor =~ "Palo Alto Networks" and Activity has_cs "TRAFFIC"
| where DestinationPort in ("443","4443") and DestinationIP in (MgmtIPs)
| where ipv4_is_private(SourceIP) == false
| summarize by TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction

AWS CloudTrail Lake (SQL) — ekspozycja mgmt przez SG/ELB

-- Zmiany otwierające 443/4443 na 0.0.0.0/0
SELECT eventTime, eventSource, eventName,
       userIdentity.sessionContext.sessionIssuer.arn AS actor,
       requestParameters
FROM aws_cloudtrail_events
WHERE eventName IN ('AuthorizeSecurityGroupIngress','CreateSecurityGroup','CreateLoadBalancerListeners','ModifyLoadBalancerAttributes')
  AND (requestParameters LIKE '%0.0.0.0/0%')
  AND (requestParameters LIKE '%443%' OR requestParameters LIKE '%4443%')
ORDER BY eventTime DESC;

Elastic / EQL

any where event.dataset == "panw.threat" and
         (panw.threat.id in ("510000","510001") or message =~ "CVE-2025-0111")

Heurystyki / korelacje

Dostęp do UI z zewnętrznych ASN ⟺ logowanie admina ⟺ odczyt/zmiany konfiguracji (System log).
Wyzwolenie Threat ID 510000/510001 ⟺ ciągłe próby z jednego źródła ⟺ brak wcześniejszej aktywności tego IP.
Nagłe upublicznienie portu 4443/443 (CloudTrail/K8s audit) ⟺ nowe alerty Threat ⟺ zmiany haseł/kluczy w krótkim oknie czasu.

False positives / tuning

Ruch z monitoringu/NAC/VPN podszywający się pod „zewnętrzny” (np. testy dostępności).
Maintenance (serwis dostawcy) — jednorazowy dostęp spoza korp.
Dla sygnatur — testowe skanery i pentesty w labie.
Tuning: listy zaufanych źródeł, mapowanie IP mgmt w SIEM, korelacja z oknami serwisowymi.

Playbook reagowania (IR)

Triage/izolacja ekspozycji
- Zidentyfikuj, czy UI mgmt jest publicznie dostępny; jeśli tak, zablokuj/ogranicz źródła (ACL, SG, WAF) do zaufanych IP.
Patching
- Zaktualizuj do wersji naprawczej: 10.1.14‑h9+, 10.2.x‑h21/h24/h14/h12/h6/… (wg tabeli), 11.1.6‑h1+/11.1.4‑h13+/11.1.2‑h18+, 11.2.4‑h4+ lub 11.2.5+. Starsze EoL — migracja/wymiana.
Zabezpieczenia prewencyjne
- Włącz/zweryfikuj subskrypcję Threat Prevention i sygnatury Threat ID 510000/510001 (Apps&Threats ≥ 8943).
Hunting
- Przejrzyj logi Threat/System/Traffic pod kątem prób/udanych dostępów.
- Oceń korelację z CVE‑2025‑0108/CVE‑2024‑9474 (możliwe łańcuchy).
Remediacja sekrety (gdy podejrzenie nadużycia):
- Zmień master key (AES‑256‑GCM), hasła/PSK/secrety, unieważnij i wydaj ponownie certyfikaty z kluczami prywatnymi na urządzeniu.
Edukacja i kontrola zmian
- Wymuś politykę „jump‑box only” do UI mgmt; przegląd SG/ACL/Ingress.

Przykłady z kampanii / case studies

Eksploatacja łańcuchowa: producent i niezależne raporty wskazały próby łączenia CVE‑2025‑0108 + CVE‑2024‑9474 + CVE‑2025‑0111 na niezałatanych i źle zabezpieczonych interfejsach mgmt.
Advisory/monitoring: Armis i HKCERT klasyfikują ryzyko jako wysokie; zalecają priorytetowy patching i ograniczenie ekspozycji.
Bazy podatności: NVD/CVE.org/Tenable/Rapid7 dokumentują charakter luki, wektor i brak wpływu na Cloud NGFW/Prisma Access.

Lab (bezpieczne testy) — przykładowe kroki/komendy

Tylko w odizolowanym labie. Nie wykonuj testów wobec cudzych systemów. Scenariusz ma zweryfikować detekcje i hardening, nie eksploatować luki.

Weryfikacja wersji i contentu (CLI PAN‑OS):
- show system info → sprawdź sw-version.
- request content upgrade check / request content upgrade download latest / request content upgrade install version <>=8943 (upewnij się, że Threat ID 510000/510001 są obecne).
Tymczasowe logowanie dostępu do UI
- Skonfiguruj forwarding System/Threat/Traffic do SIEM.
- Z dozwolonego hosta wewnętrznego wygeneruj benign ruch do UI: curl -k https://<fw-mgmt>:4443/ (sprawdź, czy powstają zapisy w Traffic/System).
Testy detekcji w SIEM
- Uruchom podane zapytania Splunk/KQL/Elastic; w razie braku rzeczywistych zdarzeń skorzystaj z generatorów logów testowych (np. sample CEF) z symbolicznym threatid=510000 (bez faktycznej próby eksploatacji).
Hardening
- Zaimplementuj listę zaufanych źródeł (ACL/SG) i regułę „jump‑box only”; potwierdź, że ruch spoza listy nie dociera do UI.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK)

M1051 — Update Software (aktualizacje PAN‑OS do wersji naprawczych).
M1037 — Filter Network Traffic (restrykcja źródeł do UI, tylko zaufane IP).
M1030 — Network Segmentation (dostęp przez jump‑host/VPN).
M1042 — Disable or Remove Feature or Program (wyłączenie profilu mgmt na interfejsach dataplane, jeśli zbędny).
M1027 — Password Policies / M1026 — Privileged Account Management (rotacja sekretów/mk, least privilege).

Techniki (ATT&CK)

T1190 — Exploit Public‑Facing Application

Dotyczy nadużycia błędu w aplikacji web wystawionej publicznie (UI mgmt). Tu: wymaga PR:L (zalogowanego aktora), ale wektor nadal AV:N i kanał webowy.

T1078 — Valid Accounts

Warunek konieczny: ważne konto z dostępem do UI mgmt (np. po phishingu/wycieku). Korelować logowania z nietypowych ASN.

T1005 — Data from Local System

Odczyt plików z systemu plików urządzenia w celu pozyskania informacji pomocnych do dalszych faz ataku.

Źródła / dalsza lektura

Palo Alto Networks — Advisory (CVE‑2025‑0111): opis, wersje naprawcze, Threat ID 510000/510001, zalecenia dot. master key/rotacji sekretów. (Palo Alto Networks Security)
NVD (nist.gov) — karta CVE. (NVD)
CVE.org — rekord producenta. (CVE)
Tenable / Rapid7 — podsumowania ryzyka i przypomnienie o ograniczeniu dostępu do UI. (Tenable®)
FortiGuard / H‑ISAC / HKCERT / Armis — doniesienia o łańcuchach eksploatacyjnych i „in‑the‑wild”. (FortiGuard)
MITRE ATT&CK — Version history (v18.1). (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjne):

Czy posiadamy watchlistę IP mgmt i aktywne reguły dla portów 443/4443?
Czy SIEM odbiera Threat/System/Traffic z NGFW i wzbogaca o ASN/CIDR?
Czy alertujemy na Threat ID 510000/510001 (wysoki priorytet)?
Czy działają korelacje: zdalny dostęp do UI ↔ logowanie admina ↔ zmiana config?
Czy przeprowadzono hunt pod kątem prób łańcuchowych (CVE‑2025‑0108/2024‑9474/2025‑0111)?

CISO / właściciel ryzyka:

Czy interfejs mgmt nie jest dostępny z Internetu (architektura „jump‑box only”)?
Czy wszystkie instancje mają wersje naprawcze (wg tabeli producenta)?
Czy mamy proces rotacji sekretów/master key/certyfikatów po incydencie?
Czy SLA na Apps&Threats content gwarantuje ≥ 8943 i autoupdate?
Czy polityki least privilege dotyczą również kont administracyjnych NGFW?

CVE-2023-27997 – Krytyczna podatność typu heap‑based buffer overflow w FortiOS/FortiProxy (SSL‑VPN, FortiGate)

TL;DR

Co: Pre‑auth RCE w FortiOS/FortiProxy SSL‑VPN (FortiGate) — CVE‑2023‑27997 („XORtigate”).
Jak: nadpisanie bufora (heap) poprzez parametr enc w endpointzie /remote/hostcheck_validate, co umożliwia wykonanie kodu bez logowania.
Ryzyko: krytyczne, aktywnie wykorzystywane, w KEV (CISA).
Naprawa: aktualizacja co najmniej do FortiOS 6.0.17 / 6.2.15 / 6.4.13 / 7.0.12 / 7.2.5 oraz odpowiednie wersje FortiProxy; w razie potrzeby tymczasowo wyłączyć SSL‑VPN.
ATT&CK: T1190 (Initial Access). Wskazane korelacje z T1133 (External Remote Services) oraz T1210 (Exploitation of Remote Services) dla ruchu/powykorzystaniowych zachowań.

Krótka definicja techniczna

CVE‑2023‑27997 to błąd heap‑based buffer overflow (CWE‑122/CWE‑787) w komponencie SSL‑VPN FortiOS/FortiProxy umożliwiający zdalne wykonanie kodu na urządzeniu bez uwierzytelnienia poprzez „specjalnie spreparowane” żądania HTTP/HTTPS do publicznego interfejsu VPN.

Gdzie występuje / przykłady platform

Network Devices (FortiGate/FortiProxy) — urządzenia brzegowe z włączonym SSL‑VPN. (Matryca ATT&CK obejmuje „Network Devices”).
Chmura/edge: gdy FortiGate stoi za ALB/WAF (AWS/Azure/GCP), ślady ataków w logach ALB/WAF/Load Balancer. [Mimo że sama podatność dotyczy urządzenia, telemetria może być w logach chmurowych.]
Windows/AD/Azure/M365/K8s/ESXi: pośrednio — jako dalsze cele po początkowym włamaniu (lateral movement), nie jako wektor podatności.

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

Atakujący składa pre‑auth żądania HTTP(S) do portalu SSL‑VPN FortiGate. Kluczową rolę odgrywa endpoint /remote/hostcheck_validate i parametr enc, którego długość i dekodowanie są błędnie weryfikowane. Błąd pozwala na nadpisanie pamięci sterty i w konsekwencji wykonanie kodu. Badanie LEXFO opisuje też zależności od /remote/info (do pobrania „salt”) oraz charakter „XOR‑overflow” wykorzystywany do manipulacji pamięcią. W praktyce umożliwia to początkowy dostęp (Initial Access) i często ominięcie MFA, ponieważ atak następuje przed uwierzytelnieniem.

Fortinet potwierdził krytyczność problemu (FG‑IR‑23‑097), publikując łatki i zalecając niezwłoczną aktualizację; CISA dodała CVE do KEV (Known Exploited Vulnerabilities).

6) Artefakty i logi (tabela)

Źródło/warstwa	Kluczowe pola / wzorce	Przykładowe wartości / IOC	Uwagi
FortiGate system/sslvpn logs	`type=event`, `subtype=vpn`/`daemon`, `msg`, `service=sslvpn`, `logid`, `eventtime`	Błędy `invalid enc data length`, restarty/„sslvpnd daemon crash/watchdog timeout”	Crashe/timeouty `sslvpnd` są sygnałem ostrzegawczym.
FortiGate HTTP/HTTPS access	`url`, `http_method`, `status`, `user=""` (pre‑auth), `srcip`	Żądania do `/remote/hostcheck_validate` z parametrem `enc=`; skoki 4xx/5xx	Najlepiej zbierać jako syslog/CEF do SIEM.
FortiGate Event (log IDs)	`logid`, `action`, `user`	Zalew SSL‑VPN login fail (np. `...user-ssl-login-fail...`) lub niestandardowe wzorce	Przydatne do korelacji szumu skanowania z exploitami.
Crashlog	`diag debug crashlog read`	Wpisy o `sslvpnd`, sygnały, restarty	Materiał dowodowy na awarie procesu.
ALB/WAF/Reverse Proxy	`request_uri`, `user_agent`, `status`, `bytes`	`/remote/hostcheck_validate`, `enc=`; piki z pojedynczych IP	Gdy urządzenie stoi za LB/WAF.
Windows EID	—	[nie dotyczy]	Bezpośrednio brak artefaktów Windows.
AWS CloudTrail	—	[nie dotyczy]	CloudTrail nie rejestruje treści HTTP; szukaj w ALB/WAF (CloudWatch Logs).
K8s audit	—	[nie dotyczy]
M365 audit	—	[nie dotyczy]

Detekcja (praktyczne reguły)

Sigma (FortiGate / proxy logs)

title: FortiGate SSL-VPN hostcheck_validate enc Anomaly (CVE-2023-27997)
id: 4d6f70b0-6b8a-4a3a-9be1-enc-hostcheck
status: experimental
description: Wykrywa żądania do /remote/hostcheck_validate z parametrem enc= (pre-auth) – możliwe wykorzystanie CVE-2023-27997.
references:
  - https://nvd.nist.gov/vuln/detail/cve-2023-27997
  - https://blog.lexfo.fr/xortigate-cve-2023-27997.html
  - https://www.cisa.gov/news-events/alerts/2023/06/13/cisa-adds-one-known-exploited-vulnerability-catalog
tags:
  - attack.t1190
  - cve.2023-27997
logsource:
  category: firewall
  product: fortinet
detection:
  sel_path:
    url|contains: "/remote/hostcheck_validate"
  sel_param:
    url|contains: "enc="
  # alternatywne pola spotykane w CEF/LEEF
  sel_alt1:
    cs-uri-stem|contains: "/remote/hostcheck_validate"
  sel_alt2:
    cs-uri-query|contains: "enc="
  condition: (sel_path and sel_param) or (sel_alt1 and sel_alt2)
fields:
  - src_ip
  - dst_ip
  - url
  - http_method
  - http_status
falsepositives:
  - Starsze klienty FortiClient wykonujące host-check (rzadkie)
level: high

Splunk (SPL)

Wyszukaj podejrzane żądania i skoki błędów:

index=network (sourcetype=fortigate* OR sourcetype=proxy*)
("|/remote/hostcheck_validate" OR cs_uri_stem="/remote/hostcheck_validate")
("enc=" OR cs_uri_query="*enc=*")
| bin _time span=5m
| stats count count(eval(http_status>=400 AND http_status<600)) AS errs
        values(http_method) AS methods
        values(http_status) AS statuses
        by _time, src_ip, dest_ip, uri, user
| where count>=5 OR errs>=3

Crashes sslvpnd (system events):

index=network sourcetype=fortigate:syslog ("sslvpnd" OR "SSL VPN Watchdog" OR "daemon crash")
| stats count latest(msg) AS any_message by _time, host

KQL (Microsoft Sentinel — CommonSecurityLog lub CEF z FortiGate)

let t = 5m;
CommonSecurityLog
| where DeviceVendor =~ "Fortinet"
| where RequestURL has "/remote/hostcheck_validate" and RequestURL has "enc="
| summarize cnt = count(), statuses = make_set(FlexString1) by bin(TimeGenerated, t), SourceIP, DestinationIP, RequestURL
| where cnt >= 5

AWS — CloudWatch Logs Insights (ALB/WAF access logs; nie CloudTrail)

fields @timestamp, @message, httpRequest.clientIp as src
| filter requestURI like /\/remote\/hostcheck_validate/ and @message like /enc=/
| stats count() as hits, countif(elb_status_code like /5\d\d|4\d\d/) as errs by bin(5m), src, requestURI
| filter hits >= 5 or errs >= 3

Elastic (Kibana KQL + EQL)

KQL (HTTP/Proxy index):

url.path : "/remote/hostcheck_validate" and url.query : "*enc=*"

EQL (jeśli parsowane do pól http/url):

sequence by source.ip with maxspan=5m
  [ network where url.path == "/remote/hostcheck_validate" and url.query : "*enc=*" ]
  [ any where process.name == "sslvpnd" and event.action in ("crash","restart") ]

Heurystyki / korelacje

Wzorzec żądań: burst żądań do /remote/hostcheck_validate z enc= z pojedynczego IP + wysoki udział 4xx/5xx → koreluj z restartem/crashem sslvpnd w ±5 min.
Pre‑auth charakter: brak user w logu, brak sesji, nietypowy User‑Agent (skanery/custom).
Post‑exploitation: nagłe utworzenie/zmiana konta admina (np. fortigate-tech-support) lub odczyt konfiguracji — sygnał znany z incydentów wokół CVE‑2023‑27997.
Trwałość na urządzeniu: modyfikacje w przestrzeni plików SSL‑VPN (np. katalog językowy) i techniki „symlink” opisywane przez Fortinet jako metoda ukrywania artefaktów po wcześniejszych exploitach — warto hunting.

False positives / tuning

Prawdziwe host‑checki starych klientów FortiClient mogą dotykać hostcheck_validate, jednak wolumen jest niewielki i statusy HTTP są zazwyczaj 200/302.
Skanery bezpieczeństwa/VAS mogą generować pojedyncze hity.
Tuning: whitelisty źródeł administracyjnych, progi wolumetryczne (np. ≥5 w 5 min), statusy ≥400, brak user, nietypowe geolokalizacje/GEO‑ASN.

Playbook reagowania (IR)

Identyfikacja ekspozycji
- Zbierz listę FortiGate/FortiProxy z włączonym SSL‑VPN i sprawdź wersje (get system status).
- Jeżeli urządzenie podatne i dostępne z Internetu — podnieś priorytet.
Doraźne ograniczenie ryzyka (jeśli patch niedostępny)
- Wyłącz SSL‑VPN do czasu aktualizacji (Fortinet wskazuje to jako obejście).
Patch & Verify
- Zaktualizuj co najmniej do FortiOS 6.0.17 / 6.2.15 / 6.4.13 / 7.0.12 / 7.2.5; FortiProxy do odpowiednich wersji (≥7.2.4 lub ≥7.0.10).
Hunting (±30 dni)
- Przeszukaj SIEM pod kątem /remote/hostcheck_validate + enc=; wysoki wolumen/4xx/5xx.
- Sprawdź crashlog/system events (sslvpnd crash/watchdog).
- Zweryfikuj kontrolę administracyjną: nieautoryzowane konta admin (np. fortigate-tech-support), anomalie w konfiguracji.
Forensyka na urządzeniu
- Sprawdź katalogi językowe SSL‑VPN pod kątem podejrzanych plików/symlinków (wątek post‑exploitation opisany przez Fortinet).
Remediacja haseł/kluczy
- Po kompromitacji: rotacja poświadczeń, kluczy VPN, certyfikatów; sprawdź integracje LDAP/Radius.
Hardening
- Ogranicz ekspozycję panelu/portu VPN do zaufanych adresów; włącz WAF/geo‑IP rate‑limit/DoS‑policy.
Zgłoszenie i lessons learned
- Odnotuj w rejestrze incydentów; zaktualizuj reguły, dashboardy, runbooki.

Przykłady z kampanii / case studies

CISA KEV: CVE‑2023‑27997 dodane 13 czerwca 2023 do katalogu KEV — wymóg szybkiej remediacji.
Fortinet PSIRT (06.2023): ograniczone przypadki wykorzystania „in the wild”; zalecenie natychmiastowego upgrade, brak powiązania z Volt Typhoon w dacie publikacji.
Raporty branżowe (2024–2025): CVE pojawia się w zestawieniach „routinely exploited”; organy rządowe ostrzegały przed utrzymaną obecnością na FortiOS po patchach (konieczny threat hunting).

Lab (bezpieczne testy)

Tylko w kontrolowanym labie (izolowane FortiGate/FortiProxy). Celem jest detekcja, nie eksploatacja.

Przygotowanie:
- Urządzenie testowe FortiGate z włączonym SSL‑VPN, wersja podatna (offline, bez Internetu).
- SIEM (np. Splunk/Elastic/Sentinel) z odbiorem syslog/CEF.
Generowanie normalnego ruchu:
- Z klienta FortiClient zestaw połączenie → powstaną logi tunnel-up / tunnel-down (do porównania).
Generowanie podejrzanych wzorców (bez exploitów):
- Wyślij wielokrotne żądania GET do /remote/hostcheck_validate?enc=AA z różnych IP źródłowych (np. z testowych kontenerów) — celem jest wygenerowanie charakterystycznego wzorca URI i 4xx w logach (nie dostarczać Keystream/PoC).
- Zweryfikuj, czy reguły z pkt 7 aktywują alerty, a dashboardy pokazują piki 4xx/5xx.
Symulacja awarii procesu:
- (Opcjonalnie) ręcznie zrestartuj usługę SSL‑VPN, aby przetestować korelację z logami „daemon restart/crash” bez wymuszania błędu w pamięci.
Walidacja:
- Przejrzyj korelacje: burst /remote/hostcheck_validate + restart sslvpnd + brak user + 4xx.

Mapowania (Mitigations, powiązane techniki)

Technika główna: T1190 – Exploit Public‑Facing Application (Initial Access).

Techniki powiązane:

T1133 – External Remote Services (VPN jako brama zdalna; logika detekcji dostępowej).
T1210 – Exploitation of Remote Services (ew. późniejsze ruchy boczne).

Mitigations (ATT&CK):

M1030 — Network Segmentation (DMZ dla usług publicznych).
M1035 — Limit Access to Resource Over Network (allow‑list do portalu VPN).
M1042 — Disable or Remove Feature or Program (wyłącz SSL‑VPN, jeśli nieużywany).
M1050 — Exploit Protection (ochrony przed exploitami, w tym IPS/WAF).
M1016 — Vulnerability Scanning (ciągła walidacja wersji).

Źródła / dalsza literatura

NVD: opis, wersje dotknięte, CVSS 9.8. (NVD)
CISA KEV: dodanie CVE‑2023‑27997 do katalogu (2023‑06‑13). (CISA)
Fortinet PSIRT (blog, 12.06.2023): kontekst, zalecenia, brak bezpośredniego powiązania z Volt Typhoon w dacie publikacji. (Fortinet)
FortiGuard CVRF FG‑IR‑23‑097: opis, workaround „disable SSL‑VPN”. (FortiGuard)
LEXFO (XORtigate): szczegóły techniczne błędu (/remote/hostcheck_validate, enc). (blog.lexfo.fr)
Rapid7: wersje naprawcze (6.0.17/6.2.15/6.4.13/7.0.12/7.2.5), IOCs (np. fortigate-tech-support). (Rapid7)
Fortinet (04.10.2025): technika symlink post‑exploitation na FortiOS. (Fortinet)
Fortinet community: watchdog/crash sslvpnd — jak rozpoznać w logach. (Fortinet Community)

Checklisty dla SOC / CISO

SOC (operacyjna):

Alert na /remote/hostcheck_validate + enc= (pre‑auth) z progami wolumetrycznymi.
Korelacja z sslvpnd crash/restart i pikami 4xx/5xx.
Hunting kont admina (np. fortigate-tech-support) i zmian konfiguracji.
Dashboard narażonych wersji (parsing get system status).
Logi z ALB/WAF, jeśli FortiGate za load balancerem.

CISO (strategiczna):

Patch policy: SLA dla urządzeń brzegowych (≤7 dni dla CVE krytycznych, w KEV).
Segmentacja/DMZ dla serwisów publicznych (M1030).
Dostęp warunkowy do paneli VPN (M1035/M1042) + geofencing.
Testy kontrolne: cykliczne skany podatności (M1016) i symulacje IR.

VPN Hardening Cookbook

Dlaczego to ma znaczenie?

VPN jest bramą do firmowej sieci – ułatwia pracę zdalną, ale dla atakujących stanowi atrakcyjny cel. Wystarczy jedno przejęte konto lub luka w VPN, by intruz zyskał dostęp do zasobów wewnętrznych. Przykładowo, głośny atak na Colonial Pipeline w 2021 rozpoczął się od wykradzionych danych dostępowych VPN bez wymuszonego MFA, co sparaliżowało krytyczną infrastrukturę. To pokazuje, że kompromitacja VPN niesie poważne konsekwencje – od wycieku danych po zatrzymanie działalności firmy.

Czytaj dalej

CISA ostrzega: aktywnie wykorzystywana krytyczna luka zero-day w Oracle Identity Manager (CVE-2025-61757)

Wprowadzenie do problemu / definicja luki

CISA dodała do katalogu Known Exploited Vulnerabilities (KEV) krytyczną lukę CVE-2025-61757 w Oracle Identity Manager (OIM) — komponent Oracle Fusion Middleware. Luka ma CVSS 9.8 i umożliwia pre-auth RCE (zdalne wykonanie kodu bez uwierzytelnienia) w wersjach 12.2.1.4.0 i 14.1.2.1.0. Oracle załatał problem w Critical Patch Update z 21 października 2025 r., lecz według CISA luka jest już aktywnie wykorzystywana.

W skrócie

Co: CVE-2025-61757 — brak uwierzytelniania dla krytycznej funkcji w OIM (CWE-306) → pre-auth RCE.
Kogo dotyczy: OIM 12.2.1.4.0 i 14.1.2.1.0 (REST WebServices).
Status: aktywne exploity; CISA wpisała do KEV 21 listopada 2025 r.; termin na patch dla FCEB do 12 grudnia 2025 r.
Jak działa atak: ominięcie filtra bezpieczeństwa i potraktowanie chronionych endpointów jako publicznych przez dopisanie ?WSDL lub ;.wadl do URI; następnie POST do endpointu sprawdzania skryptów Groovy prowadzi do RCE.
Dowody nadużyć: obserwacje SANS ISC z logów honeypotów między 30 sierpnia a 9 września 2025 r. (wzorzec groovyscriptstatus;.wadl, 556-bajtowy payload, spójny user-agent, 3 adresy IP).

Kontekst / historia / powiązania

Oracle ujawnił i załatał CVE-2025-61757 w CPU October 2025; mapowanie CVE→doradztwo potwierdza przynależność luki do tego CPU. Kilka tygodni później CISA odnotowała aktywną eksploatację i dodała wpis do KEV, co w praktyce oznacza podniesienie priorytetu patchowania do najwyższego. Niezależnie, badacze Searchlight Cyber opisali wewnętrzną anatomię błędu oraz to, jak filtry oparte o regex/matching można zwieść dopisaniem sufiksów WSDL/WADL.

Analiza techniczna / szczegóły luki

Klasa problemu: CWE-306 – Missing Authentication for Critical Function: produkt nie wymusza uwierzytelniania przy wywołaniu funkcji wymagającej zaufanej tożsamości. W OIM błąd siedzi w REST WebServices.
Mechanizm obejścia: wadliwy allow-list/filtr URI pozwala, by chronione endpointy były rozpoznane jako publiczne po dopięciu ?WSDL lub ;.wadl do dowolnego URI. To typowy „edge case” parsowania ścieżek/parametrów.
Od R/W do RCE: po obejściu uwierzytelniania atakujący wysyła specjalnie przygotowany POST do /iam/governance/applicationmanagement/api/v1/applications/groovyscriptstatus. Choć endpoint służy tylko do sprawdzania składni Groovy, badacze pokazali, że adnotacja Groovy może wykonać się na etapie kompilacji, co skutkuje RCE.
Wersje i ocena ryzyka: dotyczy 12.2.1.4.0 i 14.1.2.1.0; CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Praktyczne konsekwencje / ryzyko

Przejęcie OIM = pełny dostęp do procesów zarządzania tożsamościami, przepływów aprowizacji, konektorów do systemów krytycznych.
Ruch boczny & eskalacja uprawnień: manipulacja przepływami uwierzytelniania i aprowizacji → dostęp do kont i zasobów zależnych.
Ataki łańcuchowe: OIM bywa centralnym punktem SSO/IGA — kompromitacja zwiększa blast radius.
Dowody aktywności: ruch skanujący i próby POST na URI z sufiksem ; .wadl przed wydaniem patcha sugerują wykorzystanie jako zero-day.

Rekomendacje operacyjne / co zrobić teraz

1) Patch natychmiast

Zastosuj CPU October 2025 dla OIM; zweryfikuj, że instancje 12.2.1.4.0 / 14.1.2.1.0 są zaktualizowane. Jeżeli nie możesz patchować „od ręki”, rozważ odseparowanie (segregacja sieci, VPN, allow-list IP, WAF) i czasowe wyłączenie REST WebServices, jeśli to możliwe.

2) Detekcja i triage incydentu

Przeskanuj logi reverse proxy/WAF/app servera pod kątem ?WSDL i ; .wadl w URI, zwłaszcza ścieżek zaczynających się od /iam/governance/applicationmanagement/….
Szukaj POST do .../groovyscriptstatus oraz nietypowej wielkości payloadu ~556 bajtów i user-agenta Chrome/60.0.3112.113.
Zweryfikuj ruch z/do adresów IP wskazanych przez SANS ISC: 89.238.132[.]76, 185.245.82[.]81, 138.199.29[.]153 (potencjalne IOC z września 2025).

Przykładowe wzorce (do adaptacji pod własne SIEM/WAF):

Regex URI (HTTP logs): (?i)(\\?|;)\\.?wadl($|[&])|\\?WSDL($|[&])
Sigma (pseudoklucze): selection: uri|contains_any: ['?WSDL', ';.wadl'] and http.method: 'POST' and uri|contains: '/groovyscriptstatus'

3) Twardnienie i monitoring

WAF: blokuj żądania zawierające ; .wadl lub ?WSDL kierowane do aplikacji OIM (czasowo — do aktualizacji).
Zaimplementuj deny-by-default dla management/diagnostic endpoints i egzekwuj mTLS dla API administracyjnych.
Włącz dodatkowe logowanie dla kompilacji/wykonania Groovy po stronie serwera aplikacyjnego (jeśli występuje).

4) Zgodność z wymogami CISA (jeśli dotyczy)

Jednostki FCEB: spełnij termin 12 grudnia 2025 r. z BOD 22-01 dla pozycji KEV.

Różnice / porównania z innymi przypadkami

Ataki wykorzystujące artefakty WSDL/WADL do obejścia kontroli dostępu nie są nowe — to warianty błędów w filtrach path/extension-based. W CVE-2025-61757 newralgiczne jest to, że wystarczy modyfikator w URI, by endpoint „udawał” publiczny, a następnie specyficzny endpoint Groovy daje RCE na etapie kompilacji — to rzadkie, ale bardzo niebezpieczne połączenie. Opis Searchlight Cyber szczegółowo pokazuje, jak taka „droga na skróty” w allow-liście sprowadza pełne przejęcie.

Podsumowanie / kluczowe wnioski

Luka CVE-2025-61757 w OIM jest poważna (CVSS 9.8), łatwa w nadużyciu i aktywnie wykorzystywana — traktuj ją jak incydent do natychmiastowej reakcji.
Nie czekaj na „okno serwisowe”: patch, segmentacja, WAF-owe reguły i łowy na IOCs już teraz.
Przejrzyj procesy IGA/SSO, bo kompromitacja OIM ma efekt domina w ekosystemie tożsamości.

Źródła / bibliografia

CISA — alert o dodaniu do KEV i terminach łatania (21.11.2025). (CISA)
Oracle — CPU October 2025 (opis luki + wersje) oraz mapowanie CVE→doradztwo. (oracle.com)
Searchlight Cyber — analiza techniczna, vektory ?WSDL/; .wadl, RCE przez Groovy. (Searchlight Cyber)
SANS ISC — obserwacje prób exploitacji (08.30–09.09.2025), IOCs i charakterystyka ruchu. (SANS Internet Storm Center)
The Hacker News — przegląd najważniejszych faktów i statusu „aktywnie wykorzystywana”. (The Hacker News)

Sankcje USA, Wielkiej Brytanii i Australii uderzają w rosyjne „bulletproof hosting” (Media Land, Hypercore/Aeza). Co to oznacza dla obrony przed ransomware?

Wprowadzenie do problemu / definicja luki

Rządy USA, Wielkiej Brytanii i Australii ogłosiły skoordynowane sankcje wobec dostawców tzw. bulletproof hostingu (BPH) – wyspecjalizowanej infrastruktury, która świadomie toleruje nadużycia, ignoruje zgłoszenia z organów ścigania i usuwa mechanizmy egzekwowania regulaminu, by zapewnić cyberprzestępcom „bezpieczną przystań” dla C2, serwerów płatności w kryptowalutach, dropów danych czy infrastruktur DDoS. Na celowniku znalazły się m.in. Media Land (Rosja) i Hypercore Ltd. (Wielka Brytania), powiązane z wcześniej sankcjonowaną Aeza Group.

W skrócie

Kogo objęto sankcjami (SDN/Krajowe listy):
Media Land LLC, ML.Cloud LLC, Media Land Technology LLC, Data Center Kirishi LLC; osoby: Aleksandr A. Volosovik (alias „Yalishanda”), Kirill A. Zatolokin, Yulia V. Pankova. Dodatkowo: Hypercore Ltd. jako „front” Aeza Group, osoby: Maksim V. Makarov, Ilya V. Zakirov.
Powód: wspieranie ransomware (LockBit, BlackSuit, Play, Cl0p), DDoS i innej działalności cyberprzestępczej.
Zakres koordynacji: wspólne działania USA–UK–AU + poradnik techniczny Five Eyes (+Niderlandy) dot. ograniczania ryzyk BPH.
Co to zmienia: większe ryzyko deplatformingu, „przemeblowanie” infrastruktur przestępczych i przepięcia do kolejnych AS/hostingów w krajach trzecich (np. Serbia, Uzbekistan – spółki wspierające).

Kontekst / historia / powiązania

Hypercore Ltd. została wskazana jako fasada dla Aeza Group, wobec której wcześniej zastosowano środki ograniczające. Obecnie rządy wskazują dodatkowo łańcuch podmiotów pomocniczych (np. Smart Digital Ideas DOO w Serbii i Datavice MCHJ w Uzbekistanie), które miały służyć obchodzeniu sankcji. Australia równolegle nałożyła kary finansowe i zakazy wjazdu na kluczowe osoby oraz podmioty powiązane z Media Land.

Analiza techniczna / szczegóły luki

Jak BPH wzmacnia ataki:

Odporność na zgłoszenia (abuse/LEA): brak reakcji na notyfikacje, przeciąganie lub ignorowanie nakazów, szybka rotacja adresacji i AS.
Segmentacja i „whitelabel”: klienci dostają dedykowane podsieci, tunelowanie, anycast/GeoDNS, aby utrudnić atribucję i sekwencję blokad.
Infrastruktury „pod kampanię”: hosting paneli C2, serwerów kradzieży danych i portali płatności, z możliwością szybkiego „mirrorowania” i fast-flux.
Łańcuch pośredników: firmy-słupy, resellerzy i procesory płatności w jurysdykcjach o niższej współpracy prawnej.

Wspólna publikacja techniczna (CISA/FBI + partnerzy Five Eyes i Niderlandy) zalicza BPH do dostawców, którzy „świadomie i celowo” oferują infrastrukturę cyberprzestępcom; dokument podaje konkretne wzorce TTP i czeklisty dla operatorów.

Wskazane powiązania kampanii: w materiałach rządowych Media Land/Aeza mają historię obsługi LockBit, BlackSuit, Play (oraz w komunikatach AU także Cl0p) i kampanii DDoS wymierzonych w infrastrukturę krytyczną.

Praktyczne konsekwencje / ryzyko

Ryzyko „przeciążenia” list blokad: nowe sankcje spowodują przepięcia infrastruktur do innych AS/hostingów (w tym „czystych”), co może przejściowo obniżyć skuteczność statycznych blokad.
Efekt uboczny (collateral): błędnie zaklasyfikowane adresy współdzielone z legalnymi klientami mogą trafić na denylisty – potrzebna granularność i telemetria ruchu.
Ekspozycja łańcucha dostaw: jeżeli Twój MSP/ISP używa trasowania przez AS powiązane z BPH, możesz nadal widzieć beaconing lub fallback C2 mimo sankcji.
Zwiększona presja compliance: podmioty objęte sankcjami trafiają na listy SDN/UK sanctions, co implikuje obowiązki KYC/AML i weryfikacje kontrahentów (także dla dostawców chmurowych i rejestratorów).

Rekomendacje operacyjne / co zrobić teraz

W oparciu o wspólne wytyczne (CISA/FBI/partnerzy) i komunikaty rządowe:

Dynamiczne filtrowanie: wdrażaj dynamiczne listy ASN / prefiksów / IP powiązanych z BPH; utrzymuj „curated lists” i automatyczne review. Zapewnij telemetrię i logowanie zdarzeń dla ruchu dopasowanego do list.
Routing security: stosuj najlepsze praktyki BGP (RPKI/ROA), BCP-38/84 i monitoruj anomalia tras do „podejrzanych” AS. (Rekomendacja wynika z poradnika – „internet routing security best practices”.)
Segmentacja i egress controls: ogranicz połączenia wychodzące do dozwolonych destynacji (FQDN/JA3/SNI), wymuś proxy/TLS inspection w strefach o podwyższonym ryzyku.
TI & współdzielenie: zasilaj SIEM/SOAR i IDS/IPS z wielu źródeł TI, w tym publikacji CISA/FBI (IOC/TTP), oraz dziel się obserwacjami z branżą (ISAC/CSIRT).
Playbook „deplatformingu”: przygotuj runbook na nagłe „przepięcia” C2 (nowe ASN, nowe VPS w 3. krajach), z huntami DNS/HTTP-TLS i regułami detekcji beaconing-like.
KYC dostawców: przeprowadź due diligence wobec rejestratorów, resellerów i mniejszych dostawców chmurowych; unikaj podmiotów bez polityk abuse i Secure-by-Design.
Mapowanie zależności: zaktualizuj asset inventory i mapy egress/ingress pod kątem zależności od AS powiązanych z BPH; uruchom alerty na zmiany tras/WHOIS.

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

W odróżnieniu od poprzednich, bardziej punktowych sankcji przeciw pojedynczym operatorom, obecne działania łączą designacje z natychmiastowo dostarczonym poradnikiem technicznym (mitigacje na poziomie ISP/defenderów). Dodatkowo rządy ujawniają łańcuchy obejścia sankcji (np. Hypercore ⇄ Aeza + spółki w Serbii/Uzbekistanie), co ułatwia proaktywne blokady na poziomie AS/firm-słupów.

Podsumowanie / kluczowe wnioski

BPH to krytyczne „zaplecze” ekosystemu ransomware – uderzenie w infrastrukturę dostawców utrudnia monetyzację i utrzymanie C2.
Skuteczna obrona wymaga dynamicznej, as-levelowej kontroli ruchu i koordynacji branżowej; same, statyczne denylisty nie wystarczą.
Organizacje powinny operacyjnie wdrożyć zalecenia z poradnika CISA/FBI/Five Eyes w ciągu najbliższych sprintów (network, SOC, compliance).

Źródła / bibliografia

U.S. Treasury (OFAC): „United States, Australia, and United Kingdom Sanction Russian Cybercrime Infrastructure Supporting Ransomware” (19 listopada 2025). (U.S. Department of the Treasury)
OFAC – Recent Actions / SDN Update (19 listopada 2025) – pełna lista osób/podmiotów (Media Land, ML.Cloud, MLT, DC Kirishi; Hypercore; Makarov, Zakirov; Pankova, Zatolokin; Volosovik). (OFAC)
UK FCDO: „UK smashes Russian cybercrime networks…” (19 listopada 2025). (GOV.UK)
Australian Federal Police: wspólny komunikat o sankcjach (20 listopada 2025). (afp.gov.au)
CISA/FBI + partnerzy (Five Eyes + NL): „Bulletproof defense: Mitigating risks from bulletproof hosting providers” – komunikat i publikacja techniczna (19 listopada 2025). (CISA)