Меня зовут Максим Мотиков, я аналитик киберугроз в «Гарде». Недавно на анализ мне пришел странный экзешник весом 81,54 МБ. Коллега выцепила его из сетевого трафика, но что внутри было, непонятно. Стиллер? Загрузчик? Что-то новое?

Оказалось, что передо мной вредоносная утилита на Python. Хотя эти зловреды давно существуют и регулярно эксплуатируются, мне задача отреверсить подобную штуку досталась впервые. До «Гарды» я занимался реверсом firmware — встроенного ПО инициализации ПК (BIOS, UEFI) и прошивок микроконтроллеров. Там всё написано на ассемблере и C/C++, ведь код должен напрямую работать с железом, поэтому никакой Python там не встречается. 

Готового пошагового гайда по реверсу Python‑вирусов и вредоносных утилит я не нашел. Попадались, конечно, разборы конкретных кейсов, но какой-то универсальной инструкции, не было. Когда я разобрал по косточкам свой зловред, взял еще несколько образцов, прогнал их по тому же сценарию, получился вполне рабочий пайплайн для начинающих аналитиков угроз. Делюсь им под катом.

Насколько часто злоумышленники используют Python-вирусы в своих атаках

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

 Причины простые.

1. Злоумышленнику не нужно неделями собирать инфраструктуру разработки, так как большинство возможностей уже есть в готовых модулях Python — requests для сети, pywin32 для Windows API, sqlite3 для локальных баз, cryptography для шифрования.

2. Один и тот же скрипт отлично работает и на Windows, и на Linux, и на macOS. Не нужно даже ничего перекомпилировать.

3. Инструменты вроде PyInstaller, Nuitka или cx_Freeze собирают интерпретатор, зависимости и байт-код в один экзешник. Для конечного пользователя это «программа», для аналитика — заархивированная директория. Правда, степень «упаковки» у них отличается. Например, cx_Freeze обычно не встраивает все динамические библиотеки внутрь исполняемого файла, а складывает их рядом в отдельную директорию. Без этих DLL- или SO-файлов программа просто не запустится, поэтому в реальных вредоносных кампаниях такой подход встречается редко. Существуют и другие решения, например, py2exe, работающий по схожему с PyInstaller принципу. Однако этот продукт развивается не слишком активно, а большинство автоматизированных инструментов для извлечения PYC-файлов рассчитаны на старые версии его сборок.

Где это встречается? Везде. От простых инфостиллеров до MaaS-платформ вроде CrystalX RAT, которую распространяют в приватных Telegram-чатах. В ее функционале — WebSocket-C2, кража учетных данных через ChromeElevator (как раз тот, который прилетел мне на анализ), инъекция расширений в браузеры, подмена криптокошельков в буфере обмена и антиотладка.

Отдельно стоит упомянуть Nuitka. Формально это не упаковщик, а компилятор, который транслирует Python-код в C/C++, а затем собирает полноценный исполняемый файл. Аналитику с таким файлом придется повозиться. Ведь на входе он получает уже не набор байт-кода Python, а целую программу, которую приходится исследовать методами классического реверс-инжиниринга. В коммерческой версии Nuitka доступны дополнительные механизмы обфускации и защиты данных внутри исполняемого файла. Тем не менее, по нашему опыту, вредоносное ПО на основе Nuitka пока встречается заметно реже, чем образцы, упакованные PyInstaller.

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

Особенности Python-сборок и почему их «вскрывать» проще, чем C++

Большинство упаковщиков Python, включая PyInstaller, работают примерно одинаково. Сперва они компилируют исходные скрипты в байт-код (.pyc), после чего всё это вместе с интерпретатором и необходимыми библиотеками включается в итоговую сборку. К примеру, они могут собрать приложение как в один исполняемый файл, так и в каталог с набором зависимостей. Для аналитика угроз это означает, что в готовом образце приходится работать уже не с исходным кодом, а с байт-кодом Python.

У Python-сборок есть еще парочка отличительных особенностей. Во-первых, такие файлы практически всегда большого размера. Так, 80–100 МБ для простого стиллера — норма. Причем это не обфускация, а реальный вес интерпретатора и библиотек. Во-вторых, такой архив можно распаковывать за считанные секунды. Здесь, в отличие от C/C++ (Themida, VMProtect), нет сложной упаковки виртуальными машинами. Нужно всего лишь извлечь байт-код и конфигурации.

Пайплайн для вскрытия вирусов на Python

Алгоритм, который я отработал на нескольких семплах, выглядит так.

1. Проверяю тип упаковщика. Я смотрю на размер, проверяю импорты в PE-заголовке (strings, PEview, Detect It Easy), ищу строки PyInstaller, python3x.dll, pyi_runtime, MEI. Если нахожу такие признаки, значит, анализируемый образец представляет собой PyInstaller-сборку.

2. Извлекаю .pyc-файлы. В этом мне помогает open-source утилита Pyinstxtractor (extremecoders-re/pyinstxtractor). Она парсит структуру PyInstaller-сборки и на выходе выдает директорию с .pyc-файлами, конфигурацией и библиотеками.

3. Нахожу целевой модуль. Нас интересуют те, что не входят в стандартную библиотеку Python: либо с подозрительными именами (victim_hidden.pyc, core_logic.pyc, update.pyc и подобными), либо с импортами сетевых модулей, криптографии, работы с реестром или файловой системой (видно через strings или быстрый grep).

4. Декомпилирую байт-код. Обычно первым делом запускаю pycdc (zrax/pycdc), который восстанавливает Python-код из .pyc-файла. Правда, одного декомпилятора бывает недостаточно. Так, на одних версиях байт-кода он работает отлично, на других оставляет артефакты или не может корректно восстановить отдельные конструкции. Поэтому иногда приходится прогонять образец через uncompyle6 или decompyle3 и выбирать наиболее читаемый результат.

5. Статически анализирую декомпилированный код. В нем ищу декодирование строк (base64.b64decode, codecs.decode, zlib.decompress), сетевые запросы (requests, socket, urllib, websocket) и выполнение кода (exec, eval, subprocess.run, os.system). Дополнительно исследую, как вредонос взаимодействует с файловой системой и реестром.

Краш-тест алгоритма на зловредных питоняшках

Теперь проведу краш-тест описанного выше пайплайна на нескольких вредоносных утилитах. И начну с виновника торжества ChromeElevator.exe. Чтобы понять функцию неизвестного модуля и расшифровать данные, уходящие на C2, я запустил Pyinstxtractor. На выходе получил папку с файлами. В ней наряду со стандартными файлами был один нестандартный — victim_hidden.pyc.

Декомпилирую victim_hidden.pyc через pycdc. Код читается, но часть строк обфусцирована: длинные base64-строки, которые передаются в zlib.decompress().

Распаковываю «текст» и на выходе получаю чистый Python-скрипт. Логика действия зловреда становится прозрачной.

Алгоритм общения с C2

Чтобы обозначить себя, ВПО посылает на C2 строку «VICTIM». Следом отправляется идентификатор в формате «Имя пользователя»@«Имя хоста»:«текущая директория». После чего ВПО ждет ответ от сервера. Если приходит команда «REFRESH_PROMPT», повторно отправляется идентификатор, и информация о текущем состоянии сессии тоже обновляется. 

С помощью cd вредонос меняет рабочую папку. Если сервер присылает «exit» либо не присылает ничего, цикл останавливается. Любую другую строку он воспринимает как команду ОС: передает ее в subprocess, забирает вывод и шлет его обратно на сервер управления.

Коммуникация реализуется посредством передачи raw-байтов по TCP через сетевые сокеты. По сути, это примитивный, но вполне рабочий интерактивный шелл-код поверх TCP. Перед отправкой вредонос шифрует полезную нагрузку. В данном случае используется Fernet, что может служить дополнительным индикатором для аналитика при разработке детектирующих правил. Также важно учитывать, что к шифротексту добавляется служебный заголовок.

Проверка алгоритма реверса на втором зловреде

Для второго теста я выбрал инфостиллер. Он крадет пароли из браузеров на движке Chrome: проходит по файловой системе винды, находит такие браузеры и вытаскивает их базы с паролями. Вредонос проходится по всем известным расположениям файловой системы, где могут храниться эти базы данных. Затем расшифровывает базу и передает данные в Telegram-чат с помощью Telegram Bot API.

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

Поскольку тестовый образец я нашел сам, то заранее знал, что имею дело с PyInstaller-сборкой. Но для чистоты эксперимента решил прогнать зловред по всем пунктам алгоритма. Первым делом оценил размер файла и проверил строки через PEview. Здесь мне сразу бросились в глаза такие маркеры, как python312.dll, pyi_runtime, каталог _MEI.

Дальше запустил Pyinstxtractor, на выходе получил 77 файлов в CArchive и 244 модуля в PYZ. Среди них я выделил файл stealer.pyc с наиболее подозрительным именем. Стандартные библиотеки и зависимости отложил в сторону.

С декомпиляцией пришлось немного повозиться. После запуска pycdc утилита сыпанула предупреждениями. Например, пожаловалась на неизвестный опкод и проблемы с END_FOR. По выводу Pyinstxtractor увидел, что сборка сделана на Python 3.12 — отсюда и проблемы, pycdc с этой версией работает неидеально. К счастью, код восстановился более-менее читаемо, так что можно было двигаться дальше.

Открыв декомпилированный файл в редакторе, я приступил к статическому анализу. Такой стиллер работает по стандартной схеме. Сперва он подключается к базе Chrome Login Data и извлекает из нее сохраненные учетные данные, расшифровывает их, после чего отправляет злоумышленнику.

Отдельно опишу, как реализована обработка ошибок. В функции расшифровки стоит блок try/except. Это означает, что, если не получается расшифровать пароль, выводится сообщение Cannot decrypt password и функция возвращает None. Почему это важно для аналитика угроз? Дело в том, что не все записи в базе могут быть зашифрованы одинаково. Перед добавлением в extractedData код проверяет, что username_value и password_value не None и не пустые строки. Таким образом, в отчет не попадает мусор.

Еще одна интересная деталь — форматирование данных. Каждый найденный пароль собирается в строку вида URL: ... Username: ... Password: ..., а затем одной строкой отправляется через Telegram Bot API. Токен бота и chat_id передаются в функцию send_telegram_message(), которая формирует POST-запрос к api.telegram.org. В main() происходит перебор путей к профилям Chrome через os.path.expanduser('~') с проверкой существования файлов.

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

Напутствие

С Python-малварью не нужно лезть в дебри ассемблера. Главная ее уязвимость кроется в самой архитектуре. Байт-код довольно легко вытаскивается, а обфускация чаще всего ограничивается шифрованием строк и ренеймом.

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

А какой у вас подход к реверсу вирусов на Python?