В рамках проведения внутреннего аудита информационной безопасности (Red Team) перед нами стояла задача проверить АИС. Обычно на таких проектах ты заранее знаешь, что увидишь. что заказчик выполнил требования Приказа № 117: процессы задокументированы, матрица зрелости заполнена, отчёты уходят в ФСТЭК, CMDB ведёт учёт, SOC дежурит, EDR стоит на каждой машине.

Получив первоначальный доступ под локальной учёткой, мы оказались перед очевидным ограничением: на хосте - Windows 11 и работающий EDR. Любой готовый инструмент или «классический» payload почти сразу улетит в алерт. Вектор не пришлось выбирать - он сложился из доступных легитимных возможностей. Особенность заключалась в том, что мы не пытались выбраться из песочницы (техника T1497 Virtualization/Sandbox Evasion), а наоборот зашли внутрь нее, чтобы спрятаться от средств зашиты хоста.

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

Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.

Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.

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

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

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

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

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

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

Совет про токен в адресе страницы кочует из статьи в статью в одной и той же формулировке: не кладите его в URL, иначе он уедет в заголовке Referer на все сторонние ресурсы, которые подключает ваша страница.

Совет правильный по выводу и неправильный по обоснованию. Через Referer он давно никуда не уезжает. А вот сам токен из URL утекает — просто в других местах, и там его обычно никто не ищет.

Что можно выжать из базовых метрик SOC, если у тебя лапки

Многие руководители начинают день с дашбордов и красивых «бубликов». На них традиционно горят классические временные метрики по заветам NIST SP 800-61: среднее время обнаружения/решения/взятия в работу инцидентов ИБ совместно с общим количеством обработанных инцидентов. Топ-менеджмент всё устраивает – они понятные, линейные и отлично смотрятся в квартальных отчетах.
Но потом внезапно выясняется, что кейсы закрываются по инерции, решения становятся все более поверхностными, а качество расследований тихо уезжает в закат.

Привет, Хабр! Если судить по новостям, то до повсеместного распространения автономного транспорта осталось совсем чуть-чуть: Waymo расширяет парк роботакси в США, Baidu через Apollo Go возит пассажиров в двух десятках китайских городов, а Volvo и Einride готовят автономные грузовики к серийной эксплуатации на автомагистралях. Пилотные проекты идут один за другим, растут показатели безопасности, а инвесторы вкладывают миллиарды. Но время идет, а прорыва все нет и нет.

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

Ситуация из практики любой компании: сотрудник уволился, ноутбук сдал, пароль от гостевой и рабочей сети остался прежним. Формально сотрудник его не знает — вводил один раз при подключении, полгода назад, наизусть не помнит.

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

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

Меня зовут Павел Пушкарёв, я разработчик сервиса по аренде выделенных серверов Yandex BareMetal. Мы с коллегами из Yandex Infrastructure создавали его для пользователей Yandex Cloud, опираясь на накопленный в Яндексе опыт работы с железом, и максимально переиспользовали лучшие практики. 

Я удалил из библиотеки агента навык с вирусом. К этому моменту зараза, которая в нём сидела, уже жила в 10 навыках, написанных самим агентом. После удаления я прогнал ещё 5 задач. Заражённых skill‑ов стало 14.

Это был эксперимент, не инцидент. Закладку я добавил сам, а вместо вредоносной нагрузки в ней была безобидная строка с меткой. Так я проверял свежую атаку EvoMal и вывод меня не порадовал: для агентов, которые пишут себе skill‑ы сами, привычные советы «проверь перед установкой» и «удали опасное» не работают. Расскажу, почему, и покажу весь прогон по шагам.

Доброго времени суток, Хабр! Я ИБтивист Александр, скоро как 10 лет профессионально увлекаюсь информационной безопасностью и применяю свои исследования на практике. Эта статья будет полезна ИТ- и ИБ-специалистам, которые интересуются аспектами логирования (аудита) и мониторинга безопасности в операционных системах семейства Linux. Рассмотрим и сравним классический подход к логированию auditd с осовремененными решениями на базе eBPF – tetragon, kunai, falco и Sysmon for Linux.

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

Эта статья не про конкретные схемы «как разводят» — их пересказывают в каждой новости. Она про механику: что именно происходит с человеком в момент атаки, почему инструктаж почти не помогает и что работает вместо него.

LLM-бум породил не только новые возможности, но и новое поколение атак. За два года мы увидели реальные атаки на агенты: один вредоносный email и Copilot сливает платёжные данные клиентов, одно фальшивое GitHub issue и CI/CD пайплайн скомпрометирован, один тщательно настроенный промпт и AI-агент выполняет удалённый код на вашей машине. Это уже далеко не теория, а зафиксированные исследователями в 2025 - 2026 годах атаки на Microsoft Copilot, OpenAI Atlas, Claude Code и Apple Intelligence.

Атаки становятся изощрённее: злоумышленники маскируют вредоносные инструкции под XML-политики, шифруют в base64, вставляют невидимые символы и даже прячут джейлбрейк в стихи. Встроенные фильтры LLM пропускают до 76% таких атак.

Значит, нужен другой подход - лёгкий, быстрый (чтобы не тормозить агента) и понятный (чтобы вы знали, почему запрос заблокировали). И главное, работающий без вызовов внешних API, внутри вашей инфраструктуры. Потому что в эпоху zero-click атак доверять безопасность облачному провайдеру, который пропускает почти всё, как минимум рискованно.

В этой статье разберем основные виды атак и посмотрим на примере, как выстроить базовую защиту с моделью безопасности OGL-Mini.

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

Наутро у меня на руках оказались подтверждённая критическая уязвимость прошивки, полный административный доступ к роутеру, полученный без единого пароля, черновик отчёта вендору и поданная в MITRE заявка на регистрацию CVE. Из этих четырёх пунктов явно просил я только первый. Остальное агент сделал сам, и сделал корректно. Ни одного изменения конфигурации, координированное раскрытие, классификация CWE и CVSS по методике.

Это история о том, что произошло в ту ночь, что именно он нашёл (класс уязвимости классический и неприятный), как агент провёл меня через процесс регистрации CVE частным исследователем, и почему часть технических деталей я пока намеренно опускаю.

У меня в проекте было четырнадцать копий одного IP‑адреса. По одной в каждом скрипте, который ходит на боевой сервер: деплой, перезапуск сервиса, правка DNS, диагностика почты. Классический копипаст, который живёт до первого переезда.

Переезд случился. Адрес поменялся. Четырнадцать скриптов стали указывать в никуда.

Дальше начинается то, ради чего я это пишу.

Для примера будем использовать наш продукт для просмотра топологии и верификации(EDA) и расскажем, как мы построили его лицензирование.

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

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

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

В этот момент плохо работает модель «один бинарь и проверка лицензии есть или нет».

Привет, хабр. Если вы состоите в более‑менее крупных ТГ сообществах, то наверняка замечали, как время от времени в чатах мелькают боты с предложением установить сомнительный APK. Обычно их мгновенно банит антиспам или админ, и на этом всё заканчивается. Правда, пока сообщение ещё висит, взгляд успевает за него зацепиться, и в голове проскакивает «это очевидно скам, но как оно работает?». У меня эта мысль проскочила в дождливый вечер прошлой пятницы, и вот, неделю спустя, я всё ещё смотрю на четыре домена, куда уходят перехваченные банковские коды, и ожидаю хоть каких‑до действий от уполномоченных компаний, которые были уведомлены об атаке почти неделю назад.

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

За две недели ко мне зарегистрировалось 176 ботов. Я полез разбираться, как они прошли мимо трёх уровней защиты, — и вылез с двенадцатью дырами, к ботам отношения не имевшими: хранимый XSS через JSON-LD, чужие задачи по одному идентификатору, сессия, которую нельзя погасить сменой пароля.

И одна, из-за которой до сих пор стыдно: все мои лимиты по IP обходились одной строкой в HTTP-заголовке. Проверил на собственном проде — сорок запросов, ноль отказов.

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

Или как получить полный доступ к изнанке CPU через скремблирование DRAM — PSP, C6, микрокоду, среде SMM и всему остальному, что не попало на страницы спецификации.

Всё-таки не всегда &x == &x...

Через вмешательство в работу контроллера DRAM можно сделать так, что обращение по определённому адресу будет вести в любую нужную область памяти. skitter-creek-bath-salts изменяет нижние слои структуры памяти, перестраивая трансляцию физический адресов DRAM. Такой скрэмблинг раскрывает защищённые области памяти, в том числе изолированные зоны, которые не видит даже само ядро. Когда ломается трансляция памяти, следом рушатся построенные на ней механизмы безопасности, и мы получаем доступ буквально ко всему.

Привет, Хабр! Будем знакомы — grizzzer, участник различных CTF-команд и независимый исследователь кибербезопасности. В этой статье разберу, как я реализовал критическое событие в банковском сегменте онлайн-полигона Standoff 365 — «Дефейс веб-сервиса ДБО First Partner Bank».

Покажу всю цепочку — от DNS-разведки до эксплуатации уязвимости server-side template injection (SSTI) в шаблонизаторе Pug и финальной подмены текста на главной странице.