Информационная безопасность *

Мы искали уязвимости в RAG-платформе с десятками тысяч пользователей — а нашли доступ ко всей инфраструктуре и API-ключам с бюджетом в сотни тысяч долларов. Две недели мы строили сложные цепочки: SSRF через LangChain, инъекции в промпты, HTTP smuggling, CVE в десериализации. Ни одна не дала результата. А потом мы сделали один curl к открытому порту — и получили все ключи за 5 минут.

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

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

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

В 2026 для VPN нужна маскировка. А нет никакой лучшей маскировки, чем уже работающий легитимный сервис. Силами NGINX-streams и HTTP2 это сделать довольно легко.

В предыдущей статье "Сканеры ML-моделей: разбор инструментов и некоторых методов обхода их проверок" был представлен обзор основных статических сканеров артефактов ML-моделей. В выводах сканер ModelAudit был выделен как наиболее зрелое решение среди проанализированных конкурентов по следующим критериям:

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

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

- сканирование подмножества моделей из Hugging Face, сериализованных в виде наиболее опасных форматов хранения моделей;
- сканирование таких моделей из Hugging Face, помеченных самими авторами как зловредные (в названии или описании), с последующим сравнением сработок ModelAudit с результатами проверок встроенных в Hugging Face инструментов.

Рендерер Scratch имеет долгую историю связанных с SVG уязвимостей. Их источником становится то, что Scratch парсит сгенерированный пользователем (то есть контролируемый нападающими) контент в элемент <svg> и добавляет его в основной документ для выполнения различных операций (например, для измерения ограничивающего прямоугольника SVG более надёжным образом, чем viewbox или width/height).

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

Я считаю, что подход Scratch к санации SVG обречён на провал. Чтобы объяснить это, нам нужно совершить путешествие по истории санации SVG в Scratch и посмотреть, насколько хорошо он с этим справлялся.

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

У вирусных аналитиков есть небольшая профессиональная трагедия: работать с вредоносами обычно скучнее, чем может казаться по их вычурным названиям. За каждым ShadowSomething RAT/Loader/Stealer почти всегда скрывается один и тот же набор знакомых техник: загрузчик, закрепление в системе, канал связи с C2, немного обфускации «для галочки».

Но иногда попадаются образцы, которые действительно удивляют. В недавнем расследовании нам встретился именно такой. Речь пойдет о PhantomRShell — бэкдоре группировки PhantomCore (Head Mare), атакующей компании из России и Беларуси.

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

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

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

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

Сайт kad.arbitr.ru — предоставляет информацию о гражданских делах, в первую очередь данная информация интересна юристам. Также там можно найти информацию о начале\конце банкротства и много другой информации связанной с юридической составляющей нашей жизни как граждан данной страны. На практике часто возникает задача мониторинга состояния дел по заданному списку — допустим по ИНН или же по ФИО. Именно такая задача была поставлена предо мной, найти дело по ИНН (если оно существует) и открыть его карточку чтобы собрать информацию.

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

Первое, что приходит в голову при решении задачи парсинга по конкретному полю — это использование API.

Возможны три варианта.

DevSecOps по-прежнему часто сводят к подключению сканеров в CI/CD. Дальше сценарий предсказуем: пайплайн замедляется, отчёты копятся, команда теряет к ним интерес. Проблема обычно не в инструментах, а в том, что их внедряют поверх неизменённых процессов.

В статье — о том, как подойти к DevSecOps как к системному изменению: с чего начать, как выбрать пилот, какие цели ставить и где чаще всего всё идёт не так.

Привет, Хабр.

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

Не метафорическая стена. Прям реально стена!

И вот пока я эту функцию ковырял, переименовывал переменные, ходил по ссылкам, открывал соседние функции, смотрел строки, в какой-то момент меня щёлкнуло.

Это же сканворд.

При масштабировании инфраструктуры вчерашние рабочие процессы часто превращаются в архитектурные. Линейный рост затрат на хранение, проблемы консистентности СУБД при восстановлении из снапшотов и зависимость от закрытых API — это реальность, в которой живут многие команды. Ситуация усложняется, когда бэкапы становятся целью для атак, а стандартного контроля доступа оказывается недостаточно. В релизе Хайстекс Акура 4.5 мы собрали инструменты, которые делают инфраструктуру по-настоящему автономной и защищенной. Под катом — подробнее о каждом из них.  

Локально всё работает идеально: политики ловят нарушения, логи пишутся, система стабильна.

В проде Kubernetes‑кластера — теряются события, появляются дубли, а дедупликация ломается от одного скрипта.

Разбираю реальные проблемы, с которыми мы столкнулись при интеграции Tetragon и eBPF в реальный ИБ продукт, и почему Kubernetes ломает наивные предположения.

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

Да, я не занимаюсь какой-то стратегически важной для государства деятельностью. Я не IT-специалист, не создаю новый технологический продукт, не запускаю производство и не строю заводы. Моя профессия это налоговый консалтинг, так как после многих лет, проведенных на службе в ФНС, я не придумал ничего лучше, чем продавать свою экспертизу.

Через Telegram-канал, через посты и статьи я продвигаю себя как автора и как специалиста. Люди приходят, читают мои материалы, начинают доверять. Кто-то обращается ко мне со своими ситуациями, я разбираю документы, консультирую, помогаю оценить налоговые риски и получаю с этого доход.

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

История про совместную работу разработчика и патентного поверенного

Привет, Хабр! Меня зовут Михаил, я руководитель отдела внутренних технических проектов в ГК InfoWatch. 26 апреля прошёл международный день интеллектуальной собственности, так что расскажу вам одну историю по теме. Недавно я принял участие в новом для меня проекте, связанном с патентованием технологии «Система и способ контролируемого доступа к веб-ресурсу», которую я разработал. Опыт оказался интересным, мы получили патент всего за 2,5 месяца вместо стандартных от 6 месяцев до 1,5 лет, поэтому захотелось рассказать о том, какой путь проходит технология от её изобретения до защиты. А именно:

- Зачем вообще защищать инновационные разработки
- Какие задачи можно решить путем этой защиты
- Особенности совместной работы разработчика и патентного поверенного
- Чем для меня оказался полезен этот новый опыт
- И многое другое на примере нашего случая

Впрочем, обо всём по порядку.

К 2028 году в корпоративных средах будет работать 1,3 млрд AI‑агентов, а классическая модель identity по‑прежнему исходит из допущения «один деятель — один человек». Разбираем, что ломается в аутентификации, почему service account и OAuth‑токен больше не закрывают задачу, и как мы в Ideco смотрим на ближайшее развитие средств защиты: непрерывная биометрия для людей и делегированные токены для агентов.

Цифры, которые ломают ИБ‑ландшафт

На RSAC 2026 Microsoft, опираясь на прогноз IDC, заявила о 1,3 млрд AI‑агентов в корпоративных средах к 2028 году (Windows Forum, RSAC 2026, Lantern Studios). Это не «копилоты, которые помогают писать письма» или «чатики» — это автономные исполнители, у которых есть права, токены и доступ к продуктовым системам.

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

Атакующая сторона тоже меняется. В отчёте о кампании GTG-1002 Anthropic зафиксировала первую массовую AI‑оркестрированную операцию: взломанная версия Claude, подключённая к набору MCP‑серверов, выполнила 80–90% тактических операций самостоятельно — разведку, поиск уязвимостей, эксплуатацию, сбор учётных данных, латеральное движение (Anthropic, Disrupting the first reported AI‑orchestrated cyber espionage campaign, Paul, Weiss разбор). Человек был нужен на 4–6 точках принятия решений за всю кампанию.

И последняя цифра, без которой картина неполная. По 2025 Identity Security Landscape от CyberArk (опрос 2 600 ЛПР‑ов в сфере ИБ), на каждую человеческую идентичность в средней организации приходится 82 машинных; 42% этих NHI имеют привилегированный доступ или доступ к чувствительным данным, при этом 88% респондентов всё ещё относят определение «привилегированный пользователь» исключительно к людям. 87% компаний за последние 12 месяцев пережили минимум два успешных identity‑центричных инцидента.

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

В этой статье разбираем, как балансировщик становится точкой принятия решений в сценариях отказоустойчивости — от health checks до переключения между ЦОД — и почему без этих механизмов одной «балансировки» недостаточно.

Самая опасная угроза — внутри

В массовом представлении угроз информационной безопасности главным врагом остаётся внешний хакер. Однако многолетняя практика эксплуатации корпоративных ИТ‑систем показывает более неприятную реальность.

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

За последние пару лет стало особенно заметно: атаки меняются быстрее, чем процессы защиты успевают адаптироваться. Они становятся дешевле, масштабнее и доступнее — во многом за счет ИИ.

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

Конференция Cloud Security Day от Яндекса и SolidLab оказалась не очередной конференцией про облака вообще, а довольно точным срезом того, как рынок ИБ смотрит на 2026 год. На сцене много говорили про гибридную инфраструктуру, импортозамещение, ИИ, атаки на цепочки поставок и защиту учетных данных. В кулуарах разговор был еще прямее: почти никто уже не спорит, что архитектура усложнилась, а окно на спокойную раскачку у компаний сужается.

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