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

MAX тоже можно защитить шифрованием поверх мессенджера

Telegram, VK и другие сервисы можно использовать как транспорт для зашифрованных сообщений, не полагаясь на их собственный механизм защиты содержимого. Российский разработчик развивает open-source проект CryptoLayer — библиотеку, которая создает дополнительный криптографический слой непосредственно на устройствах участников переписки.

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

Как это работает

CryptoLayer не заменяет Telegram, VK или другой сервис, а отделяет защиту содержимого от транспорта.

Для шифрования используется AES-256-GCM, для цифровых подписей — ECDSA на кривой SECP256R1, а согласование ключей выполняется через ECDH с той же кривой. Дополнительно библиотека может преобразовывать зашифрованные данные с помощью WordCoder — он кодирует байты в последовательность обычных слов.

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

Один криптографический слой — разные каналы

Главная особенность проекта — модульная архитектура. CryptoLayer не привязан к конкретному мессенджеру или платформе.

В репозитории указано, что транспортом может быть практически любой канал, способный передавать данные. Среди примеров — Telegram, VK, Discord, HTTP, SSH, FTP, UDP, облачные хранилища, файловая система и Bluetooth. Для нового варианта передачи требуется написать отдельный модуль.

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

Однако готового модуля для MAX в основном репозитории сейчас нет. Поэтому полноценной поддержки этого мессенджера пока нет — потребуется отдельная интеграция.

Какие инструменты уже доступны

Вокруг CryptoLayer постепенно формируется собственная экосистема:

• CryptoLayer CLI — интерфейс для работы из терминала;

• CryptoLayer Web UI — веб-интерфейс для защищенного обмена сообщениями;

• zkgram — отдельный клиент для приватного общения через Telegram.

Исходный код опубликован под лицензией MIT. На момент проверки официальный репозиторий набрал более 200 звезд на GitHub, но проект остается небольшим независимым open-source решением, а не криптографической системой, прошедшей масштабный аудит.

Это важная оговорка. Наличие AES-256-GCM, ECDSA и ECDH само по себе не гарантирует безопасность всей системы. Многое зависит от реализации протокола, генерации и хранения ключей, защиты конечных устройств и отсутствия ошибок в коде.

Что все равно видит мессенджер

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

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

Иными словами, CryptoLayer не скрывает существование переписки. Его задача — не дать транспортному каналу получить исходный текст сообщения.

Где посмотреть исходный код

Репозиторий CryptoLayer на GitHub содержит исходный код, описание архитектуры, используемые криптографические механизмы и информацию о доступных интеграциях.

Архитектура и принцип работы проекта также показаны в видеопрезентации CryptoLayer.

Главное

CryptoLayer интересен не как новый защищенный мессенджер, а как внешний слой шифрования, который отделяет конфиденциальность переписки от конкретного сервиса доставки.

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

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

Регистрацию на иностранных сайтах по номеру телефона убрали из «Антифрод 3.0»

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

Из актуальной версии «Антифрод 3.0» исключили норму, обязывающую иностранные сайты и приложения, работающие в России, регистрировать пользователей внутри страны только по номеру телефона. Об этом сообщили «Ведомости», ознакомившиеся с новой редакцией законопроекта.

Что планировали изменить

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

Если бы норма сохранилась, такие платформы должны были бы:

• использовать номер телефона как обязательный способ авторизации пользователей в России;

• хранить сведения о регистрации, входе и удалении аккаунтов в течение трёх лет;

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

Теперь этих положений в новой редакции проекта нет.

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

Почему от требования могли отказаться

Главная проблема — техническая и юридическая реализация такой схемы на иностранных платформах.

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

Гендиректор Telecom Daily Денис Кусков считает исключение нормы разумным именно по этой причине. Независимый аналитик Алексей Бойко также обращает внимание на риск, что зарубежной платформе может оказаться проще ограничить работу в России, чем создавать отдельную систему авторизации для российских пользователей.

«Антифрод 3.0» ещё меняется

О подготовке третьего пакета мер против кибермошенничества объявили в апреле 2026 года. Законопроект планируют внести в Госдуму осенью.

Причём требования к иностранным ресурсам уже успели измениться: ещё в конце июля «Ведомости» сообщали о проекте, в котором обязательная авторизация по номеру телефона присутствовала.

Пока окончательный набор мер не утверждён, поэтому пользователям иностранных сайтов не стоит воспринимать исключённую норму как уже принятое решение или окончательную отмену каких-либо требований. Финальная редакция «Антифрод 3.0» может ещё измениться.

🔎 PhishIntel — автономный OSINT-инструмент для анализа доменов

Проект помогает быстро собрать технический профиль домена и оценить потенциальный фишинговый риск в формате структурированного JSON-отчёта.

Что проверяет PhishIntel:

• DNS-записи, IP и reverse DNS;
• RDAP/WHOIS и регистрационные данные;
• HTTP, TLS-сертификаты и цепочки редиректов;
• содержимое веб-страниц, формы и внешние action;
• упоминания брендов и фишинговых ключевых слов;
• используемые веб-технологии;
• sitemap и обнаружение распространённых поддоменов;
• локальную историю изменений DNS и TLS;
• контекстный explainable scoring — с пояснением, почему домен получил тот или иной уровень риска.

Инструмент работает автономно, не требует обязательного доступа ко всем сетевым сервисам и продолжает формировать отчёт даже при недоступности DNS, HTTP или TLS-проверок.

Запуск:

python3 scan.py example.com

Результат сохраняется в JSON, поэтому его удобно использовать в расследованиях, автоматизированных пайплайнах и собственных аналитических инструментах.

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

"Изучи технический отчет домена и дай оценку потенциальному фишинговому риску, составь краткий человекочитаемый отчет"

Инструмент писал для личных нужд, но может он будет полезен детективам, безопасникам и OSINT-специалистам.

🔗 Репозиторий: https://github.com/Bednyakov/PhishIntel

Аттестация начинается с инфраструктуры: виртуализация и контейнеризация под требования ФСТЭК

В 2026 году требования к защите информации стали строже: обновления в регулировании КИИ уточнили подходы к категорированию значимых объектов и применению российского ПО, а для государственных информационных систем начал действовать приказ ФСТЭК №117. В этих условиях готовиться к аттестации важно уже на этапе проектирования ИТ-инфраструктуры. 

На вебинаре разберем, какие требования предъявляются к инфраструктуре регулируемых ИС и как zVirt Max и Nova SE помогают сформировать технологический фундамент для аттестации.

Что обсудим:

— Требования ФСТЭК к инфраструктуре ЗО КИИ, ГИС, МИС, АСУ ТП и ИСПДн
— Применение сертифицированных версий zVirt Max и Nova SE в регулируемых контурах
— Механизмы защиты на уровнях виртуализации и контейнеризации
— Изоляция данных, разграничение доступа, контроль целостности и регистрация событий безопасности
— Роль сертифицированных продуктов в подготовке систем к аттестации
— Построение доверенной российской инфраструктуры без отказа от современных технологий виртуализации и контейнеризации

Спикеры:

Александр Гавриленко, директор технического пресейла и партнерских интеграций, Orion soft

Анна Лернер, руководитель по безопасной разработке, Orion soft

Регистрация тут

Наша команда потихоньку перебирается в новый офис и обзаводится дополнительным оборудованием. Среди новых "игрушек" у нас появился источник питания RIGOL DP932E, цифровой мультиметр DM3058E, осциллограф RIGOL DS1202Z-E, на подходе USRP-200 и еще более 50 позиций.

Среди давно ожидаемого оборудования, как бы это не казалось таким странным, являлся тепловизор и, в данном случае, наш выбор остановился на Verdo Ti3101.
Тепловизор - вещь достаточно незаменимая и нужная в хозяйстве. Основная задача измерителя - найти неисправные элементы для их последующей замены и восстановления работоспособности устройства: подаешь 1-2 вольта и смотришь где греется - там и короткое замыкание.

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

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

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

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

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

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.
▶ Ничего не сделали и живём с риском.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сертификаты минцифры в 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? Интересно, как быстро отвечают и доходит ли уязвимость до публикации.