Пять раундов дообучения детектора промпт-инъекций, четыре неудачи и только один успешный релиз. Разбираем, как собирать и размечать корпус на реальном корпоративном трафике, почему рост точности может обернуться потерей атак и какие гейты помогают не выкатить регресс в прод. Внутри — реальные метрики, причины откатов и практический процесс релиза модели.
Патч был на две строки: правка в проверке прав доступа. На ревью читается ровно то, что задумано, — апрув, мёрж. Через день выясняется, что проверка не срабатывает, хотя код перед глазами правильный.
На ревью смотрят глазами. Глаз видит символы так, как их нарисовал шрифт, а интерпретатор читает байты. Между этими двумя представлениями есть зазор, и в него помещается логика, которую при чтении кода не видно.
Этим зазором пользуются двумя способами, и оба закрываются одной проверкой.
Эхолот давно перестал быть просто прибором, показывающим рельеф водоёма. Сейчас это многофункциональный дисплей, своего рода мозговой центр лодки или катера, на который возлагается ведение картографии, управление двигателями, радио, подсветка, музыка и даже подача сигналов о бедствии или о человеке за бортом.
При этом безопасность таких важных систем порой оставляет желать лучшего. О том, какие абсурдные ошибки я заметил в прошивке одного из этих приборов и почему проверка подписи на файле обновления ещё не защищает от вмешательства в ПО — под кат.
«Он подписан, издатель известный» — этим аргументом закрывают вопрос про стороннюю программу, которую тянут в сборку или ставят на рабочий компьютер. Возразить с ходу нечем: вкладка «Цифровые подписи» в свойствах файла и правда показывает «Эта цифровая подпись действительна». Случаи, когда вредоносный файл подписан настоящим сертификатом, редки — на них и не рассчитывают. В таких разговорах я обычно зануда.
Подпись действительно кое-что подтверждает. Просто не то, что от неё ждут. Она говорит: «этот файл в момент подписи выпустил вот такой издатель, и после подписи содержимое не меняли». Она не говорит: «файл безопасен», «издатель — тот, за кого себя выдаёт прямо сейчас» и «ключ не украли полгода назад».
Последние две недели ленту заливает одинаковыми заголовками: «с 1 сентября изменения для операторов ГИС». Формулировка удобная и неверная. Точнее, верная процентов на сорок.
Приказ ФСТЭК от 27.02.2026 № 60 переписал не сроки и не методы. Он переписал пункт 3 Порядка аттестации, тот самый, где сказано, к кому этот порядок вообще применяется. Когда меняют список адресатов, «изменения для операторов ГИС» превращается в неточность, из‑за которой кто‑то не прочитает документ, решив, что он не про него.
Разберу, кто там теперь есть.
Разговор о том, кто на самом деле контролирует облако, часто начинается с регионов: где выполняется рабочая нагрузка и где хранятся её данные. Но выбор региона — только часть картины, архитектура платформы значит ровно столько же. Особенно важно, как она разделяет между кластерами ответственность за управление, исполнение, сборку и наблюдаемость.
Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.
Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.
Однажды вечером я, как обычно, листал ленту одного синего маркетплейса и случайно наткнулся на электронный замок со сканером отпечатка пальца. По описанию — почти идеальное устройство за небольшие деньги: биометрия, защита от воды, какая-то «уникальная» микросхема. Звучит убедительно, но исследователь на то и исследователь, чтобы не принимать рекламные обещания на веру, а потому уже на следующий день замок лежал у меня на столе. Ну, а дальше сработал знакомый принцип: где один интересный девайс, там быстро появляется пара других…
Меня зовут Астафиев Денис, я ведущий специалист по аппаратным исследованиям в Бастионе. По работе я регулярно разбираю самые разные устройства, чтобы проверить, насколько можно доверять тому, что производитель обещает на коробке. Сегодня будем смотреть сразу на три замка с биометрией и искать слабые места в их защите.
Сразу оговорюсь: цель этой статьи — не любой ценой «дожать» дешевый китайский замок до уровня лабораторного исследования. Наоборот, мне хочется на простом и доступном примере показать, как обычно строится базовый аудит аппаратной безопасности и почему начинать его стоит совсем не с самых сложных атак.
Что может быть привычнее для разработчика, чем ежедневный ввод команд установки или обновления зависимостей: npm install, pip install, uv add, bundle add, cargo add? Пакетный менеджер находит нужную библиотеку, скачивает её вместе с транзитивными зависимостями и за несколько секунд устанавливает в проект сотни тысяч строк чужого кода. В этот самый момент мы не задумываемся о том, что совершаем серьёзный акт доверия. Мы доверяем автору пакета, его аккаунту, системе публикации, сборочному конвейеру и всем зависимостям, которые пакет подтянет вместе с собой. Бесспорно, большую часть этого кода мы не читали и, скорее всего, не прочитаем никогда. Пока всё работает как задумано, этот процесс остаётся незаметным. Но стоит злоумышленнику скомпроментировать хотя бы одно звено этой цепочки, и обычное добавление или обновление библиотеки превращается в установку вредоносного кода в сотни или даже тысячи проектов.
Именно на этой идее и строится атака на цепочку поставок — supply-chain attacks. Зачастую злоумышленнику не обязательно искать уязвимости непосредственно в вашем приложении, планировать дорогостоящие многовекторные атаки и применять социальную инженерию. Ему достаточно увести учётку разработчика даже не особо известного пакета, добавить бэкдор в новую версию, опубликовать её в тот же npm или PyPi — и вуаля: вот уже вредоносный код отправляет персональные данные ваших клиентов прямиком на серверы хакеров.
Наверное, многие уже видели или хотя бы слышали про цепочки атак, где пользователю показывают красивую фейковую Cloudflare CAPTCHA, а дальше предлагают выполнить несколько действий «для проверки».
Схема далеко не новая. Более того, я вообще не удивлюсь, если кто-то скажет: «Да мы это уже видели». И будет прав. Но, как обычно, старые идеи периодически достают из шкафа, немного перекрашивают и снова пускают в ход.
Вся эта история опять упирается в одну простую вещь — внимательность пользователя. Если человек сам выполнит то, что ему подсунули, дальше защита компьютера уже может не сильно помочь.
Совет про токен в адресе страницы кочует из статьи в статью в одной и той же формулировке: не кладите его в URL, иначе он уедет в заголовке Referer на все сторонние ресурсы, которые подключает ваша страница.
Совет правильный по выводу и неправильный по обоснованию. Через Referer он давно никуда не уезжает. А вот сам токен из URL утекает — просто в других местах, и там его обычно никто не ищет.
Представьте типичный понедельник в отделе ИБ. Политики настроены, фильтрация работает, отчёты зеленые. А потом бухгалтер Марина открывает «счет от поставщика» из письма, пришедшего якобы с адреса директора — и все.
Технически все было сделано правильно. Но фильтрация не сработала — потому что строилась как технический барьер, а не как инструмент управления поведением пользователя. Разница между этими двумя подходами кроется в «все настроено» и «все работает».
Такие сценарии — не исключение. Компании, которые выстраивают контентную фильтрацию только как технический барьер, раз за разом сталкиваются с одними и теми же проблемами. Пользователи находят лазейки, обходят ограничения или просто их игнорируют.
Меня зовут Николай Куликов, руководитель группы сетевой безопасности департамента клиентского сервиса ГК «Солар». За 10 лет работы на стороне заказчика и в десятках пилотных инсталляций зрелой SWG‑системы Solar webProxy я выработал несколько принципов того, как строить контентную фильтрацию так, чтобы она учитывала не только трафик, но и поведение людей за экраном. В первой части — четыре практических сценария политик контентной фильтрации с учетом психологии пользователя на примере Solar webProxy.
Почему пользователь — главная уязвимость
Атаки киберпреступников — осознанные, точечные, целенаправленные. Поведение рядового пользователя в сети — почти всегда хаотичное и импульсивное, а также состоит из набора поведенческих стереотипов, когнитивной эвристики (упрощения восприятия для ускорения обработки информации) при реагировании на информационную перегрузку или большой объем данных в моменте. Именно в этом зазоре происходит большинство инцидентов.
По традиции собрали ежемесячный дайджест ИБ-инцидентов. В этот раз – с поучительными историями ко Дню знаний. Главные уроки августа – не спонсировать хобби из бюджетов компаний, защищать корпоративные системы от ИИ, быть осторожнее с криптовалютой и мириться с ситуацией на рынке труда. Решения задачек со звездочкой – в тексте.
Что можно выжать из базовых метрик SOC, если у тебя лапки
Многие руководители начинают день с дашбордов и красивых «бубликов». На них традиционно горят классические временные метрики по заветам NIST SP 800-61: среднее время обнаружения/решения/взятия в работу инцидентов ИБ совместно с общим количеством обработанных инцидентов. Топ-менеджмент всё устраивает – они понятные, линейные и отлично смотрятся в квартальных отчетах.
Но потом внезапно выясняется, что кейсы закрываются по инерции, решения становятся все более поверхностными, а качество расследований тихо уезжает в закат.
Подробное решение задания, в котором есть многие техники обфускации. Каждую технику я снял и рассказал как.
Есть решение этого таска по трассировке. Я решаю иначе: снимаю обфускацию слой за слоем, чтобы на каждом шаге оставалась работающая декомпиляция.
Пару статей назад я устал возиться с кучей VPN и поставил Xray на роутер. Дома проблема закрылась: все устройства сами ходят куда надо — локальные и российские сервисы напрямую (без лишнего крюка и потери скорости), остальное через мой собственный сервер, реклама режется на лету. Красота.
А потом я поехал. И выяснилось, что весь этот уют остаётся дома.
В отеле — чужой Wi-Fi, которому я не доверяю ни на грамм. Симка в роуминге даёт IP, от которого у банка дёргается глаз, и он на всякий случай просит «подтвердить вход» третий раз за день. Хочется то полностью в туннель, то наоборот напрямую — чтобы пройти captive-портал в аэропорту. Таскать с собой ноутбук ради ssh в роутер — так себе развлечение в очереди на посадку.
Мне нужен был карманный роутер, у которого режимы переключаются пальцем, без веб-морды и SSH. Я взял GL.iNet Mudi 7 (GL-E5800) — и, забегая вперёд, довёл его до состояния «достал из кармана, ткнул нужный профиль на экране, поехал». Семь профилей-тумблеров, сквозной kill switch и даже выход через домашний IP без белого IP дома.
Но сначала — обзор самого железа, потому что на Хабре я его не нашёл, а зверь любопытный.
Знакомая схема защиты от подмены. Сервер кладёт клиенту cookie user=guest&role=reader и рядом — подпись sha256(secret + данные), чтобы клиент не переписал reader на admin. Секрет знает только сервер, поэтому пересчитать подпись под изменённые данные клиент вроде бы не может.
Поломается не сама SHA-256, а конструкция вокруг неё: к данным можно дописать хвост &role=admin и предъявить к нему валидную подпись, не зная секрета вообще. Атака называется length extension, и в статье мы её проделаем на своём же сервере.
С середины июля по сентябрь семьи активно готовятся к учебному году: совершают крупные покупки, регистрируются на новых платформах, оформляют выплаты, покупают ребенку первый смартфон. В этот период мошенническое сообщение не привлекает внимания, так как воспринимается как очередная задача из общего потока. Просьба перевести деньги в чат класса не отличается от остальных похожих запросов за неделю. Поэтому рекомендация «будьте внимательны» не работает: у уставшего человека ограничен ресурс внимания.
Эксперты Positive Technologies и «МТС» совместно изучили основные цифровые риски, с которыми семьи могут столкнуться в период подготовки к новому учебному году, и собрали практические рекомендации, которые помогут защитить аккаунты, устройства, телефонные номера и деньги детей и родителей.
Ситуация из практики любой компании: сотрудник уволился, ноутбук сдал, пароль от гостевой и рабочей сети остался прежним. Формально сотрудник его не знает — вводил один раз при подключении, полгода назад, наизусть не помнит.
На самом деле пароль он унёс: если ноутбук уехал с ним, а иногда и просто потому, что пароль можно было посмотреть в системе одной командой в любой момент.
Специалисты Лаборатории цифровой криминалистики и исследования вредоносного кода компании F6 предупреждают о новой угрозе российскому бизнесу. В августе 2026 года специалисты Лаборатории выявили активность группировки вымогателей, которая называет себя VantaCore. На данный момент известно как минимум о семи жертвах группировки. Суммы запрашиваемых выкупов составляют миллионы долларов.
Исследователи из канадского Университета Торонто на прошлой неделе опубликовали научную работу, в которой продемонстрировали новую атаку на видеоускорители NVIDIA. Атака, получившая название GPUThor, относится к классу Rowhammer, то есть использует многократные обращения к ячейкам оперативной памяти с целью повлиять на соседние ячейки. Таким образом можно изменить данные в областях памяти, изначально недоступных потенциальному злоумышленнику. Наиболее актуален такой сценарий атаки в случае совместного доступа к профессиональному видеоускорителю. Именно поэтому в подобных работах традиционно исследуются устройства NVIDIA, в данном случае модели поколения Ampere A4000, A4500, A5000 и A6000.
По сравнению с предыдущими атаками на подобные устройства, продемонстрированными в начале 2026 года, GPUThor обеспечивает изменение данных в целевых ячейках в сотни и даже тысячи раз чаще. Но самое главное — новая атака в некоторых случаях приводит к двойным и тройным бит-флипам, которые не корректируются системой ECC. Это точно позволяет провести атаку типа «отказ в обслуживании» и теоретически создает условия для атаки с повышением привилегий, даже если коррекция ошибок включена.
