В Git in Sky мы последние полтора года плотно занимаемся безопасностью AI-контуров: аудируем интеграции, разбираем архитектуру доступов, помогаем командам выстроить нормальный контроль над тем, что происходит между их данными и языковыми моделями.
За 2025-2026 годы произошло достаточно публичных инцидентов с AI, чтобы написать большую статью. И призвать всех, кто работает с AI-решениями, обращать внимание на безопасность.
Когда смотришь на блокировки трафика со стороны пользователя, картина выглядит противоречиво: один и тот же сервис в разных сетях работает по-разному — где-то не открывается вовсе, где-то нестабилен, а где-то продолжает частично функционировать. При этом известно, что управление ограничениями централизовано. Возникает естественный вопрос: если политика едина, почему результат отличается?
Причина в том, что речь идёт не об одной точке контроля, а о распределённой системе, где итоговое поведение формируется на пересечении трёх слоёв: централизованного управления, DPI/ТСПУ как контура распознавания и сети оператора как среды исполнения. Именно эта многослойность и объясняет наблюдаемую неравномерность.
Если коротко: После дефейса сайта нашего знакомого из-за утекшего пароля от админки мы поняли, что управлять доступами нетехнической команды (редакторы, SEO, подрядчики) через VPN или статические IP - это боль. Существующие proxy требовали рестартов и рулились конфигами. В итоге мы написали свой forward-proxy на Go, где доступ выдается токеном через расширение браузера, а правила (TTL, лимиты трафика, доступные домены) применяются на лету без разрыва соединений.
Привет! Я Максим Чеплиёв, менеджер продукта Staffcop, одного из ИБ-сервисов Контура. Расскажу, как мы разрабатываем Staffcop так, чтобы он не нагружал безмерно IT-инфраструктуру клиента. Сразу оговорюсь, что не буду рассказывать о технической реализации на уровне кода, но обращу внимание на уровень архитектуры и стратегических решений.
Ещё пять лет назад Gartner предсказывал, что эксплуатация уязвимостей API станет самым частым вектором взлома приложений и сервисов. Сегодня этот сценарий атак стал практически нормой. Из-за этого API превратились в полноценный бизнес-актив, к которому, по-хорошему, должны применяться те же требования по безопасности и надёжности, что и к любому другому продукту. Однако на практике с этим возникают проблемы.
По данным Salt Security, большинство компаний за последний год сталкивались с инцидентами, связанными с безопасностью API. При этом сами интерфейсы продолжают быстро расти и усложняться, а защита за этим ростом не всегда успевает. В таких условиях даже корректные запросы могут приводить к утечкам данных или обходу ограничений. Особую тревогу вызывает рост ИИ-уязвимостей, где API выступают основным каналом взаимодействия — а значит, и потенциальной точкой атаки.
В статье разберу актуальные техники и тактики атак на API и рассмотрю, какие практики стоит внедрять уже сейчас для защиты веб-приложений.
Юрий Подгорбунский, Security Vision
Введение
Требования к безопасности критической информационной инфраструктуры (далее – КИИ) установлены Федеральным законом от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (далее – Федеральный закон).
Цель Федерального закона заключается в предъявлении требований безопасности для обеспечения устойчивого функционирования КИИ при проведении в отношении ее компьютерных атак.
Основные понятия
Компьютерная атака представляет собой целенаправленное воздействие программных и (или) программно-аппаратных средств на объекты КИИ, сети электросвязи, используемые для организации взаимодействия таких объектов, в целях нарушения и (или) прекращения их функционирования и (или) создания угрозы безопасности обрабатываемой такими объектами информации.
А компьютерный инцидент – это факт нарушения и (или) прекращения функционирования объекта КИИ, сети электросвязи, используемой для организации взаимодействия таких объектов, и (или) нарушения безопасности, обрабатываемой таким объектом информации, в том числе произошедший в результате компьютерной атаки.
Остальные основные понятия в статье будут рассматриваться ниже последовательно.
Что же такое КИИ?
В целом КИИ – это объекты КИИ, а также сети электросвязи (сети операторов связи), используемые для взаимодействия таких объектов.
А сами объекты КИИ — это следующие системы и сети:
Иногда доступ во внутреннюю сеть — это не начало атаки, а тупик. Именно в такой ситуации я оказался в самом начале.
Всем привет! Продолжаем разбор одного из интересных кейсов по тестированию на проникновение, в котором мне довелось принять участие. Первая часть уже опубликована у моего коллеги и посвящена компрометации внешнего периметра, поэтому здесь я сосредоточусь на том, что происходило дальше — внутри локальной сети.
Кратко напомню отправную точку: в ходе тестирования внешней инфраструктуры заказчика нам удалось получить доступ во внутреннюю сеть через туннелирование. Чтобы не дублировать материал, отмечу лишь, что схема была реализована по подходу, описанному у моих друзей из компании «Deiteriy Lab» в статье - https://habr.com/ru/companies/deiteriylab/articles/920064/. Способ отличный и полностью рабочий, советую взять на вооружение. Для общего представления приведу схему подключения, которую мы использовали (так же взята из статьи).
Привет, Хабр! В этой статье я хочу поделиться опытом проведения внешнего black-box пентеста и разобрать методологию, которая позволяет находить критические уязвимости даже при минимальном входном скоупе. Статья будет разбита на две части, про внешний расскажу я, а про внутренний расскажет мой коллега.
Black-box подразумевает, что у пентестера нет никакой внутренней информации: ни списков IP, ни учётных данных, ни описания архитектуры. Только доменное имя - и вперёд. Звучит как ограничение, но на практике это зачастую преимущество: вы смотрите на инфраструктуру глазами реального злоумышленника.
Целью данного пентеста является проверка возможности компрометации внутренней инфраструктуры через веб-приложения.
Хабр, привет! На связи Алина Байрамова, аналитик-исследователь угроз кибербезопасности R-Vision.
В этой статье я разберу уязвимость нулевого дня в TrueConf Server (CVE-2026-3502), связанную с механизмом обновлений, и то, как она может быть использована для компрометации изолированных инфраструктур через доверенный канал распространения ПО.
Привет, Хабр!
Я Ирина Слонкина из отдела безопасности распределенных систем, Positive Technologies. Вместе с коллегами исследую безопасность смарт-контрактов и блокчейн-приложений. Конечно, всегда интересно вникнуть вглубь каждой технологии, вышедшей на рынок. В этой статье я расскажу про криптографический протокол PLONK, один из самых интересных протоколов в блокчейн-индустрии.
С момента появления PLONK ценят за компактные доказательства, быструю верификацию и многоразовую обновляемую доверительную настройку, поэтому в наши дни он широко используется в различных приложениях. Тем важнее исследовать его безопасность.
Одноразовые алиасы скрывают основной почтовый ящик и надёжно защищают от спама через включение/отключение алиасов, которые засветились у спамеров.
Оригинальный hosted-сервис Addy.io (AnonAddy) предоставляется как платная услуга. Хотя есть бесплатная версия, но она работает с ограничениями. При этом исходный код сервера открыт, так что его можно установить на VPS и использовать без ограничений — со всеми функциями платной подписки и без ограничений трафика.
В статье рассматриваются избранные места SHA-3 стандарта, относящиеся к анатомии кечак-функции (KECCAK) и, частично, к структуре губчатой функции (sponge function). Не затрагиваются многие другие части стандарта, в частности, описывающие функции с расширенным выходом SHAKE, RawSHAKE.
Стандарт FIPSPUB 202 определяет Secure Hash Algorithm-3 (SHA-3) как семейство функций, оперирующих бинарными данными. Каждая из функций основана на кечак-алгоритме (KECCAK algorithm). Семейство включает четыре криптографические хэш-функции SHA3-224, SHA3-256, SHA3-384, SHA3-512 и две функции с расширенным выходом (extendable-output function, XOF) – SHAKE128 и SHAKE256.
Статья будет без ИИ мусора и прочего пустословия. Обсудим способы выживания на операционной системе Android в тяжелых условиях.
Авто — идеальный полигон для экспериментов программно-аппаратного хакера. Здесь вам и реверс-инжиниринг прошивок IoT устройств, и подключение к портам дебага, и взлом беспроводных сетей, и радиохакинг. Но самое интересное начинается, когда все эти направления пересекаются в одном исследовании.
На связи Иван Глинкин, руководитель группы аппаратных исследований из команды Бастиона. Сегодня займемся реверс-инжинирингом штатного ключа автомобильной сигнализации (key fob) китайского JAC JS4, известного в России как Москвич 3. Этот китаец с русским именем за несколько лет уверенно прописался на наших дорогах, но в инфополе до сих пор нет информации о его тестировании на стойкость к взлому.
Итак, вызов принят! Мы проведем детальное исследование компонентной базы брелока, изучим его внутренности, просканируем эфир с помощью SDR, постараемся выявить плавающий код (hopping/rolling code) и наметим несколько векторов атаки.
Субботний день 24 октября 2020 года выдался дождливым, ветреным и довольно прохладным — впрочем, такую погоду можно назвать типичной для осеннего Хельсинки. Люди прятались от промозглой сырости в уютных кафе и ресторанах, пили горячий чай и глинтвейн, стараясь отдохнуть за выходные от насущных дел. Внезапно их мобильные телефоны — практически одновременно, с разницей в секунды — начали оживать, сигнализируя о пришедших по электронной почте сообщениях. Студенты, политики, учителя, врачи, водители, и даже безработные вглядывались в экраны с тревогой и ужасом. Эти люди никогда раньше не встречались и никогда не увидятся в реальности. У них не было ничего общего — кроме одного: несколько лет назад каждый из них зашел в кабинет психотерапевта известной сети центров психологической помощи Vastaamo и закрыл за собой дверь. То, что они говорили за той дверью, должно было навсегда остаться там же. Но теперь неизвестный хакер утверждал: он располагает всеми записями этих сессий, включая имена, даты и самое главное — подробные признания пациентов. Двести евро в биткоинах — и похищенная информация не будет опубликована в общем доступе. На раздумья — двадцать четыре часа. Время пошло.
После не совсем удачных экспериментов с публикациями на площадках общего назначения приходится вновь возвращаться к теме описания собственных шифров, наиболее значимыми из которых считаю ESCK-7 и Seal. Оба шифра являются родственными и отличаются только некоторыми деталями, потому основное описание предполагается посвятить шифру ESCK-7, а для Seal указать только принципиальные различия.
От криптоанализа к AI-forensics
Мы привыкли считать LLM «чёрным ящиком»: дал промпт — получил ответ. Максимум — подкрутил fine-tuning или LoRA и надеешься, что стало лучше. Мы пошли в другую сторону. В предыдущей статье я показал, что подписи Schnorr / MuSig2 можно разобрать до уровня строгих affine-инвариантов и работать с ними как с математической системой, а не как с магией. В этой работе мы сделали следующий шаг: перенесли ту же exact-методологию внутрь нейросети.
Что мы сделали? Мы взяли локальный MLX-дистрибутив:
gpt-oss-20b-TurboQuant-MLX-8bit
и не стали его «обучать заново». Вместо этого: вскрыли .safetensors на уровне квантованных кодов; построили детерминированный calibration cache; начали снимать реальные BF16-активации с конкретных слоёв; свели задачу к локальной integer-оптимизации квантованных весов; реализовали безопасный patch прямо в модель; и добавили smoke-check, который проверяет: совпадает ли наша математика с реальным runtime MLX.
Что получилось
Мы впервые получили pipeline, в котором: квантованный слой наблюдаем; его поведение измеримо; его можно локально корректировать; и самое важное - можно проверить, не обманывает ли нас сама среда исполнения. Например: для router.weight мы получили почти полный перенос улучшения на holdout; для q_proj система честно доказала: без внешнего эталона patch не имеет смысла. И это, возможно, даже важнее.
За две недели апреля 2026-го один анонимный исследователь выложил в открытый доступ три рабочих эксплойта против Microsoft Defender. Все три позволяют обычному пользователю без прав администратора получить SYSTEM. Два из них на момент публикации этого текста всё ещё без патча, и Huntress уже ловит их в реальных атаках.
Самое неприятное: в двух случаях антивирус используют не как цель обхода, а как инструмент доставки. Defender сам, со своими SYSTEM-правами, пишет вредоносный файл в C:\Windows\System32 — потому что ему так сказали.
Ниже — что именно произошло, почему это работает и что с этим делать, если у вас парк Windows-машин.
Развитие цифровых сервисов, облачных платформ, распределённых корпоративных систем и API-инфраструктуры приводит к существенному усложнению задач обеспечения информационной безопасности. В современных условиях защита информации уже не может ограничиваться только периметровыми средствами, такими как межсетевые экраны и системы фильтрации трафика. Существенное значение приобретают механизмы идентификации субъектов доступа, централизованного управления правами, а также мониторинга и аудита действий пользователей и сервисов.
Одним из перспективных подходов к решению указанных задач является внедрение систем класса Identity and Access Management (IAM), обеспечивающих централизованную аутентификацию, авторизацию и управление учётными данными. Среди свободно распространяемых решений данного класса важное место занимает Keycloak - платформа с открытым исходным кодом, предназначенная для организации единого входа, федерации пользователей и управления доступом на основе стандартных протоколов безопасности.
Актуальность применения Keycloak обусловлена тем, что данная система позволяет унифицировать процессы аутентификации в гетерогенной ИТ-среде, обеспечить поддержку многофакторной аутентификации, интеграцию с LDAP/Active Directory, а также централизованное управление ролями и политиками доступа. При этом архитектурные особенности внедрения Keycloak требуют отдельного анализа, поскольку речь идёт о критически важном компоненте сетевой системы защиты информации.
Место Keycloak в архитектуре сетевой защиты информации
Сразу обозначу: это не райтап. Тут не будет пошагового разбора экзамена, спойлеров по машинам или каких-то секретных техник. У меня нет красивой истории про призвание, мечту всей жизни или про то, как я с детства шёл именно к этому. Мне просто нравится становиться сильнее в том, что я делаю, и видеть, как это даёт результат.
Это скорее мой личный взгляд на HTB CWES (Certified Web Exploitation Specialist): почему я вообще туда пошёл, как проходило обучение, что чувствовал на экзамене и какие выводы для себя сделал.
Отдельный интересный вопрос — как вообще всё это успевать, когда у тебя работа, семья, дети и собака, которой тоже почему-то всегда что-то нужно именно в тот момент, когда ты сел спокойно позаниматься. Думаю, многим эта история знакома.
Если говорить честно и не быть лицемером, моя основная мотивация довольно простая — это деньги 😂. Деньги через рост в карьере, через опыт и усиление как специалиста. Чем ты сильнее в профессии, тем больше у тебя возможностей: интереснее проекты, выше стоимость на рынке, больше вариантов для роста.