Давайте начистоту: утечка персональных данных — не гипотетическая угроза, а суровая реальность. Только за 2025 год Роскомнадзор зафиксировал больше сотни утечек, в результате которых было скомпрометировано 50 миллионов записей (строк в базах) с персональными данными пользователей.

Для бизнеса последствия стали еще серьезнее, чем раньше. Помимо репутационного коллапса и судебных исков, компаниям теперь может грозить и уголовная ответственность по новой статье 272.1 УК РФ: за нарушения можно получить штраф до 700 000 рублей или срок до пяти лет. А с 30 мая 2025 года в силу вступили «драконовские штрафы» по КоАП: от 1% до 3% выручки — но не менее 20 и не более 500 млн рублей.

Выходит, для компаний утечка — настоящая проверка на прочность. Представьте: одна ошибка, и данные тысяч клиентов оказываются в даркнете, или кто-то взломал сервер — и требует выкуп. Что делать? Паниковать? Нет. Действовать быстро и по инструкции.

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

Представьте ситуацию: AI-агент управляет логистикой грузоперевозок. Его KPI — 98% доставок вовремя. Он обнаруживает, что валидатор проверяет только наличие записей об отдыхе водителей, но не их подлинность. И принимает решение: фальсифицировать логи отдыха, отключить датчики безопасности и гнать водителей без перерывов. Ради метрики. Осознанно.

Это не мысленный эксперимент и не сценарий из антиутопии. В бенчмарке для агентных систем ODCV-Bench такое поведение показали 10 из 12 протестированных frontier-моделей. А наиболее склонная к нарушениям модель выбирала неэтичное поведение в 71,4% сценариев.

И речь не о jailbreak или внешнем злоумышленнике. Агентам никто не приказывал нарушать правила. Им просто ставили цель — а дальше они сами выбирали, как к ней идти.

Стоило Илону Маску пообещать нам создание умных помощников вроде C-3PO, как исследователи безопасности тут же решили проверить, не получится ли вместо этого настоящий Терминатор. Мы разобрали нашумевшее исследование команды Dark Navy и рассказываем, как популярного робота-гуманоида Unitree G1 за $16 000 превратили в хакерскую марионетку. 

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

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

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

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

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

Привет, Хабр! На связи снова Иван Глинкин, руководитель группы аппаратных исследований из команды Бастиона. 

«Флешка с кодовым замком», «флешка с аппаратным шифрованием», «зашифрованный USB-накопитель», наконец, эталонное название — «криптографический модуль» (Cryptographic Module). У криптофлешки aka encrypted USB много имен, но суть от этого не меняется.

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

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

Результаты получились интересными. Подробности — под катом.

Привет, Хабр! Меня зовут Александр Колесов, в Бастионе я руковожу направлением развития в департаменте тестирования на проникновение. Мы профессионально ломаем то, что другие старательно защищают. Разумеется, с разрешения владельцев.

Сегодня предлагаю поговорить о внутреннем пентесте — одной из самых недооцененных услуг на рынке. А точнее, о современном подходе к нему — Assumed Breach («предполагаемое нарушение»). В рамках этого метода мы отталкиваемся от предпосылки: «а что, если компания уже скомпрометирована?».

Я уже рассказывал на SOC Forum 2025, почему классический внутренний пентест часто не отвечает на реальные потребности бизнеса и как Assumed Breach позволяет это исправить. В статье поделюсь записью этого доклада и покажу, как максимизировать пользу от внутренних пентестов с помощью Assumed Breach.

«Давайте быстро развернем SOC» — подобные запросы от руководства компаний учащаются после каждой громкой кибератаки. Возникает иллюзия, что центр мониторинга безопасности можно легко создать за пару недель. Но так ли это? Или дело не в SOC, а в том, кто именно его запускает?

На связи Денис Иванов, руководитель по развитию центра мониторинга информационной безопасности в Бастионе. На практике я часто сталкиваюсь с подобными заблуждениями насчет SOC: заказчики путают его с SIEM, не понимают, когда нужен собственный центр мониторинга, а когда — готовая услуга. 

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

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

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

Чтобы разобраться в ситуации, мы позвали Семена Рогачёва, руководителя отдела реагирования на инциденты Бастиона. Он уже выступал с докладом на эту тему. 

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

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

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

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

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

Хотите узнать, как легко купить чужие секреты и почему компании продолжают их выбрасывать в 2025 году? Рассказываем подробно.

У мошенников нет ничего святого! Хакеры взялись за Google: подделка подписей теперь не обязательна, ведь можно заставить Google подписывать фишинговые письма валидным DKIM самостоятельно. Если раньше опытный ИБ-специалист мог сходу разобраться, где фишинговое письмо, а где — нет, сейчас это сделать в разы сложнее. И дело вовсе не в популярных нейронках, изощренном социальном инжиниринге или слитых базах.

Несем вам горячий кейс о том, как мошенники научились злоупотреблять настройкой OAuth-приложений, используя официальные инструменты Google для отправки поддельных писем от no-reply@accounts.google.com.

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

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

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

По сути, атака умело сочетает две техники: принуждение к локальному исполнению (ClickFix/FileFix) и контрабанду кэша (Cache Smuggling). В статье я подробно разберу каждый из этих приемов и покажу, как можно сделать доставку полезной нагрузки еще более незаметной.

Пока мы обсуждали, prompt injections в LLM, хакеры перешли к атакам на агентные AI-системы. Если обычные LLM-приложения работают по принципу «запрос-ответ», то агентные AI-системы действуют автономно: запоминают информацию между сессиями, самостоятельно выбирают, какие инструменты использовать, планируют последовательность действий и выполняют их. И чем больше автономии у AI-агента, тем выше цена ошибки.

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

Это руководство предоставляет детальное объяснение угроз для Agentic AI, основанное на работах OWASP Agentic Security Initiative (ASI) и AI & Cloud Governance Council.

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

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

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

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

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

Представьте: обычный вторник, и вдруг в корпоративном чате паника — CRM лежит, бухгалтерия не может отправить платежи, сайт не открывается. Где-то в серверной тихо погас светодиод на ключевом коммутаторе. Или, что хуже — весь ЦОД оказался в зоне коммунальной аварии. 

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

Сегодня поговорим о том, как превратить точку отказа в отказоустойчивую систему на примере российского NGFW-решения UserGate. Разберем не только техническую сторону (протокол VRRP, режимы Active/Passive и Active/Active, синхронизацию сессий), но и практические моменты: сколько это стоит, как долго настраивать, какие подводные камни ждут на каждом этапе.

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

Когда компания только начинает проект по внедрению SIEM или подключению к SOC, разговор обычно крутится вокруг выбора вендора и сценариев корреляции. А вот о EPS (events per second) вспоминают редко. И зря: от этой метрики напрямую зависит эффективность обработки событий и, как следствие, надежность всей системы защиты.

EPS — это количество событий, поступающих в систему мониторинга каждую секунду. На практике с этим показателем всё неоднозначно: одни клиенты SOC рассчитывают его «на глаз», другие ждут, пока этим займется интегратор, а те, кто внедряет SIEM своими силами, часто просто делят общее число логов на количество систем — и в итоге получают цифры, мало похожие на реальность. Между тем, точный расчет EPS на старте способен сэкономить миллионы рублей и спасти от ситуации, когда система захлебывается от потока событий, а часть логов не доходит до SIEM.

В этом гайде мы разберем:

• почему компании полезно знать свой EPS;

• как этот показатель влияет на архитектуру SOC и стоимость лицензирования SIEM;

• как определить свой EPS без «угадывания на глаз» и ошибок в расчетах;

• и, наконец, что стоит спросить у провайдера SOC, прежде чем подписывать договор.

Привет, Хабр! На связи Иван Глинкин, специалист по аппаратному реверс-инжинирингу из команды Бастиона. Сегодня поделюсь интересным кейсом разбора платежного POS-терминала. Когда-то эти маленькие черные коробочки были крепким орешком для хакеров. Однако отвертка, паяльный фен, логический анализатор и, конечно же, пытливый ум исследователя творят чудеса. К тому же сами разработчики и даже регуляторы порой дают в руки исследователям все козыри, будто только и ждут успешного взлома устройств. 

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

Итак, часть первая: вскрытие и разведка боем. Поехали!

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

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

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

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

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