От Сила Йозерин Хаджъоглу, инженер по изследвания на сигурността в Picus Security.

Резултатът за ефективност на превенцията ви показва какво разпознава дадено средство за защита. Той не ви казва какво точно спира това средство.

Вече в своето четвърто издание, докладът „Blue Report 2026“ на Picus Labs измерва как превенцията и откриването в предприятията действително се представят в реална среда, на базата на над 338 милиона симулации на атаки, изпълнени в реални клиентски среди от януари до юни 2026 г.

Водещото заглавие е за истинско възстановяване, но с едно важно уточнение: да, ефективността на превенцията се е повишила от 62% на 69%, връщайки се до пиковите си нива от 2024 г.

Това число обаче е средна стойност за цялата инфраструктура от защитни средства и зад него се крие по-слаба и по-уязвима вътрешност.

Същите средства за защита, които блокират добре познат инструмент за атака, позволяват на по-тиха версия на същата техника да се промъкне директно през защитата ви. Резултатът не се решава от внедрения продукт, а от това доколко разпознаваем е методът на атакуващия и дали някой е тествал за по-тихия вариант.

Тестването на сигурността на базата на индикатори за компрометиране (IOC) и на базата на тактики, техники и процедури (TTP) измерват различни неща

Дали защитата ще издържи зависи от това кой от двата въпроса ще ѝ зададете.

Тестването, базирано на IOC (индикатори за компрометиране), проверява дали дадено средство за защита разпознава известни зловредни елементи. Образци от зловреден код, разпространяващи се в мрежата, се доставят като опити за изтегляне и средствата за защита по периметъра – като защитни стени (firewalls), уеб проксита и защитени имейл шлюзове – или ги блокират, или не.

За този слой това е правилният инструмент: спирането на известно зловредно съдържание на границата на мрежата е именно целта на тези средства за защита.

Поведенческото тестване, базирано на TTP, проверява дали дадено средство за защита спира самото действие, независимо от избрания път. Въпросът не е „хващате ли Mimikatz?“, а „може ли изобщо даден процес на този хост да се сдобие с идентификационни данни?“

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

Артефактите се променят лесно; поведението – не.

Да, имате нужда и от двата подхода. И да, трябва да се противопоставите на финансовите мениджъри, които ще ви убеждават в обратното.

Асиметрията е структурна и умишлена.

За съжаление, защитата по периметъра също отстъпва.

В тазгодишните данни процентът на превенция при изтегляне на зловреден код, базиран на IOC, спадна до 50% в клиентските среди, в сравнение с 60% миналата година и 71% през 2024 г.

Дори слоят, който сигнатурите покриват най-добре, започва да поддава. А добрият резултат тук не казва нищо за поведението под повърхността – където се намесват резултатите от Mimikatz. Ето един предварителен поглед: нещата не са добре.

Сигнатурната превенция е загубила 21 пункта за две години

Вашите средства за защита спират версията на атаката, която разпознават. Приложете същото поведение по по-тих път и то ще премине невъзпрепятствано, докато последният ви тест все още показва, че сте защитени.

Вижте какво всъщност спира вашата инфраструктура в „Blue Report 2026“ и тествайте поведението вместо процедурата.

Променете начина, по който Mimikatz извлича идентификационни данни, и превенцията пада от 94% на 3%

С решението за автономно тестване за проникване на Picus, в клиентските среди беше стартиран един и същ инструмент, Mimikatz, към една и съща цел по три различни начина. Резултатите за превенция бяха шокиращи и изключително отдалечени един от друг.

  • Извличането на идентификационни данни от паметта на процеса LSASS – класическият път със силно застъпени сигнатури – беше блокирано в 94% от опитите. Добре.
  • Извличането на RDP идентификационни данни от други места в паметта със същия инструмент: 17%. Не е добре.
  • Четенето на LSA Secrets от локалния регистър: 3%. Ужасяващо.

И трите са подварианти на една и съща базова техника – Извличане на идентификационни данни от ОС (T1003), и при трите атакуващият накрая разполага с вашите ценни идентификационни данни.

Единствената променлива беше колко забележим е избраният път. В този случай класическото пожелание на г-н Спок „живейте дълго и просперирайте“ се е превърнало в „промъкнете се тихо и успейте“.

Механиката обяснява това разминаване.

Пътят през LSASS е шумен по начин, който лесно се засича: процес отваря достъп до lsass.exe и чете паметта му – събитие, за което доставчиците на решения за сигурност разработват правила от години. Четенето на LSA Secrets никога не докосва lsass; то се изпълнява с права SYSTEM и чете дял от системния регистър, което не се отличава от обичайната легитимна дейност с високи привилегии. Средство за защита, изградено около първото събитие, няма за какво да се задейства при второто.

И дори тези 94% са по-нестабилни, отколкото изглеждат. Те са измерени спрямо една известна компилация на инструмент с отворен код, чиято разпознаваемост се крие в начина, по който е компилиран, а не в това какво прави.

Преименувайте низовете, по които работи дадена сигнатура, или го компилирайте наново, и хешът и издайническите маркери стават съвсем нови.

Заредете го рефлективно и кодът никога не се записва на диска, за да бъде засечен.

Или пропуснете тази компилация и направете същото извличане с подписан от Microsoft инструмент като ProcDump или comsvcs.dll, след което го анализирайте офлайн.