Райън Дюхърст, главен изпълнителен директор на KEVIntel, обяснява как неговият екип потвърждава експлоатация на уязвимости, които все още не са вписани в каталога на CISA. Той описва глобална сензорна мрежа от пясъчници (honeypots), AI триаж и човешка проверка в лаборатория, преди дадена уязвимост да достигне до публичния поток.

Той разглежда тридневния краен срок за инсталиране на корекции за сигурност на CISA съгласно директивата BOD 26-04, защо виртуалното отстраняване на уязвимости купува време и как генерираният от изкуствен интелект код за доказване на концепцията (PoC) замъглява доказателствата. Той също така класифицира докладите за инциденти, засечените атаки от „пясъчници“, сканирането и дискусиите за PoC според това доколко всеки от тези фактори трябва да повиши увереността на защитника.

За частния сектор каталогът CISA KEV е авторитетен източник на сигнали за експлоатация. Но той не трябва да се счита за пълен и окончателен списък на известните експлоатирани уязвимости. Не можем да пренебрегнем и факта, че CISA е сравнително голяма организация, което може да повлияе на скоростта, с която работи, както и че е ориентирана основно към федералните агенции на САЩ.

Съгласно скорошната директива на CISA BOD 26-04: „Насоки за внедряване за приоритизиране на актуализациите за сигурност въз основа на риска“, издадена на 10 юни 2026 г., федералните агенции ще разполагат само с три дни, за да реагират на активно експлоатирани KEV, които са автоматизирани и засягат активи с достъп до интернет.

Тази нова директива затвърждава факта, че организациите трябва да приоритизират първо високорисковите KEV. Днес средно се откриват около 200 CVE на ден и тази цифра нараства година след година, особено с навлизането на AI. Практически е невъзможно да се отстранят всички уязвимости или дори само критичните и високорисковите.

Коригирането на уязвимост само за три дни е амбициозно. Управлението на корекциите за сигурност трябва да премине през много заинтересовани страни и обикновено се управлява от екип за управление на промените. Самото установяване на това какви активи притежавате и кой е техният собственик понякога може да бъде дълъг процес, особено ако организацията няма ефективно управление на активите.

Това, от което организациите се нуждаят, е повече време. Но атакуващите не чакат. Виждаме ги да действат все по-бързо, използвайки AI за обратен инженеринг на корекции и превръщане на уязвимостите в оръжие за рекордно време.

Едно от решенията на този проблем е виртуалното коригиране – обикновено правило за WAF, предназначено да блокира атаката, докато организацията инсталира корекции за сигурност на уязвимите устройства. Например, наскоро видяхме това да се използва ефективно от доставчици за намаляване на излагането на веригата за отдалечено изпълнение на код (RCE) в ядрото на WordPress. Виртуалните корекции не са дългосрочно решение, те не са перфектни и трябва да се използват само за купуване на повече време, докато се извършва същинското обновяване.

Това наистина зависи от доставчика. Виждали сме доставчици, които изкуствено завишават риска от уязвимост, докато други се опитват да го омаловажат. Например, по отношение на омаловажаването, сме виждали доставчици да твърдят, че дадена уязвимост е експлоатируема само с идентификационни данни, а при по-внимателно вглеждане се оказва, че тя действително може да бъде експлоатирана от анонимни неудостоверени потребители. Или да твърдят, че уязвимостта не е била експлоатирана в реална среда, но същевременно да включват индикатори за компрометиране (IoC), произтичащи от инциденти, в своите препоръки. Това е огромен червен флаг.

В крайна сметка клиентите на доставчика плащат цената. Рано или късно пълните подробности обикновено излизат наяве. Междувременно атакуващите се възползват напълно от объркването, а клиентите трябва да догонват.

Виждаме това доста често. Много „изследователи“ подават ограничените налични подробности за уязвимостта на LLM модел и го молят да генерира PoC. Изкуственият интелект прави всичко възможно да създаде PoC с предоставената ограничена информация, но полученият злонамерен код всъщност не експлоатира уязвимостта – той просто изглежда достатъчно убедителен, за да задоволи изследователя. Това може да се случи десетки пъти за една уязвимост, което прави трудно разграничаването на това какво е „AI спам“ и какво е истински работещ експлоит.

Наскоро видяхме това с CVE-2026-25089, уязвимост от тип OS Command Injection във Fortinet FortiSandbox.

Например, нашите сензори улавят новата експлоатация и ни сигнализират за нея, но след това трябва да прекараме време в проучване и опити да възпроизведем уязвимостта, за да определим дали е „AI спам“ или не.

Понякога е много трудно да се прецени и от самата телеметрия на атакуващия. Кодовете за доказване на концепцията често използват правилния целеви софтуер и правилните уязвими крайни точки.

Често очевидната следа не се крие в техническите детайли, а по-скоро в начина, по който е написана документацията на PoC – дали е написана от AI? Или дали това е реномиран изследовател? Издавали ли са фалшиви PoC в миналото, или са опитни изследователи с голям опит и добра репутация?

Това са лесни ориентири, но в крайна сметка техническото възпроизвеждане на уязвимостта е решаващият фактор.

Докладите за инциденти са чудесни, защото често съдържат много технически подробности, похвати на атакуващите и IoC, които защитниците могат да използват, за да помогнат за смекчаване на атаките. Но, от друга страна, това също означава, че активната експлоатация вече е в ход.

Ако видим експлоатация в нашите сензори от тип пясъчник, която е валидирана като реална атака (KEV), това трябва да бъде приоритет за защитниците. Атакуващ активно е насочен към уязвимостта и се опитва да я експлоатира.