CISA po cichu aktualizuje „ransomware flags” w KEV: 59 podatności zmieniło status bez komunikatu - Security Bez Tabu

CISA po cichu aktualizuje „ransomware flags” w KEV: 59 podatności zmieniło status bez komunikatu

Wprowadzenie do problemu / definicja luki

Katalog CISA Known Exploited Vulnerabilities (KEV) jest dla wielu zespołów bezpieczeństwa „listą priorytetów” – skoro podatność trafiła do KEV, istnieją dowody realnej eksploatacji „w dziczy”. Problem opisany na początku lutego 2026 r. dotyczy jednak nie samego dodawania nowych wpisów, lecz cichych zmian atrybutów już istniejących wpisów: CISA aktualizowała pole mówiące o tym, czy podatność jest „Known to be used in ransomware campaigns”, bez wyraźnego ogłoszenia tych zmian.

W praktyce to luka w procesie konsumpcji threat intel: Twoje narzędzia mogą widzieć KEV jako statyczną listę, podczas gdy ryzyko wpisu ewoluuje (np. „exploited” → „exploited in ransomware”).

W skrócie

  • Badacz GreyNoise (Glenn Thorpe) wykrył, że w 2025 r. aż 59 podatności w KEV miało po czasie przełączone pole knownRansomwareCampaignUse z „Unknown” na „Known”.
  • Zmiana jest „materialna” dla ryzyka: sugeruje, że CISA ma dowody użycia przez operatorów ransomware, ale brak do tego alertu/komunikatu – to „field change w JSON”.
  • Wśród „flipów” dominują kategorie, które napastnicy kochają: RCE i obejścia uwierzytelniania, a duża część dotyczy urządzeń brzegowych (VPN/edge).
  • GreyNoise uruchomił RSS śledzący te zmiany godzinowo, aby zlikwidować „ciszę” w aktualizacjach.

Kontekst / historia / powiązania

Według GreyNoise, CISA dodała pole knownRansomwareCampaignUse do KEV w październiku 2023 r. jako mechanizm lepszej priorytetyzacji – bo ransomware zwykle oznacza nie tylko włamanie, ale też monetyzację przez szyfrowanie i wymuszenie.

Problem polega na tym, że:

  1. KEV i tak jest wskaźnikiem „po fakcie” (skoro jest dowód eksploatacji),
  2. a ransomware-flag bywa jeszcze bardziej opóźniony – dowód użycia w kampanii ransomware często pojawia się po dodaniu CVE do KEV,
  3. i finalnie – te opóźnione aktualizacje były wykonywane bez osobnego kanału powiadomień.

Istotne powiązanie: CISA udostępnia dane KEV jako pliki (CSV/JSON), a ich mirror na GitHub ma historię commitów, co (paradoksalnie) ułatwia wykrywanie zmian niż sama przeglądarka katalogu.

Analiza techniczna / szczegóły luki

Na czym polega „cichy flip”?

Wpisy KEV zawierają pole knownRansomwareCampaignUse. W momencie dodania wpisu do KEV pole często ma wartość „Unknown”. Później, kiedy pojawi się wiarygodny sygnał użycia w ransomware, pole może zostać zmienione na „Known” — i to właśnie te zmiany były wykonywane bez odrębnego komunikatu.

Jak to wykryto?

Thorpe pobierał codzienne snapshoty KEV i robił diff pod kątem zmian pól (nie tylko nowych rekordów). Dzięki temu znalazł 59 przypadków w 2025 r.

Co mówi struktura tych flipów?

Z danych GreyNoise:

  • 59 flipów w 2025 r.
  • duży udział vendorów klasy enterprise i perimeter (m.in. Microsoft, Ivanti, Fortinet, Palo Alto, Zimbra)
  • znaczny odsetek dotyczył edge/network
  • czas do flipu potrafił być skrajnie różny: od 1 dnia do wielu lat (przykłady „legacy” też się pojawiają).

Dlaczego perimeter jest tu kluczowy?

W praktyce ransomware często „wygrywa” dzięki szybkiemu wejściu przez:

  • VPN / gateway / urządzenia bezpieczeństwa (edge),
  • serwery pocztowe,
  • platformy zarządzania,
    a potem eskalacji i lateral movement. To zgodne z obserwacją, że operatorzy stawiają na „get-in-and-go chains” (auth bypass + RCE).

Praktyczne konsekwencje / ryzyko

  1. Fałszywy spokój w priorytetyzacji łatek
    Jeśli Twoje reguły mówią: „KEV tak, ale ransomware-known = najwyższy priorytet”, to cichy flip powoduje, że nie podnosisz priorytetu, bo nie wiesz, że status się zmienił.
  2. Ryzyko rozjechania się danych w narzędziach
    Jeżeli konsumujesz KEV okresowo (np. raz w tygodniu), a nie śledzisz różnic pól, to zmiana może przejść niezauważona, mimo że „lista KEV” formalnie się nie zwiększyła.
  3. Uderzenie w procesy zgodności / SLA
    W wielu organizacjach „ransomware-exploited” uruchamia osobne ścieżki: emergency patch, CAB w trybie przyspieszonym, wyjątki dla downtime’u. Brak sygnału = brak reakcji.

Rekomendacje operacyjne / co zrobić teraz

1) Traktuj zmiany pól KEV jak „nowe zdarzenia”

Nie monitoruj wyłącznie „nowych CVE w KEV”. Dodaj detekcję zmian w polach (szczególnie knownRansomwareCampaignUse) jako osobny trigger w procesie VM.

2) Subskrybuj kanał, który wyłapuje flip

GreyNoise udostępnił RSS wykrywający zmiany pola ransomware (sprawdzanie godzinowe). To najprostsza „łatka” na problem ciszy komunikacyjnej.

3) Wykorzystaj GitHub mirror KEV do audytu zmian

Repo cisagov/kev-data zawiera pliki CSV/JSON i – co kluczowe – historię commitów. To daje Ci:

  • łatwy diff,
  • możliwość automatycznego pobierania,
  • możliwość budowy własnych alertów w CI/SOAR.

4) Zmień reguły priorytetyzacji

Praktyczny „policy snippet”:

  • knownRansomwareCampaignUse = Known → P1 / emergency patch (dla Internet-facing lub high value assets),
  • Known + edge device → P0 (okno serwisowe ASAP, kompensacje WAF/IPS/ACL jeśli patch niemożliwy),
  • Unknown wciąż nie znaczy „bezpieczne” – to nadal KEV (dowód eksploatacji jest!).

5) Dopnij telemetrię na perimeter

Skoro duża część flipów dotyczy perimeter, upewnij się, że masz:

  • logi z VPN/Gateway/Reverse proxy,
  • detekcje exploit attempt (WAF/IPS),
  • szybkie rotacje credentiali i przegląd tokenów/sesji (szczególnie po auth bypass).

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

  • „Nowy wpis w KEV” zwykle ma swój naturalny sygnał (ktoś to zauważy, feedy o tym piszą).
  • „Aktualizacja pola w istniejącym wpisie” może zostać kompletnie pominięta, choć operacyjnie bywa równie ważna, bo zmienia klasyfikację ryzyka i często SLA reakcji.
  • W praktyce to podobny problem jak „ciche re-klasyfikacje IOC/TTPS” w feedach TI: jeśli nie patrzysz na delta, tylko na headline, tracisz sygnał.

Podsumowanie / kluczowe wnioski

CISA nie tylko dodaje nowe podatności do KEV — potrafi też zmieniać atrybuty już istniejących wpisów w sposób, który realnie wpływa na priorytety obrony. Odkrycie 59 „cichych flipów” w 2025 r. pokazuje, że zespoły bezpieczeństwa powinny przestać traktować KEV jak statyczną listę i zacząć traktować ją jak strumień zmian, który trzeba monitorować (diff + alerty).

Źródła / bibliografia

  1. Dark Reading – opis zjawiska „unpublicized ransomware updates” i wnioski operacyjne. (Dark Reading)
  2. GreyNoise Research (Glenn Thorpe) – analiza 59 flipów, metodologia diffowania, RSS i przykłady CVE. (greynoise.io)
  3. The Register – kontekst i znaczenie braku notyfikacji dla obrońców. (The Register)
  4. SecurityWeek – dane o wzroście KEV i ransomware-exploited w ujęciu rocznym (kontekst „skali”). (SecurityWeek)
  5. GitHub cisagov/kev-data – mirror KEV z plikami JSON/CSV i historią commitów do śledzenia zmian. (GitHub)