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

Карьера в Innostage: ищем пресейл-архитектора

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

Первая позиция — пресейл-архитектор.

Чем предстоит заниматься

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

В зоне ответственности:

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

• определение ключевых стейкхолдеров проекта, их задач, рисков и потребностей;

• подготовка технико-коммерческих предложений с понятным составом работ, решениями и ограничениями;

• анализ рынка, вендоров и open-source решений для выбора оптимального технологического стека;

• поиск возможностей для развития и расширения проектов;

• техническое сопровождение сделки от первого контакта до заключения договора;

• подготовка презентаций и проведение технических демонстраций для заказчиков;

• участие в отраслевых мероприятиях и конференциях в качестве технического эксперта.

Что нам важно

• Архитектурный бэкграунд. Вы проектировали корпоративные ИТ-инфраструктуры и понимаете принципы их построения, эксплуатации и защиты.

• Экспертиза в информационной безопасности. Знакомы с требованиями ФСТЭК, ФСБ, 152-ФЗ и 187-ФЗ и умеете применять их при проектировании решений.

• Системное мышление. Понимаете ГОСТы и нормативные требования, но воспринимаете их как инструмент для создания работающих решений, а не как набор формальных требований.

• Опыт от 2 лет в ИБ/ИТ. Можете самостоятельно обсуждать технические решения с заказчиком, аргументировать свой подход и представлять результаты работы.

Также важно умение находить общий язык с разными участниками проекта — от технических специалистов и директоров по ИБ до руководителей бизнеса и финансового блока.

Что мы предлагаем

• помощь в адаптации и погружении в работу;

• ДМС, включая стоматологию, телемедицину, психологическую поддержку и ежегодное медицинское обследование;

• страхование от несчастных случаев и страхование при выезде за рубеж;

• возможности профессионального развития: курсы, семинары и доступ к онлайн-библиотеке МИФ;

• частичную компенсацию занятий спортом;

• сообщества сотрудников по интересам;

• социальную поддержку в ключевые моменты жизни;

• официальное трудоустройство;

• имеем аккредитацию в Минцифры.

Если вам интересно развиваться на стыке ИБ, архитектуры и работы с бизнесом, будем рады познакомиться.

По вопросам вакансии: Александра Титова - телеграм @alex_titova, почта Aleksandra.Titova@innostage-group.ru

14 августа была выложена новая версия модели Qwen 3.8 27b и 27b-FP8. 12 августа назад была выложена новая версия модели Qwen 3.8-2.4T-A95B и Qwen 3.8-2.4T-A95B-FP8.

Почему это важно для кибербеза? Семейство квен самое популярное семейство среди моделей на hugging face как по количеству скачиваний так и по использованию для построения\файнтюна своих моделей. Россия в этом плане не сильно отличается от мировых тенденций.

Версия на 27 млрд параметров по общим бенчмаркам способностей находится на уровне GLM-5.2 (max), Deepseek V4Pro 0813, GPT 5.6 Luna. Квантованную до FP8 версию можно попробовать запустить на условно домашней rtx 5090 32 Гб

Версия на 2,4 трлн параметров по общим бенчмаркам способностей находится на уровне Muse Spark 1.2, GPT 5.6 Terra, т.е. можно отнести к SOTA моделям . Эта версия FP8 уже потребует профессиональных минимум 16 видеокарт Nvidia B300.

Как обычно хотелось бы понимать насколько эти модели более защищенная и (или) более способная для задач кибербезопасности.

А тут появляются проблемы, официально у новых моделей нет тех репорта, только карточки на hugging face c ссылками в никуда или на весьма ограниченное описание. Каких либо других независимых отчетов по кибербезопасности и safety мне тоже не удалось найти. В части возможностей самой модели можно с допущениями ориентироваться на тест облачной версии модели Qwen 3.8 Max (как аналога Qwen 3.8-2.4T-A95B) от Aikido:
"Qwen rediscovered 26 of 32 CVEs across three runs, for 81.25% pass@3 recall. That's ahead of GPT-5.6-Sol and matches Opus 5, at roughly half the cost".

Можно попробовать ориентироваться на комплексные бенчи:
Terminal‑Bench 2.1 - навыки работы в командной строке, в том числе для задач кибербезопасности (нахождение и закрытие уязвимостей в коде, реверс-инжиниринг бинарных файлов и безопасная настройка доступов).
DeepSWE 1.1 - бенч для навыков агентов по написанию кода, отдельных разделов по безопасности нет, но это навык смежный с написанием кода.

Значимое отличие - Qwen 3.8 27b единственную из актуальных опенсорс общих моделей можно запустить на одиночном устройстве, особенно если на неофициальном квантовании FP4. Тогда как для "соседей" по бенчмаркам (GLM 5.2, Deepseek V4Pro 0813, GPT 5.6 Luna) потребуется кластер (а иногда и не один) профессиональных видеокарт.

Что на текущий момент является аномальным результатом по соотношению (возможности модели в Terminal‑Bench 2.1)/стоимость оборудования. Соотношение сохраняется в DeepSWE 1.1 и нескольких других бенчах .

Будем ждать новых отчетов по этому семейству, пока Artificial Analysis не включил в бенч по затратам Qwen 3.8 27b, поэтому нужно отнестись сдержанно к получившейся аномальной оценке.

Если у кого то есть локальная RTX 5090 и свободное время - поделитесь впечатлениями ;) .

Эксплойт с молоком

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

Меламин - синтетическое органическое химическое вещество, используемое для создания прочных смол, пластика, ламината для мебели и посуды. Казалось бы, где меламин, и где молоко? Дельфин и русалка... Но...

Как определяют содержание белка в продуктах? В белках есть азот. Извлекают азот или его соединения (для этого варят в кислоте или сжигают), замеряют их и по содержанию азота считают, сколько было белков. Метод не абсолютно точный, может же быть и иной азот в продукте, но его ничтожно мало и можно принебречь.

Можно принебречь так же, как можно принебречь экранированием апострофа в имени пользователя на сайте парикмахерской. (Вряд ли у нас на районе поселится д'Артаньян или Жанна д'Арк). Но если принебрегли - у нас поселится '; DROP TABLE users; --

Если разбавить молоко бесплатной водой - получим много молока. Но его не примут, так как по азотному тесту содержание белка будет слишком низким. А вот в меламине - 66% азота. Добавляем совсем немного дешевого меламина - и белковый анализатор счастлив!

https://ru.wikipedia.org/wiki/Скандал_с_китайским_молоком_(2008)

Мы, конечно, пилим наш продукт в России, но Atmy (ex-Nebo - карта качества воздуха, приложение и датчики) будет жить и за пределами нашей страны.

И перед релизом бета-сайта Atmy мы столкнулись с вполне себе геморройной проблемой - data residency.

С правилами РФ более-менее разберёмся. А вот что делать с SOC2, GDPR и прочими зарубежными требованиями — вопрос открытый. Каждая юрисдикция хочет своё, и универсального рецепта не видно.

Поэтому спрашиваю: как вы сейчас решаете data residency?

▶ Подняли второй Keycloak.
▶ Купили InCountry или Strivacity. Платим $XXk.
▶ Отказались от рынка.
▶ Держим два Auth0 tenants.
▶ Написали свой router.
▶ Ничего не сделали и живём с риском.

Что из этого — про вас? Или есть свой вариант, которого здесь нет?

Telemax: когда не хочешь держать MAX на телефоне, но есть Telegram

Ситуация, знакомая многим: MAX ставить не хочется, а приходится. Работа, знакомые, школьные чаты — и вот у тебя на телефоне живёт приложение, которому ты не доверяешь, и которое работает в фоне тогда, когда ему захочется.

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

Мне хотелось третьего варианта: чтобы MAX вообще не было ни на моём телефоне, ни в моём браузере — а переписка при этом приходила туда, где я и так сижу. В Telegram.

Так появился Telemax — мост между MAX и Telegram.

Что понадобится

• Сервер — любая VPS на Ubuntu/Debian. Требования скромные, хватит самой дешёвой.

• Свой Telegram-бот — создаётся за минуту в @BotFather, токен вставляется при настройке. Бот твой, живёт на твоём сервере, никакого общего чужого бота — данные идут только через твою инфраструктуру.

• Telegram-группа с включёнными темами, куда ты добавишь этого бота админом. Она и станет твоим «окном» в MAX.

• Номер MAX, на который мост авторизуется (в том числе если на аккаунте стоит пароль-2FA).

Про безопасность и доступ — два уровня:

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

• Внутри группы — разграничение. Обычные участники могут читать и писать (можно спокойно добавить людей в группу, чтобы вести общее обсуждение). А вот команды боту — только для админа.

Честная оговорка: тот, кого ты добавил в Telegram-группу, видит там все MAX-чаты, а не один. Так что доступ к самой группе — вещь чувствитвительная.

В ТГ это выглядит так:

• текст, фото, файлы, голосовые, видео и видео-кружки;

• стикеры — и статичные, и анимированные;

• геолокация и контакты;

• опросы — создание и голосование;

• удаление сообщений;

• реакции;

• пересылка (обычным forward в Telegram — прилетает в MAX с пометкой источника);

• уведомления о звонках (входящий / пропущенный / завершённый — текстом, без передачи звука: для аудио нужен WebRTC, это вне рамок).

Плюс мелочи для удобства: веб-панель со статусом и метриками (приватный доступ), самообновление по кнопке прямо из Telegram, авторизация (включая аккаунты с паролем-2FA) без танцев с бубном.

Из интересного: анимированные стикеры ТГ по умолчанию МАХ не принимает, поэтому они конвертируются в короткие видео - можно завалить максчатланинов своими стикерпаками )

Как развернуть

На чистом Ubuntu-сервере — одна команда:

curl -fsSL https://raw.githubusercontent.com/Trollobot/Telemax/main/install.sh | bash

Дальше скрипт сам поставит Docker, склонирует проект, сгенерирует ключи и по шагам проведёт настройку: попросит токен Telegram-бота (создаётся в @BotFather), сам определит id твоей группы, а в конце прямо в консоли спросит номер MAX и код из SMS. Переключаться в браузер для первого запуска не нужно.

Всё, что дальше (сменить номер, посмотреть логи) — через веб-панель по HTTPS.

Честно про ограничения, чтобы никто не питал иллюзий:

• Это не end-to-end. Переписка идёт через серверы MAX и Telegram — как и в любом обычном мессенджере. Мост ничего в этом плане не «шифрует поверх», он просто переносит сообщения. Если тебе нужен E2E — это не сюда.

• Переписка оседает на твоём сервере — в логах и в истории Telegram-группы. Безопасность этого сервера (доступ, шифрование диска) — на тебе.

• Это неофициально. Проект не связан с MAX, работает поверх твоего собственного аккаунта на твой страх и риск, в том числе в части их правил.

• Сыровато. Один разработчик, живой проект. Но у меня самого крутится и работает.

Открытый код и зову тестить

Специально открытый исходник — чтобы можно было посмотреть, что внутри, и гонять на своём сервере, а не на чьей-то инфраструктуре:

github.com/Trollobot/Telemax

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

Рынок VPN — это рынок недоверия. Как я пытался починить его голосами пользователей

Выбор VPN-сервиса устроен хуже, чем выбор почти любого другого софта. Обзоры «Топ-10 VPN» — это партнёрские ссылки, отсортированные по размеру комиссии. Отзывы на агрегаторах пишут сами сервисы. Нейросети уверенно рекомендуют сервисы, закрывшиеся год назад. А проверить самому можно только одним способом — заплатить и попробовать. Классический рынок лимонов: у продавца информации больше, чем у покупателя, и добросовестным сервисам это вредит не меньше, чем пользователям.

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

Почему «свежесть» важнее «качества»

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

Накрутка приходит сразу, как только рейтинг начинает что-то значить

Самая интересная часть — антифрод. Как только каталог начал приводить сервисам пользователей, рейтинг попытались накрутить. Показательный эпизод: 173 голоса за 50 минут с пяти IP за один сервис, причём атакующий проходил SmartCaptcha — то есть капча как единственная линия обороны не работает.

Что сработало — скучная математика на уровне модели данных:

• рейтинг считается по уникальным голосовавшим, а не по числу голосов — повторные голоса с того же пользователя схлопываются;

• малые выборки сглаживаются байесовским средним: сервис с пятью восторженными голосами не обгонит сервис с тысячей смешанных;

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

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

Доверие — двустороннее

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

Что в итоге

Проблема выбора VPN — на самом деле проблема доверия, и решается она не «более честным обзором», а механикой, в которой врать дорого: уникальные голосовавшие, скользящее окно, сглаживание, верификация владельцев. Посмотреть, как это выглядит вживую, можно тут: https://vpn-catalog.online. Про методику подсчёта и антифрод-механику с удовольствием отвечу в комментариях.

Сертификаты минцифры в Firefox Nightly на Android: через adb, без рута

Понадобилось, чтобы сертификату минцифры доверял только Firefox Nightly, а не весь Android.

GeckoView читает /data/local/tmp/<package>-geckoview-config.yaml не только у debuggable-приложений, но и если пакет назначен текущим debug_app. А в конфиге можно задать аргументы запуска Gecko и поднять Marionette.

Поднимаем Marionette

geckoview-config.yaml:

args:
  - --marionette
  - --remote-allow-system-access
prefs:
  marionette.port: 2828

adb shell am set-debug-app --persistent org.mozilla.fenix
adb push geckoview-config.yaml \
  /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell chmod 644 /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell am force-stop org.mozilla.fenix
adb shell monkey -p org.mozilla.fenix -c android.intent.category.LAUNCHER 1
adb forward tcp:2828 tcp:2828

Кладём сертификаты в cert9.db

Marionette в chrome-контексте даёт привилегированный JS, дальше всё делает nsIX509CertDB. Флаг "C,," для корня, которому доверяем по SSL, ",," для промежуточных: доверия им не надо, они нужны только чтобы собралась цепочка.

Протокол простой, длина:json поверх TCP, клиент пишется за пять минут:

use v5.36;
use IO::Socket::INET;
use MIME::Base64 'encode_base64';
use JSON::PP;

my $s = IO::Socket::INET->new('127.0.0.1:2828') or die $@;
my $j = JSON::PP->new->canonical;
my $id = 0;

sub pkt {
    my ($len, $buf, $c) = ('', '');
    $len .= $c while sysread($s, $c, 1) and $c ne ':';
    $buf .= $c
        while length $buf < $len and sysread $s, $c, $len - length $buf;
    $j->decode($buf);
}

sub cmd ($name, $params = {}) {
    my $body = $j->encode([0, ++$id, $name, $params]);
    print {$s} length($body) . ":$body";
    my $r = pkt();
    die "$name: " . $j->encode($r->[2]) . "\n" if defined $r->[2];
    $r->[3];
}

my @certs = map {
    my ($file, $trust) = split /=/, $_, 2;
    open my $fh, '-|', qw(openssl x509 -outform DER -in), $file
        or die "$file: $!";
    binmode $fh;
    [ encode_base64(do { local $/; <$fh> }, ''), $trust // 'C,,' ];
} @ARGV;

pkt();
cmd 'WebDriver:NewSession';
cmd 'Marionette:SetContext', { value => 'chrome' };

say JSON::PP->new->pretty->canonical->encode(cmd 'WebDriver:ExecuteScript', {
    script => q{
        const cid = "@mozilla.org/security/x509certdb;1";
        const db = Cc[cid].getService(Ci.nsIX509CertDB);
        return arguments[0].map(([b64, trust]) => {
            try {
                const c = db.addCertFromBase64(b64, trust);
                return { ok: true, subject: c.subjectName };
            } catch (e) {
                return { ok: false, error: String(e) };
            }
        });
    },
    args => [ \@certs ],
});

cmd 'WebDriver:DeleteSession';

устанавливем:

perl fenix-cert.pl \
  russian_trusted_root_ca_pem.crt=C,, \
  russian_trusted_sub_ca_pem.crt=,, \
  russian_trusted_sub_ca_2024_pem.crt=,,

# cleanup
adb shell rm -f /data/local/tmp/org.mozilla.fenix-geckoview-config.yaml
adb shell am clear-debug-app
adb forward --remove tcp:2828
adb shell am force-stop org.mozilla.fenix

Проверено на Pixel 5, Android 14, Firefox Nightly 156.0a1.

Видео доступно по ссылке -> https://vkvideo.ru/clip-237277610_456239029

Давайте сегодня поговорим про бумажную безопасность, но не в привычном ее понимании: политики, контроли и комплаенс; а в буквальном смысле - безопасность информации, представленной на бумаге. Сотрудник ФБР (по крайней мере он так представился) на наглядных примерах показывает разницу между шредерами и качеством выполнения их работы.

На сегодня существует 3 типа уничтожителей бумаги: прямые, ромбовидные и конфетти. 
Первые уничтожают бумагу, разрезая ее на ровные полоски. При таком подходе собрать обратно пазл не составляет особого труда и занимает не более 1 часа на восстановление информации. Тоже самое относится и к банковским картам - получить номер карты, ФИО и CVV код займет от силы 1 минуту (30 секунд из которых вы будет искать кончик скотча, чтобы склеить ее обратно).

С ромбовидными сложнее, но восстановление тоже возможно, хотя и занимает намного больше времени. По информации сотрудника, собрать обратно документ составляет около 8 часов.

Самые лучшие, и которые стоят в офисах ФБР (спасибо за подсказку) - это шредеры, которые превращают документ в конфетти. При таком подходе собрать документ обратно не возможно (но тут бы я поспорил). 

Естественно, стоимость бумагоизмельчителей пропорционально растет в зависимости от качества уничтожения документов. С другой стороны, купить шредер ради шредера (первый вариант) - выглядит бездумной тратой денег. К сожалению, не всегда удается донести до закупки почему нужно покупать дорогую вещь, когда существует версии в 10 раз дешевле. 

И к слову сказать, мы в своей работе в рамках Red Team проектах нередко прибегаем к таким методам, так поиск информации в шредерах. Психология людей обычно сводится к тому, что раз документ прошел через измельчитель, значит информация безвозвратно уничтожена. Однако вы теперь знаете, что это далеко не так.
Так что, какой берем?

п.с. нас еще учили, чтобы безвозвратно уничтожить документ, его сначала сжигают, а потом просеивают через мелкозернистую сеть. К сожалению, таких устройств еще не существует, поэтому дарю бизнес-идею ;) 

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

ФСТЭК опубликовала методику оценки уровня зрелости в области технической защиты информации, которая затрагивает в том числе значимые объекты КИИ. Документ вводит пять уровней зрелости (от «нулевого» до «верифицируемого») и 21 направление оценки — от управления защитой до применения ИИ. Эксперты отмечают, что методика призвана бороться с недобросовестными подрядчиками и перевести ИБ из разрозненных задач в стратегию, однако её реализацию могут осложнить неясность с проведением оценки и отсутствие должного контроля со стороны регулятора.

Червь Shai-Hulud вернулся в npm и получил настоящую подпись

4 августа в npm вышла новая версия keyv, небольшой библиотеки для работы с хранилищами. Внутри был вредоносный код, и через час он появился в cacheable, flat-cache, cache-manager и остальных пакетах того же автора, а оттуда пошел дальше по чужим учетным записям. Сутки спустя специалисты Aikido насчитали 444 зараженных пакета.

Опознать волну было несложно. Червь складывал краденое в публичные репозитории с описанием «Shai-Hulud: Here We Go Again». Wiz относит образец к тому же семейству, что и прошлогодние.

Атакующий получил доступ к учетной записи мейнтейнера и выпустил зараженные версии от его имени. В них он добавил загрузчик setup.mjs, файл с замаскированным вредоносным кодом и настройку preinstall в package.json. Она заставляла npm запускать загрузчик еще во время обычной установки пакета.  

setup.mjs определял, на какой системе работает машина. Если на ней не было Bun (среды для выполнения JavaScript), то он скачивал ее легитимную версию 1.3.13 из официального списка релизов. Затем через Bun запускался Math_Symbol.js. Этот файл собирал токены, ключи и другие секреты, доступные на машине разработчика или сервере сборки. Используя токены публикации червь выпускал зараженные версии пакетов, которыми мог распоряжаться их владелец. Таким образом червь шел не только по дереву зависимостей, но и по полномочиям мейнтейнеров. Очередной зараженный пакет попадал в следующую среду сборки, получал доступ уже к ее секретам и повторял тот же сценарий.

Интересно то, что зараженные версии попали в реестр с настоящей подписью. Год назад экосистема ответила на первую волну Shai-Hulud внедрением доверенных публикаций, при котором пакет собирается в общем сборочном конвейере, а вместе с ним публикуются сведения о происхождении сборки. На августовских версиях эта проверка проходила, и подмены после сборки действительно не было. Вредоносный код лежал в самом репозитории, поэтому конвейер честно собрал и заверил то, что там было.

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

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

Как в таком случае защитить цепочку поставки?

Новые версии внешних пакетов лучше вовсе не пускать в сборки в день публикации. Период охлаждения хотя бы на 14 дней дает время заметить подозрительный релиз. Доступ к публичным реестрам стоит пропускать через внутренний репозиторий или прокси, чтобы известная вредоносная версия не попала к разработчикам и в сборочные системы. Подробнее о таких рубежах контроля мы писали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Когда запись об уязвимости уже появилась в базах данных, композиционный анализ помогает найти проекты, сборки и контейнерные образы, где могла оказаться конкретная версия, если не применялся период охлаждения. Дальше важно очистить внутренний кэш, проверить изменения в CI, редакторах и ИИ-агентах, а также отозвать секреты, к которым имел доступ раннер. Удаление пакета из реестра этого уже не сделает.

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Вот и подошел к концу летний интенсив Баумантех.Дети, который проходил в течение всего июля на базе МГТУ им. Н.Э. Баумана. Школьники 7-11 классов со всей страны приехали не только обучиться информационной безопасности, технологиям, инженерии и ИТ, но также попробовать себя в качестве специалистов по ИБ.

В рамках обучения, кроме теоретической части, ребят ждали:
* практикумы, где участники разбирали реальные сценарии кибератак, искали уязвимостей и работали с инструментами ИБ-специалистов
* расследования - игра, в которой участники учились мыслить как синяя команда: анализировали подозрительные события, искали цифровые следы и расследовали инциденты
* CTF (Capture The Flag) - пробовали один из самых популярных форматов в мире кибербезопасности: командные соревнования на логику, внимательность и практические навыки
* финальные проекты, в рамках которых участники применили всё, чему научились, и представили результаты на финальной защите.

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

В качестве наставников и преподавателей были приглашены специалисты и эксперты ведущих ИТ-компаний страны. Со своей стороны я рассказывал про поиск информации по открытым источникам (OSINT), а также показывал "чемоданчик хакера" - аппаратные инструменты, которыми наша команда пользуется практически на каждом проекте

Те, кто не успел принять участие в летней сессии - не переживайте. Впереди осенние интенсивы (в течениие каникул) с новыми расследованиями и задачами. Мир ИБ огромен, и мы рады быть вашим проводником в нем.

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

В связи с историей про “Мадагаскар” https://habr.com/ru/articles/1067420/ , не грех опубликовать вот этот скриншот.

Это я вставил в конец статьи https://habr.com/ru/articles/1065858/ инструкцию , а потом пошёл постить соответствующий запрос в разные сервисы.

Один из испытуемых сам нашёл статью, скачал и честно выполнил инструкцию.

Вышел 9-й номер журнала Paged Out (#8 выпустили в июне), который включает в себя различные материалы на тему этичного хакинга и информационной безопасности. Издание публикуется в формате: 1 страница — 1 статья. Все остальные Paged Out выпуски можно скачать с сайта проекта.

Полтора года пентестов Active Directory сводились к одному и тому же неудобству: для аудита нужен PingCastle (только Windows, только скоринг, ничего не проверяет на практике), для графа путей атаки — BloodHound плюс отдельный коллектор (SharpHound или RustHound-CE), а для реальной эксплуатации — Impacket на Python со всем шлейфом зависимостей. Три инструмента, три экосистемы, и ни один не даёт честного ответа на вопрос "эта уязвимость реально эксплуатируется в этом домене прямо сейчас, или только теоретически светится в отчёте".

Я решил закрыть это одним инструментом — adhammer.

Что внутри

adhammer — это Rust-тулкит для AD security assessment, который совмещает три слоя:

1. Аудит в стиле PingCastle — сканирует домен, скорит находки по severity, размечает MITRE ATT&CK тегами.

2. Граф путей атаки в стиле BloodHound — строит и визуализирует attack paths до Domain Admin.

3. Валидация с реальным PoC — вот это ключевое отличие. Guided-режим проходит по каждой находке и предлагает: "провалидировать и получить PoC?". Если да — запускает реальную атаку и помечает finding как "validated" только если получен настоящий артефакт — хеш $krb5tgs$/$krb5asrep$, реплицированный секрет krbtgt, реально выпущенный сертификат. Если атака не удалась — честно "attempted", а не тихо пропускается.

Почему Rust, а не поверх Impacket

Изначально пробовал строить поверх существующих Python-библиотек — уперся в то, что тащить весь стек зависимостей ради одного бинарника, который должен без проблем компилироваться и запускаться и с Kali, и с Windows-хоста внутри AD-сети, неудобно и хрупко.

Поэтому пришлось написать протокольный стек с нуля: DCE/RPC, NTLM, SMB2, Kerberos — практически "impacket для Rust", которого в экосистеме ещё не было. Результат — один статический бинарник без рантайм-зависимостей, кросс-компилируется под Linux и Windows.

Что дальше

Инструмент build как security research, соседствует с раскрытым в MSRC 0-day в ядре Windows. Сейчас думаю над тем, чтобы вынести протокольный стек в отдельные переиспользуемые crates — уже начал переписку с мейнтейнерами sspi-rs и RustHound-CE на предмет пересечения усилий.

Код и write-up: github.com/icedracon/adhammer

Использование — только на системах, где есть явная авторизация. SECURITY.md в репозитории описывает это подробно.

Буду рад issues, PR и просто фидбеку от тех, кто занимается AD security на практике.

Продуктовые новости Innostage в июле

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

Вышла новая версия Innostage PAM 1.7.0

В новой версии Innostage PAM. Управление привилегированным доступом доработаны сценарии, от которых зависит повседневная эксплуатация PAM в крупных корпоративных инфраструктурах: улучшение функциональности работы с RDP; больше прозрачности при входе по сертификатам, смарт-картам и токенам; новые возможности автоматизации при работе с SSH-ключами; улучшения защиты данных и хранения событий. Подробнее →

Innostage AIDR включён в реестр российского ПО

Innostage AIDR «Защита ИИ» помогает контролировать взаимодействие с языковыми моделями: какие запросы отправляются, какие ответы возвращаются и какие события возникают внутри ИИ-контуров. Подробнее →

Вебинар по обновлённой версии Innostage PAM 1.7.0

Показали ключевые сценарии работы с новой версией Innostage PAM 1.7.0: доступ через RDP, аутентификация по сертификатам и управления SSH-ключами. Смотреть запись →

Регуляторика и ИБ: что меняется на практике

Обсудили с СПб ИАЦ усиление требований к ИБ в госсекторе. В фокусе — совместимость решений и соответствие нормативам (в т. ч. ФСТЭК №117). Показали, как эти задачи закрываются на практике: от расследования инцидентов до контроля применения ИИ с помощью Innostage TDIR и Innostage AIDR. Подробнее →

DDoS-Guard провела исследование совместно с FirstVDS, пионером российского VDS-хостинга. 

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

Зафиксировали значительный рост тактики Pulse Wave: когда волны трафика идут с паузами, чтобы сбить с толку автоматические системы защиты.

Отметили значительное повышение атак на игровые сервисы и тенденцию к росту атак длиной более суток.

Выявили прямую корреляцию риска атаки с возрастом сервера.

И многое другое.

Каждая из компаний изучала данные со своей стороны, а затем мы объединили результаты. Была исследована внутренняя статистика, опрошены более двухсот действующих клиентов FirstVDS и изучены глобальные тренды (с нашей стороны — данные по более чем 7,5 млн инцидентов, включая типы атак, отраслевую структуру, географию источников и сезонные колебания).

Полностью прочесть исследование можно здесь.

БДУ ФСТЭК работает в обе стороны, и у обратной стороны есть срок: пять рабочих дней

В банке данных угроз ФСТЭК сейчас 91 986 уязвимостей, счётчик на главной bdu.fstec.ru. Все привыкли к движению в одну сторону: оттуда берут перечни, туда ходят сканеры, на базу ссылаются регламенты.

Обратное движение тоже существует: кнопка «Сообщить об уязвимости» на сайте есть, жмут её добровольцы. А с 1 марта 2026 года для операторов госсистем это уже не добрая воля. Приказ ФСТЭК № 117, пункт 38: при выявлении уязвимости, сведений о которой в БДУ нет, оператор «в срок не более 5 рабочих дней с даты такого выявления должен направить информацию об уязвимости в ФСТЭК России для оценки необходимости включения выявленной уязвимости в банк данных угроз…». Основание в сноске приказа: подпункт 21 пункта 8 Положения о ФСТЭК.

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

В исследовательском мире coordinated disclosure устроен как переговоры: вендору дают время на патч, стороны торгуются о сроках публикации. Здесь конструкция жёстче: пять рабочих дней, адресат сразу регулятор, и решение о публикации в базе тоже принимает он. Обязательный disclosure по-русски.

Формально пункт касается ГИС и систем госорганов. Но у него есть эффект второго порядка: базу теперь обязаны кормить и эксплуатанты, не только исследователи с вендорами. Любопытно, сколько из следующих тысяч записей придёт именно этим маршрутом.

Кто-нибудь уже отправлял находку во ФСТЭК по пункту 38? Интересно, как быстро отвечают и доходит ли уязвимость до публикации.

Атака на цепочку поставки через Steam, или как вредоносный код спрятали в легитимных обновлениях

В США задержали 21-летнего Зайра Уилкинса, которого обвиняют в причастности к схеме распространения игр с вредоносным кодом через Steam. По версии следствия, встроенное в игры вредоносное ПО собирало учетные данные и другую информацию с компьютеров пользователей.

В июле 2026 года в суд поступили подробные материалы дела. В документе говорится о восьми играх с вредоносным кодом и примерно 8 тысячах зараженных устройств. Следствие связывает атаку с несанкционированным доступом приблизительно к 80 криптовалютным кошелькам и хищением не менее 220 тысяч долларов. Пока это версия обвинения, а не установленные судом факты.

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

Особенно показателен случай Lampy. Вредоносный код содержала обновленная версия игры, выпущенная в январе 2026 года. Пользователю не требовалось переходить на поддельный сайт или устанавливать программу из неизвестного источника – исполняемый файл доставлялся через привычный механизм обновлений.

Судя по опубликованным материалам, злоумышленники не взламывали сам Steam. Они встроились в штатный процесс поставки и использовали доверие к площадке, учетной записи издателя и обновлениям. Этот случай хорошо дополняет привычное представление об атаках на цепочку поставки. Точкой входа может стать не только скомпрометированная зависимость или система сборки, но и канал, через который готовый продукт доходит до пользователя.

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

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

uInfraTwin: цифровой двойник сегмента сети для безопасного тестирования изменений

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

Чтобы закрыть эту задачу, мы представили платформу виртуального цифрового двойника сегмента сети UserGate InfraTwin (uInfraTwin).

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

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

➡ Узнать детали и запросить пилот

PyPI готовится закреплять префиксы имен пакетов за организациями

29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.

Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.

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

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

Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.

PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.

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

Когда механизм заработает, новые метаданные можно будет использовать не только на страницах PyPI. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.