«В данном случае повреждение памяти в VoIP-стеке позволяло выполнить произвольный код уже во время входящего звонка — достаточно было находиться в контактах жертвы. После захвата аккаунта вредонос мог самостоятельно обзванивать других пользователей и продолжать цепочку заражения, фактически превращая доверенную социальную сеть контактов в механизм распространения атаки», — отметил эксперт.

Жертве не нужно отвечать на вызов, переходить по ссылкам или открывать файлы — достаточно, чтобы звонящий находился в списке контактов. После компрометации червь самостоятельно продолжает цепочку заражения.

Как пояснил Андрей Жданухин, речь идёт не только о переписке: скомпрометированный аккаунт позволяет действовать от имени пользователя, а в экосистеме WeChat присутствуют финансовые инструменты, официальные аккаунты и мини-приложения.

По словам эксперта, для GSOC компании «Газинформсервис» подобные сценарии интересны прежде всего с точки зрения выявления аномального поведения уже скомпрометированных учётных записей. «Сам факт эксплуатации мобильной уязвимости может оставаться незаметным для классического мониторинга, поэтому полезно искать последствия компрометации: резкое изменение модели коммуникаций, массовые исходящие сообщения или звонки, необычную активность аккаунта, появление новых устройств и нетипичные сетевые соединения», — пояснил руководитель группы аналитики L1 GSOC.

Добавим, что разработчики Tencent сообщили, что уже исправили уязвимость для всех пользователей.

А более подробно об актуальных вопросах кибербезопасности можно узнать на ежегодном форуме GISDAYS 2026 (Global Information Security Days*), который компания «Газинформсервис» проведёт уже в девятый раз с 30 сентября по 2 октября в Санкт-Петербурге и Москве.

*Global Information Security Days (GISDAYS) — дни глобальной информационной безопасности

3 сентября Google выпустила обновление Chrome 152.0.7977.82/.83, устраняющее 12 проблем безопасности. Среди них — CVE-2026-85046, уязвимость высокого уровня опасности типа type confusion в движке V8. Компания отдельно подтвердила, что эксплойт для неё уже используется злоумышленниками.

Спустя пять дней, 8 сентября, вышел бюллетень по Chrome 153: релиз включал 230 исправлений безопасности. В их числе — CVE-2026-87491, связанная с записью за границами буфера в V8. Она получила среднюю оценку серьёзности, однако Google также сообщила о существовании эксплойта «в дикой природе».

«Публикация очередной zero day — это напоминание о существовании "окна риска". Эксплойт может уже применяться, в то время как исправление ещё не установлено на всех рабочих местах, а средства обнаружения не располагают полным набором индикаторов. RBI позволяет изменить саму архитектуру доступа: недоверенный веб-код исполняется в одноразовой удалённой среде, а не на устройстве сотрудника. При этом патч-менеджмент, EDR, SWG, DLP и MFA сохраняют свои роли», — подчеркнул Константин Хитрово, менеджер по продукту Ankey RBI компании «Газинформсервис».

Эксперт в области кибербезопасности, менеджер по продвижению продуктов компании «Газинформсервис» Маргарита Белявская добавила, что серия обновлений показывает, что для корпоративной защиты значение имеет не только формальная оценка CVE. Даже уязвимость со средней категорией опасности может потребовать приоритетного устранения, если злоумышленники уже применяют её в атаках.

«Первоочередной мерой после публикации обновлённой версии остаётся обновление Chrome и контроль фактически установленных версий на рабочих станциях. Организациям также необходимо проверять статус обновлений других браузеров на базе Chromium. При этом установка патчей не всегда способна полностью закрыть период между началом эксплуатации уязвимости и установкой исправления на всех корпоративных устройствах. Google указывает, что новые версии масштабируются постепенно, а доступ к техническим сведениям об уязвимостях может ограничиваться до обновления большинства пользователей», — подчеркнула она.

Эксперт добавила, что в подобных случаях — применительно к браузерным zero day — компаниям необходимо прибегать к специализированным средствам защиты, таким как Ankey RBI. «Технология Remote Browser Isolation — удалённая изоляция браузера, применяется как дополнительный уровень защиты веб-доступа. При традиционной модели сайт и его активный код обрабатываются браузером непосредственно на рабочей станции. Средства защиты должны определить вредоносную активность и остановить её до развития атаки. При использовании RBI браузерная сессия запускается в удалённой изолированной среде. На устройство пользователя передаётся графическое представление веб-ресурса, а потенциально опасный JavaScript и другие активные компоненты страницы не выполняются на рабочей станции».

Константин Хитрово отметил, что браузер Ankey RBI работает внутри одноразового контейнера, отделённого от компьютера конечного пользователя и корпоративной сети. После завершения сессии контейнер уничтожается. Таким образом, RBI не исправляет саму уязвимость браузера, но уменьшает зону возможного воздействия эксплойта: атакуемой средой становится удалённый контейнер, а не корпоративное рабочее место.

Эксперты сошлись во мнении, что после сообщений Google компаниям следует проверить версии Chrome на всех управляемых устройствах и обеспечить установку исправлений. Отдельного контроля требуют компьютеры, на которых браузер редко перезапускается, удалённые рабочие места и системы с ограниченным доступом к сервисам обновления.

Для пользователей с повышенными привилегиями, сотрудников финансовых подразделений, руководителей, администраторов, операторов критической инфраструктуры и рабочих мест, с которых регулярно открываются внешние или некатегоризированные сайты, целесообразно оценить удалённую изоляцию браузера как дополнительный эшелон защиты.

Практический подход может предусматривать разделение веб-ресурсов:

∙ внутренние и доверенные корпоративные системы открываются в обычном управляемом браузере;

∙ внешние, неизвестные, некатегоризированные или рискованные сайты направляются в RBI;

∙ загружаемые файлы перед передачей на рабочее место проходят централизованную проверку.

Добавим, что подробнее о решении Ankey RBI эксперты «Газинформсервиса» совместно с экспертами компании Fortis расскажут на вебинаре 15 сентября в 11:00 (МСК). Регистрация уже открыта.

«Наша задача — собрать полный набор решений, необходимых для полноценной защиты компании от внешнего злоумышленника. Где-то мы создаем продукты сами, где-то ускоряем развитие через партнерство со стартапами или уже состоявшимися разработчиками: именно так мы в свое время усилили антивирусное направление, а сейчас делаем ставку на перспективный класс EASM. У CyberOK есть разработки, у которых нет прямых аналогов в мире, и мы видим возможность построить на их основе продукты, конкурентоспособные далеко за пределами России», — отметил Алексей Новиков, управляющий директор Positive Technologies.

Подробнее о сделке читайте в новости на нашем сайте.

@Positive_Technologies

Недавно у нас в гостях побывала съемочная команда «Эйлер — Аналитические Технологии» и нашла столько всего интересного для инвесторов, что выпуск получился в двух частях.

Первая — интервью с Максимом Филипповым, заместителем генерального директора Позитива, — уже вышла и доступна на нескольких площадках: VK Видео, RUTUBE и YouTube.

Говорили о перспективах роста компании и рынка кибербеза в целом, ИИ-технологиях, будущем и настоящем индустрии. Получился живой и очень честный разговор. Советуем смотреть целиком, а если пока не можете, читайте краткое содержание в посте.

О потенциале роста

ЦСР оценивает среднегодовой рост российского рынка кибербезопасности в 20% на пятилетку. Наша цель — расти вдвое быстрее рынка, а если он не растет, минимум на 20%.

Драйверы роста такие: базовый рынок России (95% бизнеса), новые продукты (например, PT NGFW с нижней планкой оценки рынка в 50 млрд рублей и целью — стать номером один), расширение инсталляционной базы внутри клиентов (докупка лицензий на оставшиеся активы), новые способы продаж (enterprise agreement с защитой всей инфраструктуры клиента), международная экспансия.

О финансовых целях

Финансовые планы на 2026 год остаются в рамках гайденса: 40–45 млрд рублей отгрузок. Есть уверенность, что компания попадет в диапазон. А перевыполнить верхнюю планку могут помочь крупные проекты. В прошлом году у нас появились первые чеки больше миллиарда, на горизонте 2026 года их уже несколько. Это показатель зрелости бизнеса и репутации. На 2027 год воронка еще формируется, о ней расскажем позже.

О влиянии ИИ на разработку

Можно сказать, что 2026 год — год реальной революции, когда код перестал представлять некую ценность. Потому что, имея эксперта, который может качественно сформулировать задачу ИИ, пишущему код, вы получите результат в десятки раз быстрее, а зачастую и более качественный.

Поэтому сегодня команды, которые не используют в разработке продуктов возможности искусственного интеллекта, оказываются на задворках истории. Позитиву в этом плане повезло: еще несколько лет назад наш генеральный директор настоял на том, чтобы все тимлиды разработки прошли курсы ИИ, так что мы были готовы.

Об искусственном интеллекте в кибербезе

Парадигма сменилась, и в любой момент государство или бизнес могут оказаться атакованными при помощи ИИ-технологий.

В первую очередь, это автоматизированная история поиска уязвимостей на периметре — чаще злоумышленники пытаются сорвать условные яблоки, растущие на нижних ветках, то есть атаковать ближайшие цели.

Раньше от обнаружения уязвимости нулевого дня до создания эксплойта (возможности ее использовать) проходило, в среднем, трое суток. Сейчас счет идет на часы. Реагировать с такой скоростью не может никто, поэтому атакам ИИ-агентов должны противостоять продукты, в которых также используется искусственный интеллект.

Мы пересмотрели свой цикл разработки и три года назад вложились в создание собственного Security Data Lake, где агрегируем данные для непрерывного обучения больших языковых моделей, интегрированных в наши продукты.

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

О сотрудничестве

Будущее индустрии — за коллаборациями. И тут можно с интересом наблюдать за гонкой технологий, а можно коллаборироваться. И в масштабах страны второй вариант, когда мы можем дать друг другу то, чего недостает у партнера (например, экспертизы, как у Позитива), намного целесообразнее.

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

#POSI
@Positive_Investing

Модератором выступил Григорий Ковшов, руководитель службы маркетинга «Газинформсервиса». В дискуссии приняли участие Дмитрий Овчинников (директор по информационной безопасности UserGate), Сергей Полунин (руководитель группы защиты инфраструктурных ИТ-решений «Газинформсервис»), Даниил Щербаков (заместитель генерального директора Servicepipe), Антон Белоусов (генеральный директор «Киберразведки») и Дмитрий Ляхов (директор по информационной безопасности Сервиса «Грузовичкоф»). Эксперты обсудили пять ключевых направлений трансформации: технологии и архитектуру, людей и компетенции, регулирование, экономику и управление, а также модель защиты.

Больше решений — выше сложность

Рынок решений перегружен, а количество новых продуктов и аббревиатур растёт быстрее, чем появляются реальные кейсы их применения. Как отметил Антон Белоусов, «решений становится всё больше, и фокус смещается на то, чтобы "фильтровать" их и правильно внедрять». Компании начали аудит закупок прошлых лет — выяснилось, что дорогостоящие лицензии используются лишь на 20–30% от их потенциала. Главный вызов сегодня — не приобретение новых средств защиты, а обеспечение эффективной работы уже имеющегося арсенала в условиях распределённых ЦОДов и облачных инфраструктур.

ИИ-ускоритель

Искусственный интеллект сокращает время разработки продуктов с месяцев до дней. Однако, как подчеркнули эксперты, высокая скорость негативно сказывается на качестве безопасности: код создаётся быстрее, чем проходит необходимые проверки, что ведёт к накоплению технического долга. Безопасность должна закладываться на этапе проектирования, а не дополняться отдельными средствами после завершения разработки.

Автоматизация меняет профессию

Автоматизация не уменьшила потребность в кадрах, но изменила требования к специалистам: современный сотрудник ИБ — это профессионал широкого профиля, сочетающий технические, экономические и управленческие компетенции. Дмитрий Ляхов подтвердил: «Автоматизация не отменяет людей в информационной безопасности, она меняет требования к ним. Рутинные операции постепенно уходят в автоматизацию, а ценность специалиста смещается в сторону анализа, управления рисками, архитектуры и принятия решений». Сергей Полунин подчеркнул: «Мы теперь не "коробками" говорим, а считаем риски. Мы пытаемся говорить с бизнесом на их языке». При этом возникла новая проблема — начинающие специалисты теряют возможность получать практический опыт на рутинных операциях, которые теперь выполняются автоматически, что создаёт разрыв в передаче знаний между поколениями. Дмитрий Ляхов добавил: «Нельзя эффективно автоматизировать хаос. Перед автоматизацией процесс необходимо формализовать: описать его, определить контрольные точки, и только после этого переводить его на автоматическое исполнение. Иначе мы не устраняем проблему, а просто начинаем воспроизводить её с большей скоростью». Отдельное внимание участники уделили фишингу: технические средства защиты теряют эффективность, если сотрудник самостоятельно предоставляет доступ злоумышленникам.

От бумаг к деньгам

Регуляторы движутся от формальных проверок к контролю процессов, а бизнес переходит на язык финансов. Инвестиции в ИБ теперь обосновываются не техническими характеристиками, а оценкой ущерба: стоимость простоя, прямые потери от утечки данных, затраты на восстановление. Антон Белоусов добавил: «Хакеры не смотрят на чек-лист. Они найдут пункт посерединке и используют его, даже если в тексте этого не было».

Готовность к неизбежному

Киберстрахование, по мнению участников, является лишь инструментом компенсации последствий, но не заменяет систему защиты. Приоритетом становится готовность к инциденту. Сергей Полунин резюмировал: «Вопрос никогда не ставится как "если вас взломали", это всегда "когда вас взламывают". На что реально стоит направить усилия? В подготовку плана Б, когда всё сломается». Поскольку злоумышленники автоматизируют атаки, а скорость их проведения растёт, компаниям необходимо сосредоточиться на сокращении поверхности атаки, повышении скорости реагирования и отработке планов восстановления.

Подводя итог, модератор Григорий Ковшов отметил масштаб проделанной работы: «Трансформация в информационной безопасности идёт полным ходом. Иллюзий абсолютной защиты нет, есть каждодневная работа по повышению общей киберустойчивости и отстаиванию цифрового суверенитета страны. Это не всегда видно обывателю, но результаты труда наших специалистов впечатляют».

Партнёрами и соорганизаторами конференционной программы выступили ассоциация «РУССОФТ», АБП2Б и другие.

AI-агент способен сам планировать шаги, запускать инструменты и анализировать их вывод. Но без контроля специалиста скорость быстро превращается в поток сомнительных находок и лишних действий.

Проверить эту связку на практике можно на AI-челлендже CyberED × Standoff Hackbase: собрать агента, выпустить его на учебный полигон и сравнить результат с работой человека.

Главная ошибка при внедрении AI в пентест состоит в попытке убрать специалиста из процесса. Модель может быстро обработать большой объём данных, связать наблюдения и предложить следующий шаг. Но она не понимает границы проекта так, как их понимает пентестер. Не несёт ответственности за выполненную команду. Не отличает убедительно сформулированное предположение от доказанного факта, если для этого не заданы строгие критерии.

Поэтому полезный AI-пентестер работает не вместо человека, а внутри процесса, которым человек продолжает управлять.

Где агент действительно экономит время

Лучше всего агент справляется с повторяемыми операциями, результат которых можно проверить.

На этапе разведки он может собрать вывод нескольких инструментов, убрать дубли, привести данные к единому формату и выделить адреса, параметры или сервисы, заслуживающие внимания. Специалисту не приходится вручную просматривать десятки похожих строк, но исходные результаты всё равно остаются доступными для проверки.

Ещё одна подходящая задача связана с подготовкой гипотез. Агент сопоставляет обнаруженные технологии, ответы приложения и результаты предыдущих проверок, а затем предлагает возможные направления анализа. Это не готовые уязвимости, а очередь следующих действий.

Полезно поручать агенту и техническую рутину:

• нормализацию результатов сканирования;
• сортировку и группировку наблюдений;
• поиск повторяющихся признаков;
• подготовку разрешённых команд;
• ведение журнала действий;
• сбор артефактов для воспроизведения;
• создание черновика отчёта по подтверждённым данным.

Во всех этих случаях работа остаётся наблюдаемой. Человек видит исходные данные, понимает, что сделал агент, и может повторить его действия.

Почему высокая скорость ещё ничего не доказывает

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

Если дать ему широкую цель вроде поиска всех уязвимостей, он будет самостоятельно достраивать недостающий контекст. Модель может выбрать неподходящий инструмент, неверно прочитать сообщение об ошибке или принять необычный ответ приложения за подтверждение проблемы.

Чем длиннее автономная цепочка, тем сильнее влияют ранние ошибки. Неверное предположение становится основанием для следующего шага. Затем агент получает новый результат, интерпретирует его с учётом первой ошибки и постепенно строит убедительную, но вымышленную картину.

Со стороны такой отчёт может выглядеть профессионально. В нём будут технические термины, последовательность действий и описание возможного ущерба. Но при ручной проверке окажется, что исходное наблюдение ничего не подтверждало.

Где агент начинает выдумывать

Обычно проблема возникает не в одном конкретном месте, а на стыке модели, инструментов и плохо описанного процесса.

Недостаточно контекста. Агент видит ответ сервера, но может не знать логику приложения, роли пользователей или условия программы тестирования. Пробелы заполняются наиболее правдоподобным объяснением.

Неоднозначный вывод инструмента. Ошибка соединения, пустой ответ или предупреждение сканера могут быть приняты за признак уязвимости. Особенно если агенту поставили задачу обязательно что-нибудь найти.

Гипотеза превращается в факт. Модель предлагает возможную проблему, а через несколько шагов начинает ссылаться на неё как на уже подтверждённую находку.

Теряется scope. Обнаруженная ссылка или редирект ведут на внешний ресурс, после чего агент продолжает исследование за пределами разрешённой области.

Внешний контент принимается за команду. Страница, файл или репозиторий могут содержать инструкции, адресованные модели. Агент не должен считать их новыми правилами работы.

Это не означает, что агента нельзя использовать. Это означает, что нельзя принимать его уверенность за доказательство.

Посмотреть в эфире, как собирают и запускают AI-агента для пентеста.

Самая опасная часть не модель, а доступные ей действия

Ошибка чат-бота заканчивается неправильным ответом. Ошибка агента может привести к запуску команды, отправке запросов или изменению данных.

Поэтому ограничения должны существовать не только в системной инструкции. Если действие действительно запрещено, его нужно блокировать на уровне среды выполнения.

Рабочая конфигурация предусматривает:

• список разрешённых адресов и доменов;
• минимальные права процесса;
• ограниченный набор инструментов;
• проверку параметров перед запуском;
• лимиты времени и количества запросов;
• блокировку разрушительных команд;
• ручное подтверждение критических действий;
• возможность немедленно остановить выполнение.

Запись в промпте полезна, но она не заменяет технический контроль. Агенту не следует предоставлять возможность выполнить запрещённое действие в расчёте на то, что модель вспомнит об ограничении.

Какие решения должен оставить за собой человек

Специалист нужен не для одобрения каждого безобидного шага. Его внимание требуется в точках, где ошибка меняет уровень риска или качество результата.

До запуска человек определяет цель, scope и разрешённые методы. Во время работы подтверждает активные и потенциально опасные проверки. После получения результата сопоставляет вывод агента с сохранёнными доказательствами.

Для каждой предполагаемой уязвимости должны остаться:

• исходное наблюдение;
• выполненные запросы или команды;
• необработанные ответы инструментов;
• последовательность воспроизведения;
• объяснение возможного влияния;
• условия, при которых гипотеза будет опровергнута.

Если находку нельзя повторить вручную, её нельзя переносить в итоговый отчёт. Красивое описание не компенсирует отсутствие доказательств.

Как понять, что агенту уже можно доверить задачу

Начинать лучше с короткого рабочего цикла. Агент получает одну техническую задачу, формулирует проверяемую гипотезу, выбирает разрешённый инструмент, выполняет безопасную проверку и сохраняет результат. После этого он объясняет, что узнал и почему предлагает следующий шаг.

Конфигурацию можно постепенно усложнять, если агент:

• соблюдает заданный scope;
• не запускает запрещённые инструменты;
• останавливается перед критическими действиями;
• сохраняет исходные артефакты;
• явно обозначает неопределённость;
• не выдаёт гипотезу за подтверждённую проблему;
• позволяет человеку воспроизвести результат.

Протестировать такой процесс можно на общем полигоне AI-челленджа. Участники собирают агента, проверяют его на практике, дорабатывают конфигурацию и сравнивают свой подход с прохождением эксперта.

Хороший AI-пентестер не пытается изображать автономного хакера. Он снимает рутину, помогает быстрее проверять гипотезы и оставляет специалисту решения, для которых нужны контекст, ответственность и профессиональное сомнение.

Представим обычное утро. Сотруднику университета приходит письмо: «Срок действия учётной записи заканчивается. Подтвердите данные, чтобы не потерять доступ». Ссылка ведёт на страницу, похожую на университетский портал. Логин и пароль введены. Для сотрудника письмо закончилось. Для атакующего всё только начинается.

Скомпрометированная почта может дать доступ к переписке, документам, внутренним сервисам и механизмам восстановления паролей. А с аккаунта реального сотрудника можно отправлять новые фишинговые письма уже от его имени. Поэтому почтовая инфраструктура вуза – это одна из точек входа в инфраструктуру.

Университет открытая среда. И это проблема

Вузу сложно построить цифровую крепость с подъёмным мостом. Тысячи студентов и сотрудников, десятки корпусов, общежития, гостевой Wi-Fi, личные ноутбуки и смартфоны, подрядчики, внешние сервисы. При этом внутри: персональные данные, научные разработки, финансовая информация и системы, от которых зависит учебный процесс. Для образования такая открытость необходима. Для ИБ довольно неприятная вводная.

По данным отраслевых исследований, российские университеты сталкивались с DDoS-атаками и бот-активностью во время приёмных кампаний, когда нагрузка на цифровые сервисы особенно высока. Речь могла идти о десятках тысяч запросов в секунду. Но DDoS далеко не единственный сценарий. Фишинг, кража учётных данных, ransomware, социальная инженерия и атаки через внутренние системы – всё это может начаться с одного пользователя и одной неудачной минуты.

Один аккаунт и дальше как повезёт...

Самая неприятная часть начинается после первоначального доступа. Если в инфраструктуре плохо настроена сегментация, избыточны права или критичные системы связаны между собой слишком тесно, одна украденная учётка может стать отправной точкой для дальнейшего продвижения. Сначала почта, потом внутренний сервис, затем ещё одна учётная запись. А дальше атакующий уже ищет, куда можно двигаться внутри сети. Именно поэтому вопрос для ИБ вуза сегодня звучит не только так: «Как не пустить атакующего внутрь?» Нужно задавать второй вопрос: «Что он сможет сделать, если всё-таки попадёт?»

Это уже разговор про сегментацию, MFA, минимально необходимые права, контроль привилегированных учётных записей и мониторинг подозрительной активности.

Почта – отдельная линия обороны

Фишинговое письмо нельзя рассматривать исключительно как проблему пользователя. Да, сотрудник должен уметь заметить подделку. Но рассчитывать только на его внимательность примерно как строить защиту объекта на надежде, что никто не забудет закрыть дверь.

На стороне почтовой инфраструктуры нужны свои уровни защиты: фильтрация отправителей и ссылок, выявление подозрительного содержимого, проверка подмены адресов, карантин, а также возможность ретроспективно найти уже доставленные вредоносные сообщения.

А если сотрудник всё-таки ввёл данные, дальше должны сработать следующие механизмы: MFA, контроль входов, мониторинг аномальной активности и быстрый отзыв скомпрометированных доступов.

В актуальных требованиях к защите электронной почты ФСТЭК отдельно рассматриваются меры против фишинга и вредоносных сообщений. То есть задача – не дать одной ошибке превратиться в полноценный инцидент.

А ещё есть классический ИБ-зоопарк

Вуз – это редко одна аккуратная система, которую спроектировали с нуля и дальше только обновляли. Обычно это десятки сервисов, интеграций и решений, которые появлялись в разное время и по разным причинам. Где-то старое ПО, доступы выдавались «на всякий случай», сегментация есть на схеме, но не совсем так работает в жизни. Где-то студент подключается со своего ноутбука, который никто никогда не видел. А где-то критичная система продолжает работать, хотя документация по ней последний раз обновлялась несколько лет назад.

Получается знакомый ИБ-зоопарк: NGFW есть, антивирус есть, SIEM есть, доступы как-то контролируются. А что произойдёт во время реальной атаки? Именно такие разрывы между отдельными средствами защиты и общей архитектурой часто становятся проблемой.

Что делать

Начинать с покупки ещё одного продукта не лучший вариант. Сначала нужно разобраться, что именно защищаем и от каких сценариев. Какие системы критичны для учебного процесса? Какие данные нельзя потерять? Какие сервисы должны работать во время приёмной кампании? Что произойдёт при компрометации аккаунта сотрудника? А если заражённым окажется устройство из внутренней сети? После этого уже можно собирать защиту вокруг реальных рисков.

Первое – это сегментация. Студенческий Wi-Fi не должен быть короткой дорогой к критичным системам.

Второе – доступы. MFA, минимально необходимые права и контроль привилегированных учётных записей особенно важны там, где пользователей тысячи.

Третье – мониторинг. Если организация узнаёт об атаке только после звонка пользователя «у меня что-то странное», с обнаружением явно есть вопросы.

Четвёртое – готовность к инциденту. Бэкап сам по себе не является планом реагирования. Нужно заранее понимать, кто изолирует систему, кто анализирует инцидент, кто восстанавливает сервисы и как не пустить атакующего обратно.

Пятое – люди. Фишинг и социальная инженерия продолжают работать именно потому, что атакуют не только технологии, но и привычки пользователей. Поэтому обучение должно быть регулярным и практическим.

Шестое – аудит. Без регулярной проверки инфраструктуры сложно понять, где защита действительно работает, а где есть уязвимые места. Аудит помогает посмотреть на инфраструктуру целиком, найти уязвимости и ошибки в настройках, проверить доступы и понять, какие риски нужно закрывать в первую очередь.

В «Эгида-Телеком» мы проводим аудит информационной безопасности, чтобы не просто найти проблемы, а понять, что с ними делать дальше: какие риски критичны, что нужно исправить в первую очередь и как выстроить защиту под реальную инфраструктуру вуза.

AI-агент для пентеста — это не автономный хакер, которому достаточно передать адрес цели. Рабочая система начинается с конкретной задачи, ограниченного набора инструментов и правил, не позволяющих агенту выйти за разрешённый контур.

Собрать и испытать такого агента на учебном полигоне можно в рамках бесплатного AI-челленджа CyberED × Standoff Hackbase. А пока разберём, из каких частей состоит минимальная рабочая конфигурация.

Почему одного промпта недостаточно

Обычная LLM отвечает на отдельный запрос. Агент должен пройти последовательность действий: изучить исходные данные, выбрать инструмент, запустить его, обработать результат, сформировать следующую гипотезу и остановиться при достижении цели или возникновении риска.

Для этого ему нужны как минимум:

• чётко сформулированная цель;
• системные инструкции;
• доступ к разрешённым инструментам;
• рабочий контекст;
• критерии завершения задачи;
• ограничения и точки ручного подтверждения;
• журнал выполненных действий.

Без этих компонентов получается не система, а длинный диалог с непредсказуемым результатом. Модель может потерять контекст, повторить уже выполненную проверку, неправильно интерпретировать вывод сканера или уверенно описать уязвимость, которой нет.

Начните с задачи, а не с выбора модели

Сборку агента стоит начинать с чёткого понимания его задачи, а уже затем выбирать подходящую LLM.

Цель провести пентест слишком широка. Она не объясняет, где агенту начинать, какие действия разрешены и какой результат считать достаточным. Первую задачу лучше сделать узкой и проверяемой, например:

Собрать поверхность атаки в пределах заданного домена, проверить полученные адреса разрешёнными инструментами и подготовить список точек для ручного анализа с подтверждающими данными.

У такой формулировки есть границы, понятный результат и возможность проверить качество работы. Для другой конфигурации целью может стать анализ конкретного фрагмента кода, проверка одной гипотезы или подготовка черновика описания уже подтверждённой уязвимости.

Вместе с целью определите критерий завершения. Агент должен понимать, когда задача выполнена, когда информации недостаточно и когда необходимо остановиться и передать управление человеку.

Зафиксируйте scope в системных инструкциях

Агент не должен самостоятельно решать, какие системы ему разрешено тестировать. Scope задаётся явно и не меняется на основании найденных ссылок, редиректов или внешних инструкций.

В системных правилах стоит указать:

• разрешённые домены, адреса и среды;
• допустимые типы проверок;
• запрещённые действия;
• ограничения по интенсивности запросов;
• формат сохраняемых доказательств;
• условия остановки;
• действия, требующие подтверждения оператора.

Например, агент может собирать открытые данные и выполнять безопасные проверки, но обязан запросить подтверждение перед эксплуатацией, изменением данных или запуском потенциально разрушительной команды.

Запрет в промпте — полезный, но недостаточный барьер. Критичные ограничения лучше продублировать технически: изолировать окружение, ограничить сетевой доступ, сократить права процесса и заблокировать опасные команды на уровне политик или хуков.

Разделите работу модели и обычных инструментов

LLM хорошо работает там, где нужно учитывать контекст: интерпретировать результаты, связывать наблюдения, формировать гипотезы и выбирать следующий шаг. Но воспроизводимые операции надёжнее оставлять обычным инструментам и скриптам.

Удобное разделение выглядит так:

• сканеры и утилиты собирают факты;
• скрипты нормализуют и сохраняют результаты;
• модель анализирует данные и предлагает гипотезы;
• оператор подтверждает опасные действия;
• отчёт формируется из проверенных артефактов.

Такой подход особенно полезен на этапе разведки. Агент может обработать большой объём сырого вывода, убрать дубли, выделить потенциальные точки входа и предложить приоритеты. Но исходные результаты инструментов должны сохраняться отдельно: они понадобятся для проверки выводов модели.

Не стоит сразу подключать десятки возможностей. Начните с минимального набора: рабочей директории, средства выполнения разрешённых команд, одного-двух инструментов для целевой задачи и журнала действий. Чем больше инструментов получает агент, тем сложнее контролировать его поведение и разбирать ошибки.

Опишите контракт каждого инструмента

Агент должен понимать не только название инструмента, но и правила его применения:

• для каких задач он предназначен;
• какие данные принимает;
• какой результат возвращает;
• какие действия может совершить;
• при каких условиях запуск запрещён;
• где сохраняются полученные артефакты.

Неоднозначное описание увеличивает риск неправильного вызова. Агент может передать неподходящие параметры, принять ошибку за результат или использовать активную проверку там, где разрешён только пассивный сбор данных.

Переиспользуемые инструкции и сценарии обычно полезнее, чем новый импровизированный промпт для каждой задачи. Они делают процесс стабильнее и позволяют исправить ошибку один раз, а не ловить её в каждом следующем запуске.

После настройки базовой конфигурации её можно проверить на общем полигоне AI-челленджа, где результат агента можно сравнить с собственным прохождением и подходом эксперта.

Подготовьте безопасное окружение

Первый запуск не стоит проводить на рабочей инфраструктуре или цели, ошибка на которой может причинить ущерб. Начинать лучше с простой задачи в изолированном окружении.

Перед запуском проверьте:

• агент работает с минимальными правами;
• секреты не записаны в системные инструкции и файлы журнала;
• сетевой доступ ограничен разрешёнными адресами;
• разрушительные команды заблокированы;
• критические действия требуют подтверждения;
• установлены лимиты времени, запросов и расходов;
• всю последовательность действий можно восстановить по журналу;
• оператор может немедленно остановить выполнение.

Отдельного внимания требует внешний контент. Страница, репозиторий или файл могут содержать инструкции, адресованные модели. Агент не должен воспринимать их как новые правила или разрешение расширить scope.

Не принимайте уверенный ответ за подтверждённую находку

Результат работы агента необходимо проверять так же, как результат сканера или черновик младшего специалиста.

Для каждой находки попросите агента сохранить:

• исходное наблюдение;
• выполненные запросы и команды;
• полученные ответы;
• последовательность воспроизведения;
• объяснение предполагаемого влияния;
• признаки, по которым вывод можно опровергнуть.

После этого специалист повторяет проверку вручную. Если результат нельзя воспроизвести, доказательства не совпадают с описанием или влияние основано только на рассуждении модели, находку нельзя переносить в итоговый отчёт.

Особенно осторожно следует относиться к автоматически подготовленному тексту. LLM может сделать описание убедительным, даже если исходная гипотеза неверна. Поэтому сначала подтверждаются факты и только затем оформляется отчёт.

Когда агент готов к более сложной задаче

Минимальную конфигурацию можно считать рабочей, если агент:

• стабильно соблюдает scope;
• использует только разрешённые инструменты;
• сохраняет проверяемые артефакты;
• останавливается перед опасными действиями;
• отличает гипотезу от подтверждённой уязвимости;
• объясняет, почему выбрал следующий шаг;
• позволяет воспроизвести результат вручную.

Только после этого стоит расширять набор инструментов, добавлять новые сценарии и переходить к более сложным цепочкам действий.

Сборка и проверка ИИ-агента под руководством эксперта

С 10 по 17 сентября участники AI-челленджа CyberED × Standoff Hackbase смогут пройти весь цикл: собрать минимального агента на открывающем вебинаре, испытать его на полигоне, улучшить конфигурацию и сравнить своё решение с прохождением опытного багхантера.

Главный результат здесь не найденный флаг сам по себе, а понимание, где агент действительно ускоряет пентест и где управление всё ещё должен сохранять человек.

Компания Security Vision представила очередное обновление платформы. Релиз расширяет возможности управления хранением и доступом к событиям, автоматизирует обслуживание базы данных, упрощает изменение типов событий и развивает сценарии работы с аналитическими виджетами и настройками Платформы.

Горячее и холодное хранение событий

В Платформе появилась настройка горячего и холодного хранения событий. Для типов событий можно задать период нахождения в горячем хранилище, срок хранения в холодном и последующее удаление. Это позволяет переносить архивные события на более медленные диски и гибко управлять сроками их хранения.

Разграничение событий и алертов в Multitenancy

Доступ к событиям и алертам теперь учитывает организацию пользователя. События и алерты, для которых указана организация, доступны в соответствии с организационной принадлежностью пользователя. Таким образом, механизм Multitenancy распространяется на данные событий и алертов.

Автоматизированное обслуживание базы данных

Добавлены системные настройки для автоматического обслуживания БД Платформы: выполнение VACUUM, перестроение индексов и установка необходимых значений ключевых параметров производительности. Операции обслуживания можно выполнять по настроенному расписанию.

Настройки свойств и форм ввода

В форме ввода свойства типа «Файл» появилась настройка, запрещающая загрузку исполняемых файлов. Для многострочного свойства типа «Строка» с автоматической шириной предусмотрено значение «Не задано», которое возвращает поле к ширине на весь блок карточки. Для форм ввода и вывода свойств также добавлена подсветка синтаксиса кода.

Изменение типов событий без реиндексации

Состав свойств типа события теперь можно изменять без реиндексации хранилища: добавлять новые свойства и удалять существующие. Это упрощает изменение структуры типов событий при развитии модели данных.

Обновление раздела лицензирования

Обновлён интерфейс раздела лицензирования и добавлена отдельная страница с информацией о лицензии. Если лицензия отсутствует или срок её действия завершён, соответствующая главная страница теперь отображается ещё до входа в Платформу.

Развитие интерактивных виджетов

В виджетах добавлены действия, по выполнению которых открываются представления типа «Ссылка на внутренний URL». Также реализована возможность группировать объекты в кластеры по заданным условиям на базе постоянных и динамических значений: входных параметров, переменных и результатов блока.

Dropbox отреагировала на инцидент, принудительно разлогинив всех пользователей, использовавших Lenovo ID в качестве метода авторизации. Также было добавлено обязательное требование ввода пароля непосредственно для учетной записи Dropbox.

По данным агентства Reuters, всего было скомпрометировано около 5 тысяч учетных записей. Только в трети случаев злоумышленники обращались к сохраненным файлам. Из обсуждения на сайте Hacker News, а также со слов представителя Dropbox, можно сделать вывод, что учетные записи с активированной двухфакторной аутентификацией не были подвержены атаке.

Что еще произошло

Исследователи «Лаборатории Касперского» анализируют шпионское ПО ValleyRAT. Его особенностью является маскировка под рекламное ПО (менеджер обоев рабочего стола, который показывает рекламные баннеры). Попутно оно, при помощи техники DLL sideloading, позволяет выполнить вредоносный код от имени процесса с легитимной цифровой подписью.

Еще в одной публикации эксперты «Лаборатории Касперского» разбирают новые инструменты группировки Toy Ghouls.

Свежее обновление браузера Google Chrome закрывает активно эксплуатируемую уязвимость. Проблема с идентификатором CVE-2026-85046 присутствует в движке V8 и может привести к выполнению произвольного кода при открытии веб‑страницы с вредоносным кодом на JavaScript.

Громкая новость недели — в ходе рутинного тестирования ИИ‑агенты компании OpenAI координировали свою работу за пределами контура тестирования. Для этого использовался малоизвестный вики‑сайт DSEWiki, на котором было произведено около 17 тысяч правок.

Разработчики мультимедийного сервера Plex порекомендовали пользователям немедленно обновиться до последней версии ПО. Детали уязвимости, предположительно закрываемого этим обновлением, пока не раскрываются.

Критическая уязвимость обнаружена в популярном плагине All‑in‑One WP Migration and Backup для WordPress. SQL‑инъекция позволяет выполнить произвольный код и получить полный контроль над веб‑сервером.