Когато цялата компания въведе изкуствен интелект: Как се отразява това на вашия център за оперативно управление на сигурността (SOC)

През изминалата година наблюдавахме появата на нов клас предупреждения в центровете за сигурност (SOC) на предприятията, който нараства по-бързо от всичко останало в потока: предупреждения, задействани от инструменти и агенти с изкуствен интелект (ИИ). Не атаки срещу ИИ, а обичайният, ежедневен отпечатък на организация, която го използва — от разработчици, работещи с кодиращи агенти, до нетехнически персонал, който влиза в потребителски ИИ инструменти с корпоративни профили.

Прегледахме активността, свързана с ИИ, в множество корпоративни среди. Две числа рамкират всичко последващо. Предупрежденията, свързани с ИИ, все още представляват едва 0.43% от всички SOC предупреждения. И този дял се увеличава всеки един месец, с ръст от 685% между февруари и юни 2026 г. Днес ИИ е малка част от потока от предупреждения и същевременно най-бързо растящата такава.

Това, което прави тези предупреждения достойни за вниманието на екипа по сигурност, не е техният обем, а техният състав. Сортираме всичко, задействано от ИИ агент в SOC, в три категории: реални атаки, рискове и шум, като разпределението е 94.1% шум, 5.8% същински риск и 0.02% реални атаки. Това означава, че въз основа на анализираните от нас данни, реалните атаки, използващи ИИ агенти, са капка в океана. Цената на ИИ в SOC досега не са пробивите в сигурността. Това е нарастваща вълна от предупреждения, които изглеждат обезпокоителни, но почти никога не са такива, и малък, тих набор от същински уязвимости, които тези аларми са склонни да погребат.

Тази публикация преминава през всяка от трите категории с анонимизирани примери. Всички имена на клиенти, имена на хостове, потребителски имена и идентификатори са премахнати; индикаторите са обезвредени.

Новата форма на потока от предупреждения

Внедряването на ИИ в дадено предприятие не е едно поведение, а две много различни поведения, появяващи се едновременно.

Първото е техническо. Разработчиците инсталират кодиращи агенти, които генерират обвивки (shells), четат хранилища за идентификационни данни, отварят мрежови тунели, изтеглят пакети и стартират инструменти за сигурност — всичко това като законна работа и напълно неразличимо за модула за откриване от ранните етапи на неоторизиран достъп. Това е шумната половина и тя доминира в данните.

Второто е, когато служителите предоставят OAuth съгласие на ИИ приложения от трети страни, споделят информация и поставят документи в инструменти за генеративен ИИ. Това е тихата половина. Тя рядко задейства откриване на крайни точки, но е мястото, откъдето данните напускат сградата.

И двете половини попадат на едно и също място — SOC — и на пръв поглед и двете изглеждат като нещо притеснително. Разграничаването на сигнала от шума е цялата работа.

В числа

ИИ представлява малък дял от обема, но се развива бързо. От приблизително 16.9 милиона SOC предупреждения, които прегледахме, около 73 000 (0.43%) са свързани с ИИ. Разгледано само по себе си, това е успокоително малко.

Увеличението е монотонно. Всеки пълен месец е по-висок от предишния, а растежът се ускори рязко през май 2026 г. За прозореца, в който отчитането е стабилно по региони (от февруари до юни), обемът нарасна с 685%. Цифрата от 0.43% е най-добре да се разбира като днешния минимум, а не като таван. Екип, който оразмерява обработката на ИИ предупреждения спрямо текущия обем, ще бъде с недостатъчен ресурс в рамките на едно тримесечие.

Съставът е толкова едностранчив, колкото е стръмна тенденцията. Почти всички генерирани от ИИ предупреждения са шум.

За това изследване проучихме популацията, свързана с ИИ, и сортирахме всяко предупреждение според основната активност. Реална атака е потвърдено компрометиране. Риск за сигурността не е компрометиране, а същинска уязвимост (например кодиращ агент, работещ с деактивирани защити за разрешения). Шумът е легитимна активност, която е задействала откриване, написано преди съществуването на ИИ агенти. По този показател почти всички предупреждения, свързани с ИИ, са шум (94.1%), малка част са същински рискове за сигурността (5.8%), а реалните атаки са нищожен дял (0.02%).

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

• Заключението посочва колко опасна изглежда активността: тя може да бъде безобидна, съмнителна или злонамерена.
• 79.8% са получили безобидно заключение.
• Отговорът посочва какво се случва след това: предупреждението може да бъде потушено (затворено автоматично, така че нито един аналитик да не го види), маркирано за последващо проследяване или ескалирано към човек.
• 81.7% са били автоматично потушени.

От популацията, свързана с ИИ, едва 5.4% някога са били ескалирани към аналитик човек; останалите са били маркирани за последващо проследяване.

Предупреждение с висока степен на сериозност не означава непременно действителна заплаха. Например, едно-единствено откриване при един клиент представлява 55% от всички предупреждения с „критично“ заключение, маркиращи двоичен файл на Windows (Expand.exe) като прехвърляне на инструмент за странично придвижване (lateral-tool-transfer). При проверка беше установено, че кодиращият агент на даден разработчик е настройвал обвивна среда (shell environment) и това поведение е било нормално за този тип работа.

Урокът за всеки SOC е същият: етикетите за сериозност на ИИ активността трябва да се четат със съмнение, а не да се приемат за даденост.

Категория 1: Реални атаки

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

Когато става въпрос за действителни заплахи, които са били открити в този клас предупреждения, нито една не е била компрометиране, причинено от собствения ИИ агент на организацията. Всяко предупреждение със заглавие „ИИ агент изпълнява mimikatz“, „обратна обвивка (reverse shell) от инструмент за кодиране“ или „кражба на идентификационни данни“ е било разрешено при проверка като разработчик, извършващ легитимна работа, или като погрешно задействане на модула за откриване. Ще се върнем към тях в секцията за Шум.

Това, което беше реално, е атака, която се възползва от ИИ, вместо да преминава през него: активна фишинг кампания, която използва марки на ИИ като стръв. При множество клиенти, и докато се разширявахме към нови по време на проучения от нас период, наблюдавахме зловредни имейли с теми, свързани с ИИ, включващи най-големите имена в областта на ИИ. Стръвта работи точно защото внедряването на ИИ направи тези марки познати, а техните известия — рутинни. Служителите вече очакват имейли от тези продукти, което е точно това, на което разчита киберпрестъпникът.

Ето няколко примера за инциденти, при които забелязахме изпълнението на инструменти или команди, които обикновено показват реални атаки (или тестове за проникване), но в тези случаи те са били извикани от Claude, Codex и т.н. Затова разследващият трябва също да постави под въпрос защо агентите са стартирали тези инструменти и дали това е било част от реална атака, която е експлоатирала агента.

• Anthropic се използва като примамка в бизнес контекст. В това предупреждение темата на имейла е RE: Anthropic Engagement approval & payment, а анализът казва, че изпращачът се позовава на уж съществуващ договор/фактура с Anthropic, за да изглежда искането за голямо плащане легитимно. Така че Anthropic не е изпращачът или източникът на заплахата, той е част от претекста, използван за подкрепа на историята с измама с фактури.
• Имейл използва фалшива покана за Google/Gemini Ads като примамка, за да изглежда легитимен и надежден. Той се представя като покана за работно пространство, свързана с бизнеса, насърчавайки получателя да се свърже или да се присъедини към това, което изглежда като официална среда на Gemini Ads, но инфраструктурата на изпращача и за отговор (reply-to) не са свързани с Google, а вместо това разчитат на подозрителнияโดмейн gemini-advertisers[.]com, което показва опит за имитация на марка, предназначен да насочи потребителя към злонамерен сайт.
• Имейлът имитира OpenAI („OpenAI Partner Summit 2026“), но произлиза от noreply-zoomevents@zoom.us. Въпреки че URL адресите използват легитимна инфраструктура на zoom.us, съдържанието и процесът на регистрация се използват за придаване на достоверност на измамна покана.

• AI средата за разработка (IDE) Cursor изглежда е преминала от нормална дейност по писане на код към небезопасни действия на ниско системно ниво: докато вероятно е опитвала да завърши задача по отстраняване на грешки или отстраняване на проблеми, агентът е използвал позната техника за извличане на идентификационни данни (MiniDump чрез comsvcs.dll), която може да разкрие тайни от паметта на процеса. Веригата родител-дете Cursor.exe → powershell.exe → rundll32.exe, временните .ps1 скриптове и командите за извличане на памет (memory dump) показват, че IDE инициира автоматизирана последователност от действия, която може да е била предназначена да помогне на разработката, но е направена по начин, който е създал сериозен риск за достъп до идентификационни данни на крайното устройство.

Моделът и при трите си струва да бъде заявен ясно: колкото по-внимателно се вглеждахме, толкова повече „атаката“ се разтваряше в контекста. Това е определящата характеристика на триажа в ерата на AI.

Категория 2: Небезопасна употреба

Около 5,8% от предупрежденията, свързани с AI, са тези, на които смятаме, че трябва да се обърне най-голямо внимание. Тези предупреждения откриват небезопасна употреба на AI инструменти, не непременно компрометиране (все още). Това е моментът, в който даден агент, действайки точно както му е указано и без намесата на атакуващ, прави нещо, което съществено излага на риск организацията или потребителя.

Основният риск са агенти, работещи с флаг за заобикаляне на разрешенията (permission-bypass flag) — опцията, която казва на агента да спре да пита потребителя, преди да действа. Много потребители избират да се доверят на агента, че няма да унищожи машините им или да изпълни опасни команди, но както опитът, а сега и данните ни показват, в много случаи агентите ще опитват и най-вече ще успяват да изпълняват команди, които излагат организацията и потребителя на големи рискове. Струва си да се отбележи, че особено при стартиране на агента с флаг за заобикаляне на разрешенията се препоръчва използването на допълнителни конфигурации (известни още като harnesses), за да се предотврати програмно опитът на агента да изпълнява рискови команди.

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

Други случаи на небезопасна употреба, които разкрихме:

• Обратен тунел (reverse tunnel), отворен от AI IDE: В една от средите AI редактор на код е стартирал PowerShell, който е пуснал ngrok и е отворил именован обратен тунел към публичния интернет, използвайки собствения токен за автентификация на потребителя. Въпреки че намерението е безвредно, това е реален риск и излагане на опасност.
• Агент, извличащ целия keychain на macOS, за да прочете един токен: За да извлече своите съхранени идентификационни данни и тези на облачните услуги, агент е изпълнил security dump-keychain > /tmp/, което записва всяка съхранена тайна във временен файл, излагайки за кратко всички тях.
• Предоставянето на OAuth достъп на AI агенти означава, че служителите могат да споделят чувствителна информация с външни доставчици на услуги. Но освен това, то увеличава риска от неоторизиран достъп до данни чрез инжектиране на подкани (prompt injection) или компрометиран AI профил. Наблюдавахме множество предупреждения за предоставено съгласие за OAuth приложения към ChatGPT в различни организации, събития от типа „първо влизане в ново приложение: OpenAI“ и при един клиент — значителен клъстер от предупреждения за защита на данните при качвания в генеративен AI. Повечето са безвредни. Но това е повърхността, през която корпоративните данни се изпращат към модел на трета страна, и тя е почти невидима за инструментите за крайни устройства.

Категория 3: Шум

Шумът е най-голямата категория с порядък на увеличение, 94,1% от генерираните от AI, и е тази, която пряко определя дали един SOC ще се удави. Шумът тук не е случаен. Той е специфичен и диагностицируем: откривания (detections), написани преди съществуването на AI агенти, които сега се задействат с висока степен на сериозност при рутинна работа на агентите. Това не е нова тенденция в SOC, както Sophos съобщи по-рано.

Най-ясният пример е собственият софтуер на AI доставчиците. Оригиналният инсталационен файл на Anthropic Claude Desktop, потвърден от неговия цифров подпис на кода, задейства основни EDR правила като „Засечени операции на зловреден софтуер за откуп (Ransomware)“ и „Кодирано изтегляне и изпълнение през PowerShell“ при няколко клиенти. Инсталационният файл е легитимен. Откриването описва поведението на инсталатора с терминологията на Ransomware.

Под това стоят фалшивите положителни резултати от поведението на агентите, всички потвърдени при проверка като разработчици, използващи инструментите според предназначението им:

• Обновяването на агент за кодиране и използването му от страна на разработчиците задействаха предупреждение за „Засечени операции на зловреден софтуер за откуп (Ransomware)“. Изпълнимият файл, задействал сигнала, е легитимен, подписан софтуерен пакет. Поведението, което е изглеждало „подобно на откупен софтуер“, е произлезло от нормалната активност на инсталатора Electron/Squirrel и използването на инструменти за разработчици.
• Процес, произлизащ от node.exe, изпълняващ OpenAI Codex CLI агента с --yolo или --dangerously-skip-permissions, задействащ засичания за ClickFix, DisableTools и DLL-инжекция.
• Стандартната автоматизация за разработчици задейства предупреждения от тип „PowerShell създаде възможен обратен TCP shell“. Дървото на процесите съответства на нормална автоматизация за разработчици, а не на реален обратен shell. Родителският процес показва подписан OpenAI Codex изолиран двоичен файл, който е стартирал powershell.exe, който от своя страна е стартирал cmd.exe, python.exe и conhost.exe. Командата PowerShell е в некриптиран текст и показва безобидна оркестрационна логика: проверява портове на localhost на 127.0.0.1, избира наличен порт, стартира Python скрипт от директорията на проекта и записва stdout и stderr в локални лог файлове в директорията с артефакти.

Процентът на фалшиво-положителните резултати е същината на историята. В най-шумните засичания на AI активност, делът на безобидните варира от 77% до 99%. Няколко засичания грешат за генерираното от AI съдържание в повече от четири от всеки пет случая:

Едното изключение потвърждава правилото. Засичането ClickFix е единственият клъстер, който клони към наистина сериозен риск, само 37% безобиден, и това е така точно защото се сблъсква с риска от заобикаляне на разрешения от предишната секция: задейства се при агенти за кодиране, стартирани с --yolo. Дори изглеждащият „реален“ шум се свежда до легитимно използване на AI.

Какво трябва да направят екипите по сигурност

От нашия анализ първата стъпка за всеки SOC е ясна: настройте най-шумните наследени засичания, онези, които се задействат с висока степен на сериозност при рутинна работа на агентите. След това дефинирайте политики за това каква информация може да се споделя с AI платформи на трети страни (както при всяка платформа на трета страна) и, въз основа на тези политики, проактивно търсете флагове за заобикаляне на разрешения, неоторизирани тунели и рискови OAuth права, вместо да чакате да бъдете предупредени.

Втората стъпка е по-трудна, защото засяга самия начин на триаж. Инструментите с AI изпълняват команди на машината на потребителя, с неговите идентификационни данни, като по същество действат от негово име. Поради това сигналите се задействат от действия, приписвани на потребителя, и в много случаи потребителят не е бил наясно, че тези действия са се случили. Преди навлизането на AI, подозрителна активност, изпълнявана на машината на потребителя без негово знание, обикновено показваше висока вероятност атакуващ да е превзел машината. Сега екипите на SOC са изправени пред ново ниво на сложност: първо да определят дали въпросното действие е било изпълнено от AI агент или инструмент.

За да разделите контекста на потребителя от този на агента и да държите агента далеч от идентификационни данни и чувствителна информация, до която той не трябва да има достъп, препоръчваме стартирането на AI инструментите в изолирана среда с ограничен достъп, като например Docker контейнер или виртуална машина. Изолацията ограничава това, до което агентът има достъп, и прави поведението му по-лесно за разграничаване от собствената активност на потребителя.

Какво означава това за SOC

Обединявайки трите категории, оперативната реалност на внедряването на AI в предприятията изглежда така:

• Реални атаки (0.02%): нито една от потвърдените атаки, които разследвахме, не е била извършена от собствените агенти на организацията. Истинската атака, която открихме, се възползва от внедряването на AI отвън, фишинг примамки, изградени върху бранд имена, на които служителите вече се доверяват, а не от самите агенти.
• Рискове за сигурността (5.8%): реални, постоянни и до голяма степен невидими за предупрежденията. Агентите се изпълняват с изключени защити за разрешения, отварят тунели към обществения интернет, разкриват прекомерно съхранени тайни и изпращат корпоративни данни към модели на трети страни. Нищо от това не е инцидент, но всичко представлява уязвимост.
• Шум (94.1%): основният разход. Единичното действие с най-висока стойност, достъпно за повечето SOC в момента, не е ново засичане. Това е настройването на наследените такива, така че разработчик, изпълняващ агент за кодиране, да не генерира сигнал с максимална степен на сериозност.

Неудобният извод е, че внедряването на AI досега не е довело до вълна от пробиви, подпомогнати от AI. То доведе до вълна от предупреждения, малка като дял от общия обем днес, която нарасна 18 пъти за шест месеца и е преобладаващо фалшива, заедно с по-малък, по-тих набор от реални уязвимости, които предупрежденията са склонни да погребват. SOC, който третира всяко действие на агент кактo потенциално проникване, ще се изтощи от фалшиви положителни резултати и по този начин ще има по-малък шанс да забележи ngrok тунела или извличането на данните от keychain, които действително имат значение.

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

За Intezer

Intezer е автономна AI SOC платформа, създадена за решаване на точно този проблем, който тези данни илюстрират: нарастващата пропаст между обема на предупрежденията и капацитета на аналитиците. Вместо да настройва отделни засичания едно по едно, Intezer разследва всяко предупреждение автоматично, прилагайки криминалистичен анализ, за да установи какво всъщност се случва на дадена крайна точка или в имейл, след което предоставя съждение, на което човек може да се довери. Това означава 100% покритие на предупрежденията — включително свързания с AI шум — без SOC да се удави в него.

Ако виждате същата промяна във вашия собствен поток от предупреждения, посетете intezer.com, за да видите как платформата на Intezer се справя с това.

Забележка: Тази статия е експертно написана с принос от Никол Фишбайн, старши изследовател по сигурността и анализатор на зловреден софтуер в Intezer.