ФРИИ и 🥰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