Информационная безопасность

Агентный код вроде Claude Code или Cursor постоянно работает с ключами: читает .env, генерирует конфиги, логирует свои действия. Любой токен, попавший в контекст модели, разумно считать скомпрометированным: контекст логируется, трассируется, из него можно вытащить секрет промпт-инъекцией.

Разбираем практический подход: агент получает MCP-инструмент вместо секрета — 13 методов для выпуска, ротации и отзыва виртуальных пропусков, среди которых намеренно нет операции «прочитать ключ». Конфиги подключения, сценарий pending secret (агент разворачивает бота раньше, чем появляется токен) и честное ограничение: hosted-прокси не может быть zero-knowledge по архитектуре.

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

Первое, что я подумал, - что-то не настроено. Полез в DNS: SPF на месте, ключ DKIM опубликован, подписи ставятся. Запись DMARC тоже нашлась. Всё, что положено, - есть.

Оказалось, что настроено всё правильно и работает как задумано. Просто задумано не то, что от этого ждут, - а в записи DMARC стояло значение, которое ничего не запрещает.

Кодинг‑агент выполняет то, что читает — README, вывод MCP‑инструмента, результат команды. Если там спрятана инструкция, это превращается в реальное действие: curl | sh, утечка секретов, push во внешний репозиторий. Stroq — открытый локальный файрвол, который связывает прочитанное с тем, что агент собирается сделать, и детерминированно блокирует опасное действие до того, как оно случится. Ни облака, ни расчёта на то, что модель сама заметит инъекцию.

После непродолжительных поисков в нормативных недрах обнаружились следующие документы за авторством ФСТЭК России, в которых так или иначе упоминается «искусственный интеллект»:

Можно ли научить детектор атак, ни разу не показав ему настоящую атаку?

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

Потом я выпустил их на настоящие данные: журналы аутентификации Лос-Аламосской лаборатории, 1.65 миллиарда событий, с размеченными учениями красной команды.

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

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

Привет, хабр! Сегодня будем взламывать сезонную машину из уже прошедшего 11-го сезона на Hack The Box. Нам предстоит проэксплуатировать уязвимость NextJS, наделавшую шума в конце 2025 года, крякнуть пользовательский хеш и повысить привилегии через забытый отладочный порт. Интересно? Тогда приступим!

Одна уязвимость, дюжина названий, 321 запись и стенд, за которым конкуренты договорились “дружить”. История создания самого известного идентификатора в кибербезопасности по первоисточникам 1999 года.

Есть такое уютное заблуждение: выключил Wi-Fi и мобильные данные – и все, ты невидимка. Спокойно можно строить теории заговора. На деле всё немного иначе. Даже в полном офлайне встроенные датчики смартфона продолжают исправно работать и копить информацию о том, чем вы занимались. Разбираемся, как смартфоны на самом деле следят за нами без сети, чего стоит опасаться по-настоящему, а что — просто повод для паранойи.

Привет, Хабр!

На связи Дмитрий Ларин, я руковожу продуктовым направлением по защите баз данных, в Гарде.

Маскирование данных — важное направление нашей работы (в продуктовой линейке Гарды даже представлен отдельный продукт для выполнения таких задач). Поэтому нам не привыкать к разнообразным вопросам об этом методе защиты — от банального «зачем вообще нужно маскирование?» до провокационного «почему бы не скормить поиск ПДн нейронке?».

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

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

Итак, поехали.

Я наблюдал ситуации, когда компания формально соответствует требованиям регулятора, регулярно проходит аудиты, имеет утвержденные Политики, настроенные СЗИ, выделенный SOC и несколько сотен страниц Регламентов на случай любой проверки.

Но однажды, после первого инцидента, выяснялось, что:

— Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
— SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
— Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
— Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.

Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.

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

Предлагаю посмотреть на области, которые уже соответствуют требованиям, немного другим взглядом. Рассмотрим MFA, SIEM, управление доступом, DLP и прочие моменты с точки зрения слабых мест бумажной безопасности.

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

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

За агентом всегда есть контур сущностей: скиллы и расширения, MCP‑серверы и их инструменты, модели, машины и эндпоинты, сессии, инструменты вызова (tool‑call), обращения в сеть, граф межагентного взаимодействия.

Если сотрудник с ноутбука вышел за контролируемый перечень ИИ‑моделей и сходил во внешнюю LLM — это тоже событие контура, которое попадает в блок «теневого» ИИ (Shadow AI). Чтобы это было контролируемо — нужно понимать, что происходит на рабочей станции сотрудника. Без агента на хосте остаётся только то, что проходит через шлюз.

Большинство разговоров о сетевой безопасности крутятся вокруг систем, которые стоят на пути трафика и должны принять решение здесь и сейчас: NGFW, WAF, IDS. Но есть и другой класс систем — те, что работают не с самим трафиком, а с его зеркальной копией, и потому могут анализировать происходящее сколько угодно долго. Эта статья — про то, что удаётся увидеть NTA/NDR-системам именно благодаря этому запасу времени: от восстановления цепочки атаки шифровальщика по сохранённым метаданным до обнаружения ботнета, для которого ещё не существовало сигнатуры.

Threat Intelligence — одна из тех тем в информационной безопасности, про которые вроде бы все что-то слышали, но почти каждый понимает по-своему. Для кого-то TI — это просто фиды с IP-адресами. Для кого-то — дорогая платформа, которую «надо купить, потому что так делают все». Для кого-то — модный термин из презентаций CISO.

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

TI — это не просто «база индикаторов», но и не магия

Начнём с самого важного. Да, современный Threat Intelligence давно ушёл дальше примитивных списков IP-адресов, доменов и хэшей. Сегодня существуют TI-платформы, в которых на основе данных об угрозах строятся корреляции, сценарии, гипотезы, а иногда и полноценные обнаружения. В том числе это относится к коммерческим решениям — например, в продукте Security Vision TIP индикаторы используются не сами по себе, а как часть логики анализа и детекта.

Но здесь появляется опасная иллюзия. Кажется, что, если платформа «умеет в детекты», значит, она автоматически понимает, что для нас важно, а что нет. На практике это почти никогда не так. Любой детект, даже самый сложный, всё равно опирается на предположения — о структуре инфраструктуры, качестве логирования, допустимом поведении пользователей, уровне зрелости процессов. И если эти предположения не совпадают с реальностью конкретной компании, TI снова начинает либо шуметь, либо молчать там, где должен был помочь.

Мне в руки попался обычный файл с расширением .vbs. Ничего необычного. Открываю посмотреть, что там внутри, и сначала даже немного разочаровался. Какой-то VBScript, временные файлы, cmd.exe, PowerShell. Ну, думаю, очередной скрипт-загрузчик. Но потом заметил одну деталь. Скрипт читал сам себя. И вот тут стало уже интереснее.

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

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

Хеширование паролей у нас настроено правильно, в базе всё как надо. Просто до хеширования эти строки не дошли: код их паролями не распознал.

В новом релизе Ideco NGFW Novum мы собрали функции, которые обычно приходится искать в разных слоях инфраструктуры: видимость AI-сервисов, развитую динамическую маршрутизацию, QoS и строгую аутентификацию. Разберем задачи, которые релиз закрывает в больших распределенных сетях, ЦОД, на перегруженном WAN-канале и в регулируемом контуре.

AI уже в сети, даже если его ещё нет в реестре ИБ

Shadow AI начинается с обычного рабочего действия: сотрудник открывает чат-бот (а уже наверное и разворачивает агент), разработчик подключает API-модели, аналитик загружает таблицу в ассистент, а инженер запускает локальный inference-сервис для эксперимента. У каждого действия может быть разумная цель, но у ИБ нет ответа на базовый вопрос: какие AI-инструменты реально используются в сети?

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

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

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

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

Всем привет! Меня зовут Сергей Бобров aka BlackFan. Я работаю в Лаборатории Касперского, занимаюсь анализом защищенности мобильных и веб-приложений, участвую в пентестах и редтимах. В свободное время я также разрабатываю собственные инструменты, занимаюсь исследованиями в области безопасности и ищу баги на платформе Standoff Bug Bounty. Сегодня мы разберем на практике мисконфигурации, связанные с объектным хранилищем S3, и углубимся в проблемы, возникающие при его интеграции в веб-приложения через прокси (например, nginx). В основе статьи — 10 лабораторных стендов, каждый из которых поясняет различные уязвимости интеграции: от классической хранимой XSS и подмены бакетов до обхода правила rewrite и отравления кэша. 

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

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

«Кто я?» — вопрос, над которым люди размышляют веками. Но whoami для админа — обычная команда. А для атакующего, который только что нашел OS сommand injection, это буквально первая фраза при знакомстве с сервером. В статье покажем, как из одного слова можно получить 37 196 синтаксически разных вариантов одной и той же команды, а также рассмотрим свежие CVE, связанные с этой уязвимостью.

— Есть Grafana.
— Есть n8n.
— Есть Dockge.
— Есть несколько внутренних админок и staging‑сайтов.

У каждого из них уже есть собственная авторизация. Казалось бы, что ещё нужно?

Но меня долго смущала одна простая вещь: почему форму логина вообще должен видеть весь интернет?