ИИ‑агенты: обнаружить нельзя контролировать. А запятую ставьте сами)

Коллеги из BI.ZONE разобрали локальных ИИ‑агентов с позиции SOC и EDR. Запрет в политике и отсутствие записи в CMDB не означают, что в инфраструктуре нет Codex, Claude Code, Cursor и других агентов. CLI‑утилиты, расширения IDE и пакеты часто появляются раньше корпоративных правил.

Сильная часть исследования — модель обнаружения. Одной сигнатуры процесса недостаточно: бинарник можно переименовать, агент может работать через node, python, контейнер или SDK. Поэтому авторы сопоставляют установленное ПО, дерево процессов, конфигурации, сетевую активность и подключения MCP. В кейсе с Kimi Desktop агент после неудачи с PsExec перешёл к Impacket и построил цепочку, похожую на горизонтальное перемещение.

Но фраза «EDR помогает взять агентов под контроль» требует оговорки. EDR прежде всего обнаруживает присутствие и запуск агента, связывает с ним процессы, DNS-запросы и опасные настройки. Он не управляет логикой агента: не ограничивает доступные инструменты и данные, не проверяет вызов до исполнения и не всегда определяет инициатора — пользователя, автономный шаг, инъекцию промпта или злоумышленника. Остановить процесс средствами реагирования можно, но это не полноценное управление агентом.

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

EDR стоит использовать как слой инвентаризации, телеметрии и расследования. Для реального контроля нужны управляемые конфигурации, песочница, отдельные идентичности и минимальные права, сетевые ограничения, MCP/LLM-шлюз с политиками и журналы вызовов инструментов.

Исследование BI.ZONE

🌚 @poxek | 🌚 @poxek_ai | 📲MAX

OpenAI инсценировала взлом Hugging Face? В истории слишком много белых пятен
#openai #huggingface #анализ #pr

Статья на Хабре разбирает не столько сам взлом Hugging Face во время внутренней кибероценки OpenAI, сколько пробелы в его публичном описании. И это полезная оптика — если не превращать вопросы в готовый вердикт.

Самый предметный из них — воспроизводимость среды. Открытый ExploitGym содержит 869 задач по эксплуатации уязвимостей в userspace, V8 и Linux kernel и предусматривает изоляцию исходящего трафика. В официальном отчёте OpenAI говорится о внутренней среде, где сетевой доступ был ограничен прокси-кэшем реестров пакетов; модели, по утверждению компании, нашли и использовали zero-day в Artifactory, чтобы выйти во внешнюю сеть. Это объясняет, почему описанный инцидент не сводится к публичному набору задач, но не отвечает на главный вопрос: какие внутренние расширения, права и наблюдение за длительными запусками сделали такую цепочку возможной.

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

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

СТАТЬЯ тут

Факты сверены с сообщением OpenAI / репозиторием ExploitGym / позицией METR

🌚 @poxek | 🌚 @poxek_ai | 📲MAX

ФРИИ и 🥰METASCAN запускают акселератор для ИБ-стартапов

Российским командам в сфере ИБ часто не хватает не разработки, а доступа к крупному заказчику: пройти пилот, подтвердить ценность продукта, разобраться с закупкой и довести переговоры до контракта. Под это ФРИИ и METASCAN запустили совместный фонд объёмом 600 млн рублей и его первую инициативу — двухмесячный акселератор.

В него отберут до 20 российских ИБ-компаний с работающим продуктом на стадии MVP или выше, первыми клиентами, пилотами либо выручкой. Инвестиции в один проект — от 5 до 100 млн рублей; участие бесплатное. Уже закрыта одна сделка: 40 млн рублей получил стартап по обучению сотрудников ИБ с выручкой 1,5 млн рублей.

В фокусе — кибербезопасность, DevSecOps, защита данных, антифрод, мониторинг, compliance и security tooling. Приоритетны управление уязвимостями, защита веб-приложений и API, автоматизация ИБ-процессов и ИИ в защите.

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

Заявки принимают до 15 сентября. Старт — 1 октября.

Продолжение моей очень долгой и скучной истории с европейской багбаунти платформой Bugcrowd. Я сдал P2/P3 (High-medium) уязвимость в один очень крупный проект БД. От команды платформы был проведен довольно быстрый первичный триаж за неделю где-то, с учетом что у них не получалось проэксплутировать багу и я им финально уже даже видос записывал, как скачиваю самую последнюю версию ПО, как поднимаю сервис и как запускаю скрипт после чего сервис сворачивается в клубочек. Вопросов к тому что я русский (т.к. У них обязательный KYC для отправки первого отчёта. Я проходил на свой заграник и прошел с первого раза его). После чего команда Bugcrowrd передала меня в руки вендора 8 июня и тут началось ожидание.........










Очень сука долгое ожидание. С 8 по 15 июня я ответственно ждал хоть какого-то пинга со стороны вендора. После чего увидел что есть прекрасная кнопка, как пнуть вендора и мол он заметит. Таких есть 2 волшебных пинга и если вендор в течение 2 недель не отвечает - пинг возвращается. Звучит адекватно и удобно для всех.

В итоге мной было отправлено 3 пинга, после чего я благополучно забыл о баге.

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

В итоге 15 аВгУсТа мне наконец ответил вендор, мол спасибо что подождали, если в течение 2 недель не придет финальный ответ - пингуйте)))
Начислили какие-то 10 points (если кто работает по этой платформе, подскажите что это и на что влияет?)

Как история закончится, постараюсь запросить дисклоз и показать багу.

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

Stay tuned! 🇷🇺

Поправили в комментариях, что Bugcrowd это американская бб, а не европейская

🌚 @poxek | 🌚 @poxek_ai | 📲MAX

Опубликовал новую статью: три месяца внутри двух ханипотов

Я три месяца наблюдал за двумя среднеинтерактивными ханипотами: традиционным стендом под легендой инфраструктуры поставщика промышленного оборудования (SCADA короче) и отдельным AI-шлюзом с интерфейсами, совместимыми с Ollama и OpenAI, и минимальным MCP.

На SSH/Bitrix-стенде накопилось 312 932 сессии. Почти 4/5 сессий после входа выполняли одну команду — чаще всего проверку через uname — и закрывали соединение. Но среди массового шума нашлась длинная цепочка: обход каталогов, чтение конфигурации Bitrix и MySQL, попытка перечислить таблицы и запись PHP-файла в корень сайта. Всё происходило внутри декораций Cowrie; реальная система не выполняла команды.

AI-шлюз показал другой сценарий. Один клиент отправил 27 374 запроса к /api/chat. Медианный промпт занимал 2716 символов, самый длинный меня удивил длинной — 919 294 символов. В запросах были перевод, суммаризация, извлечение фактов, анализ кода и системные инструкции, похожие на шаблоны Claude Code, Codex CLI, OpenCode и Hermes. При этом модели за API фактически не было. Я сделал прикольную штуку, нагенеририл много вариантов ответов и апишка просто читала их из JSON и выдавала готовый ответ но с рандомной задержкой в зависимости от выбранной модели

MCP-клиенты доходили до initialize и tools/list, но не вызвали ни одного инструмента (`tools/call` — 0). Поэтому в статье я разделяю подтверждённую инвентаризацию и предположения об эксплуатации.

Разбираю не только пойманные команды и промпты, но и методику: почему событие не равно атаке, как связывать nginx, логи приложения, JSONL и PCAP, почему публичный отчёт не должен содержать IP, токены, полные промпты и данные, случайно отправленные через открытый API. В конце — требования к защите SSH, самостоятельно развёрнутых AI-систем и MCP: аутентификация, ограничения контекста и вычислений, изоляция инструментов и контроль исходящего трафика.

Читать статью на Хабре

🌚 @poxek | 🌚 @poxek_ai | 📲MAX

Activation Lock и Quick Start: когда миграция данных затрагивает владение

Activation Lock задуман как защита, которая переживает стирание устройства. По документации Apple, после включения Find My состояние блокировки проверяется через серверы активации, а повторная активация требует учётной записи владельца. Apple Support

В полном отчёте от 5 июня 2026 описан кейс на конкретной связке: iPhone 13 с iOS 18.6, заблокированный под чужой учётной записью и помеченный как Lost после фишинга, и iPhone 7 с iOS 15.8.8, привязанный к легитимной учётной записи. По наблюдению автора, после сброса и штатной миграции Quick Start целевой iPhone оказался связан с учётной записью исходного устройства. Повторное стирание завершилось без прежнего экрана Activation Lock.

Сценарий, как утверждается в отчёте, не требовал джейлбрейка, аппаратной атаки или знания пароля заблокировавшей учётной записи. Достаточными условиями были физический доступ к устройству и второй iPhone. Поэтому речь идёт не о «взломе пароля», а о предполагаемой ошибке авторизации в доверенном процессе передачи данных. Quick Start предназначен для переноса данных между устройствами, а не для изменения владельца Activation Lock. Apple Support

Гипотеза автора: сервер мог принять авторизованную сессию исходного устройства за право изменить состояние блокировки целевого, не проверив существующую привязку к другой учётной записи. Разница версий iOS — 15.8.8 против 18.6 — могла задействовать устаревший путь совместимости. Это реконструкция по наблюдаемым признакам, а не подтверждённое описание серверной реализации.

🔗Источник: публичная ретроспектива

🌚 @poxek | 🌚 @poxek_ai | 📲MAX