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

С каждым годом становится всё труднее ответить на этот вопрос. Атрибуция кибератак превратилась в гадание на кофейной гуще. Атакующие используют одни и те же 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-терминала. Когда-то эти маленькие черные коробочки были крепким орешком для хакеров. Однако отвертка, паяльный фен, логический анализатор и, конечно же, пытливый ум исследователя творят чудеса. К тому же сами разработчики и даже регуляторы порой дают в руки исследователям все козыри, будто только и ждут успешного взлома устройств. 

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

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

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

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

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

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

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

Всем привет! На связи Дмитрий Неверов, руководитель направления тестирования на проникновение в Бастионе. Мы профессионально ломаем системы безопасности компаний. Разумеется, с разрешения их владельцев. Расскажу кейс, за который я получил ачивку «Фаворит года по версии жюри» Pentest Awards 2025.

Представьте: крупная инфраструктурная компания с регулярными пентестами, серьезным бюджетом на ИБ и жесткими регуляторными требованиями. Казалось бы, что тут можно сломать? А мы взяли и получили права доменного администратора, начав путь с непривилегированной учетки сотрудника. И никаких бэкдоров или zero-day, только чистая работа с Active Directory.

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

Поздний сентябрьский вечер 2023 года. Вы лениво листаете eBay. Среди обычного барахла попадается странное железо — тяжелые промышленные модули. На платах красуются логотипы Siemens и AREVA. Описание скудное, но профессиональное, цена удивительно доступная.

Перед вами компоненты системы Teleperm XS — цифровой платформы управления ядерными реакторами. Прямо сейчас такое оборудование управляет безопасностью АЭС по всему миру.

Независимый security-исследователь Рубен Сантамарта двадцать лет взламывает всё подряд — от спутниковых терминалов до систем голосования. Увидев эти лоты, он не смог пройти мимо. Купил компоненты и задался вопросом: что будет, если злоумышленник доберется до «мозгов» реактора?

Сегодня мы пройдем его путь и смоделируем реалистичную кибератаку. Сценарий «Кибер Три-Майл-Айленд», который, по расчетам Сантамарты, за 49 минут приводит к расплавлению активной зоны реактора.

Путешествие в сердце ядерного реактора начинается.

Наркоторговец из Южной Австралии Доменико Катанзарати был уверен, что провернул сделку века. Он использовал Anom — свой анонимный защищенный смартфон — для координации поставки кокаина, спрятанного внутри промышленного сварочного аппарата.

Катанзарати был спокоен. Anom считался «Роллс-Ройсом» в мире шифрованной связи, его рекомендовали влиятельные люди из криминального мира. Устройство работало на кастомной операционке, а сообщения шифровались так надежно, что, казалось, никакие спецслужбы не вскроют переписку. «Окей, давай заработаем миллионы», — беспечно писал Катанзарати своему подельнику в защищенном чате.

Когда пришло время забирать «сварочник» из порта, получателей ждал сюрприз: груза не было. Через несколько дней Доменико сообщили: «Ваш груз изъят пограничной службой Австралии». Подельники Катанзарати написали в тот же безопасный чат: «Pigs grabbed him» («Менты его взяли»).

Оказалось, каждое сообщение наркоторговца и его подельников читал специальный агент ФБР Маршалл Мьюз в своем кабинете в Сан-Диего. «Безопасный» Anom был тщательно продуманной ловушкой, которую втайне создало и финансировало Федеральное бюро расследований.

Под катом — подробный разбор операции «Троянский щит», одной из самых изощренных цифровых ловушек в истории, основанный на докладах с DEF CON, внутренних документах и свидетельствах участников по обе стороны зак��на.

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

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

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

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

В этой статье мы разберемся:

• чем отличаются методологии «черного», «серого» и «белого ящика»;

• какую из них выбрать под конкретные риски;

• как подготовиться к тестированию, чтобы не тратить деньги впустую;

• и почему даже «зеленый» отчет сам по себе — не повод выдыхать.

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

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

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

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

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

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