Библиотека-логгер и инфостилер в придачу? Спасибо, не надо 👋

За последнее время произошло немало событий. Например, кто-то решил поиграть в меценатство и опубликовал 30 релизов с именами NPM-библиотек для логирования:

• @logcore/pino-pretty-logger
• console-loggers
• jellyfi-pino-pretty-logger
• jonas-prettier-logger
• logger-beauty
• pino-logger-utils
• pino-pretty-log
• pino-pretty-logger
• pretty-pino-logger
• pretty-ts-logger
• ts-moduler
• wrapped-logger-utils

Это не просто спам-кампания: эти библиотеки несут в себе инфостилер и бэкдор.

Нам даже удалось в этот раз кому-то уступить в борьбе за звание «самая быстрая рука на диком опенсорсе» — первыми зарепортили лишь 5 из 12 пакетов 🥺

Кампания использует обфускацию. Изначально злоумышленник защищал только имена переменных, но затем стал XOR-ить строки (скриншоты 1, 2).

Вредоносная логика активируется во время импорта библиотеки:

1️⃣Определение ОС жертвы и сбор базовой информации о системе (IP-адрес сетевого устройства, имя пользователя).

2️⃣Параллельное выполнение двух задач:

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

🔗Обход домашней директории в поисках файлов с расширениями .env / .json. В коде есть небольшая оптимизация — при обходе будут пропущены следующие папки:

'node_modules', 'Library', 'System', 'Windows', 'Program Files', 'ProgramData',
'build', 'dist', 'out', 'output', 'release', 'bin', 'obj', 'Debug', 'Release',
'target', 'target2', 'public', 'private', 'tmp', 'temp', 'var', 'cache', 'log',
'logs', 'sample', 'samples',
'assets', 'media', 'fonts', 'icons', 'images', 'img', 'static', 'resources', 'audio', 'videos', 'video', 'music',
'svn', 'cvs', 'hg', 'mercurial', 'registry',
'__MACOSX', 'vscode', 'eslint', 'prettier', 'yarn', 'pnpm', 'next',
'pkg', 'move', 'rustup', 'toolchains',
'migrations', 'snapshots', 'ssh', 'socket.io', 'svelte-kit', 'vite',
'coverage', 'history', 'terraform'

Пользователям Linux особенно не повезет: им в ~/.ssh/authorized_keys закинут новый публичный SSH-ключ. При работающем сервисе sshd и разрешении использовать ssh-ключ для текущего пользователя позволит злоумышленнику подключаться к устройству 😍

Под Windows помимо обхода домашней директории стилер пройдется по всем подключенным дискам.

3️⃣Отправка всех собранных данных на сервер злоумышленника.

———

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

const ENV_LIKE_FILES = new Set([
    '.env', '.env.local', '.env.production', '.env.development',
    '.config', '.npmrc', '.pypirc', '.git-credentials', 'wallet.dat', 'id.json', 'key.json', 'keystore/*.json',
]);
const JSON_LIKE_FILES = new Set(['config.json', 'settings.json', 'secrets.json']);

Вероятно, это связано с большим количеством мусора при сборе всех json-файлов.

Также добавилась кража директории tdata, содержащей данные сессии Telegram 🤢

———

Дежурное напоминание: не ослабляйте бдительность при работе с опенсорс-проектами 😑

#npm #ti #scs #pyanalysis
@ptescalator (X, Max)

Распознаем STL-код легко 😐

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

На самом деле здесь важно потратить время на то, чтобы распознать STL-контейнер по косвенным признакам, быстро понять, где какие данные лежат, типизировать их и идти дальше. В новой серии постов мы расскажем о самых распространенных контейнерах STL и начнем с std::vector.

Паттерн 1️⃣: три последовательных чтения/записи указателей

std::vector — один из самых простых контейнеров. Он занимает в памяти 24 байта в 64-битных сборках. Если открыть исходный код std::vector в MSVC STL, мы увидим класс _Vector_val (скриншот 1), который хранит ровно три указателя — начало (_Myfirst) и конец данных (_Mylast), а также конец выделенной памяти (_Myend).

Именно эта тройка и определяет схему памяти вектора. Компилятор расставляет их в памяти последовательно (смещения 0, 8, 16 байт в 64-битном коде). Поэтому в ассемблере мы всегда будем видеть обращения по этим смещениям — это наш главный ориентир.

Сразу посмотрим на простой пример на скриншоте 2. Не имея исходника, видно, что общая картина выглядит скомкано. Слева в ассемблерном коде мы видим кусок кода:

xorps xmm1, xmm1 ; и xmm1
movdqu xmmword ptr [rbp+57h+var_68], xmm1 ; записываем 16 нулевых байт по адресу var_68
xor r15d, r15d ; обнуляем r15d
mov [rbp+57h+var_58], r15 ; записываем 8 нулевых байт по адресу var_58

Компилятор обращается к членам вектора как к смещениям относительно базового адреса. Базовый адрес здесь в локальной переменной var_68. Первые 16 байт обнуляются: по смещению var_68 лежит _Myfirst, по смещению var_60 — _Mylast. Затем обнуляется _Myend, который находится по смещению var_58.

Таким образом, мы видим инициализацию пустого вектора, выполняемую вместо вызова конструктора по умолчанию. Проверяем размер вектора — 16 + 8 = 24 байта. На скриншоте 3 видно, как выглядит вектор на стеке.

Это облегчает нам задачу. Мы пока предполагаем, что работаем с вектором, но все еще есть шанс, что мы захотим зареверсить sub_140002860. Посмотрим на второй паттерн, осознаем себя и не станем этого делать.

Паттерн 2️⃣: push_back и проверка на заполненность вектора

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

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

if (_Mylast == _Myend)
  push_back_func();
else
  construct(_Mylast, value);
  ++_Mylast;

Код проверяет, есть ли место для нового элемента в векторе. Если нет, то оно выделяется и элемент добавится в конец вектора. Если есть, значение добавляется по адресу, на который сейчас указывает _Mylast. Посмотрим в наш пример на скриншоте 4.

👀 Видим, что паттерн просматривается. Есть сравнение указателей _Mylast и _Myend, за которым следует вызов функции sub_140002860, в которую передаются наши указатели и целевое значение. Если мы зайдем в sub_140002860, первое, что мы увидим, будет вычисление размера вектора — size() = (_Mylast - _Myfirst) / sizeof(T) (скриншот 5). То есть функции, чтобы понять, нужно ли выделять новую память, требуется вычислить новый размер вектора и сравнить его с текущей вместимостью. Для нас это подсказка — мы смотрим в функцию push_back.

🤝 Теперь, когда понятно, что перед нами вектор, можем воссоздать его структуру (скриншот 6) и структуру, которая его использует, и разметить их в IDA (скриншот 7). Выглядит немного лучше и понятнее.

Несмотря на наличие и других конструкторов и методов у std::vector, знание его внутреннего расположения в памяти позволяет легко идентифицировать вектор в скомпилированном коде.

Stay tuned!

#tip #reverse
@ptescalator (X, Max)

Путаница в уязвимостях WSUS: ставим все на свои места 🕷

Одной из самых актуальных уязвимостей в Windows Server Update Services (WSUS) стала критическая ошибка с идентификатором CVE-2025-59287 и оценкой CVSS 9.8. Она связана с десериализацией недоверенных данных в службе обновления Windows Server и позволяет неавторизованному удаленному злоумышленнику выполнить код на сервере, отправив специально сформированное событие.

В разборах эксплуатации шаги были указаны некорректно, так как их взяли из статьи. Однако позже авторы сами ее исправили и указали, что разбор относится к CVE-2023-35317, тогда как анализ CVE-2025-59287 перенесли в отдельную статью.

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

❗️ Напомним технические детали эксплуатации

Условия для эксплуатации:

• Сервер Windows с включенной ролью WSUS Server (по умолчанию отключена)
• Неустановленные обновления KB5070879 / KB5070881 / KB5070882 / KB5070883 / KB5070884 / KB5070886 / KB5070887
• Сетевой доступ к портам 8530 (HTTP) или 8531 (HTTPS)
• Учетные данные не требуются

Техническая цепочка эксплуатации:

1️⃣ Получение конфигурации — злоумышленник отправляет запрос к /ReportingWebService/ReportingWebService.asmx для получения ServerID (скриншот 1)

2️⃣ Извлечение cookies — используя ServerID, выполняется запрос к /SimpleAuthWebService/SimpleAuth.asmx для получения AuthorizationCookie (скриншот 2)

3️⃣ Получение криптографических данных — запрос к /ClientWebService/Client.asmx для извлечения временных меток и зашифрованной нагрузки (скриншот 3)

4️⃣ Доставка полезной нагрузки — финальный запрос отправляет событие с вредоносным сериализованным объектом, созданным через ysoserial.net с гаджетом TextFormattingRunProperties, с использованием события SynchronizationCompletedCancel (скриншот 4)

При обработке события с ID 389 (SynchronizationCompletedCancel) WSUS пытается десериализовать XML с телом ошибки, что приводит к выполнению произвольного кода.

Также в процессе эксплуатации регистрируется ложный узел с указанным DNS, в рамках которого отправляется событие. Этот процесс легко автоматизировать — например, с помощью шаблона Nuclei (скриншот 5). Восстановление оснастки после тестирования — на скриншоте 6.

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

Для восстановления необходимо удалить вредоносное событие из таблицы tbEventInstance в базе данных SUSDB. Однако прямой доступ к БД есть только у привилегированных пользователей, а служба WSUS часто запущена от имени Network Service.

При этом служба WSUS имеет доступ к функциям, используемым в оснастке, поэтому пользователь, от имени которого получена сессия (даже Network Service), может управлять зарегистрированными узлами. Это позволяет безопасно завершить эксплуатацию и сразу восстановить оснастку.

$wsus = Get-WsusServer

Get-WsusComputer -NameIncludes "test1337.test.local" | ForEach-Object {
    $wsus.GetComputerTarget($_.Id).Delete()
}

Эта команда выполняет две важные функции:

• Удаляет зарегистрированный ложный узел из базы данных WSUS
• Автоматически очищает связанное с ним событие с ID 389, использованное для доставки полезной нагрузки

🧐 Почему это важно: без очистки в WSUS остаются артефакты — ложный узел и события в логах, что может нарушить нормальную работу службы.

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

Рекомендации — в посте ниже 🔽

#offensive #nuclei #wsus #cve
@ptescalator (X, Max)