Кто-то может назвать это безумие. Для меня это просто среда.
Она досталась мне вчера, и я разобрался с ней сегодня. Она пришла в нагрузку к java эксплойту от старого 2012 CVE (SecurityManager, я полагаю). Я называю её 0day[1], потому что её нету в базах VirusTotal / Malwr ни в каком виде — ни запакованном, ни распакованном.
Попытка анализа в IDA[2] завершается ошибкой:
Похоже, что тот засранец, который это делал, скорее всего знал, что некто вроде меня попытается провести анализ. В любом случае, существует не так уж много вариантов модификаций exe, которые сводят с ума дизассемблер, но при этом игнорируются Windows.
Исследуя exe-файл в CFF Explorer, мы видим ошибку в одном из NT-заголовков, а именно в «Data Directories» на значении Delay Import Directory RVA. CFF прекрасен тем, что сразу подсвечивает значение 0x00000040 как неверное. Зануляем его, чтобы исправить ошибку.
Сохраняем exe и заново открываем его в IDA — теперь ошибки нет и отрытие проходит без сучка и задоринки.
Беглый осмотр показывает, что это MFC[3]-приложение. Как я понял это? Об этом прямо сказано в столбце Library секции импорта.
Приложение, само собой, запаковано. Память запакована. Никаких модифицированных заголовков секций, банальная запакованная память.
Что ж, статический анализ — не вариант. Для дальнейшего исследования необходим динамический анализ. Шашки Immunity наголо!
Перед тем как погрузится в Immunity и виртуальную машину, стоит отметить пару небезынтересных вещей, которые не видны в IDA, однако были замечены в CFF Explorer. Для начала, есть пару файлов, которые, на радость Капитану Очевидности, скрыты в директории ресурсов.
Первый — это PNG файл:
Второй — HTML страница:
Странно. Загрузив PNG файл в IrfanView (лучший вьювер для изображений, между прочим) мы видим небольшой черный прямоугольник, что не совсем вяжется с его размером в 55 КБ. Наверняка что-то спрятано внутри. Стеганография?
Теперь посмотрим на HTML-страницу. Загрузив и почистив его в Notepad++, получаем что-то похожее на скрипт определения типа браузера.
Почему все это находится в секции ресурсов, да еще и в незапакованном виде — остается загадкой. К секции ресурсов мы еще вернемся. А пока продолжим распаковку.
Запускаем Immunity Debugger и Virtual Box и подгружаем анти-анти-отладочный python плагин.
После того, как процесс завершится, можно слить память и заняться её анализом:
Я заметил несколько областей памяти, помеченных как Read Write Execute (RWE). Одна из них по адресу 0x00910000, еще одна — 0x00930000, следующая — 0x00940000 и, наконец, последняя — по адресу 0x00970000. Дальнейший анализ показывает, что только 3 из 4 содержат программы. Однако, три программы прятать в одну? Неплохая пасхалка.
Теперь сдампим наши программы для дальнейшего анализа. Подгружаем OllyDumpEx и скармливаем наши 0090 области. Видно, что программы по адресам 0x00910000 и 0x00970000 совпадают с оригинальной, судя по их размеру, заголовкам секций и характеристикам. А область по адресу 0x00950000 отличается от них: другие заголовки секций, другие размеры. Должно быть, это то самое золотое яйцо (я оставил буквальный перевод, т.к. в дальнейшем автор использует golden egg в своих скриншотах — прим. перев.).
Сдампим наш exe используя Binary (Raw) режим вместо режима Rebuild, чтобы сохранить целостность дампа.
Два заголовка секций указывают на то, что программа запакована с помощью UPX[4]. Запуск upx утилиты подтверждает это. Значит, мы можем легко распаковать наше яйцо.
Новый exe примерно на 40 КБ больше и распакован корректно, так что теперь мы наконец можем скормить его IDA. Взглянув на строки, видим интересные вещи.
Это же HTTP запрос. Похоже, эта штука отсылается домой мамочке, используя POST запрос.
Вы можете спросить — а как же C&C сервер? Не похоже, чтобы он содержался в программе в plain text виде. Помните, я просил вас не забывать про секцию ресурсов? Заглянем в секцию ресурсов нашего golden_egg.exe
Вуаля. http://31.207.6.161. Это прекрасно — предоставить нам адрес в открытом виде. Security through obscurity наносит очередной ответный удар.
Наверное вам интересно, что же происходит, когда выполняется основное приложение. Давайте посмотрим:
Во время загрузки, оно автоматически закрывает мой Process Explorer и на любые попытки загрузить диспетчер задач отвечает сообщением «диспетчер задач был отключен администратором» перед тем как почти мгновенно закрыться. Я хотел было сделать скриншот, но оказалось, что я не настолько быстр. Обратившись к Immunity, мы видим, что оригинальная программа «golden_egg.exe» уже завершилась. Взамен — какая-то другая программа с именем «zpNvNKSi.exe», запущенная из темповой директории. Сравниваем хэши — и, похоже, они одинаковы:
(Понравился мой хэшер? Скачать можно тут без регистрации и смс)
Рекламная пауза окончена, теперь понятно что делает программа — отключается диспетчер задач, убивает «неугодные» приложения и запускается из темповой директории. Проверка msconfig показывает 2 новых записи в автозагрузке:
Я проверил оба файла и они байт в байт совпали с оригинальной программой.
Аттачимся к программе с помощью Immunity, смотрим на память и количество потоков (нажатием клавиши «t») — видим, что программа многопоточная. Я насчитал 12 потоков.
Предполагаю, что каждый поток следит, не убит ли один из других потоков. Однако, приостановив выполнение процесса, мы можем заглянуть в его память, используя Process Explorer. Анализ показывает, что существуют строки, которые не были показаны в IDA:
Внезапно. Я думаю, что программа проверяет эти утилиты и принудительно закрывает их, если они запущены. Это объясняет то, почему я не мог воспользоваться Process Explorer'ом, пока была запущена программа. Вполне себе способ усложнить запуск любой из этих утилит, моментально убивая их. В списке можно найти regedit, LordPE, Wireshark, regmon, filemon, procmon, tcpview, taskmgr и даже Windows Defender. Сурово. Правда, я не вижу двоюродного брата Process Explorer'a — Process Hacker.
Возвращаясь к нашим баранам нашей памяти: очевидно, что программа либо обфусцирует строки, либо дважды пакует их. В любом случае, давайте разберемся.
Выполнив поиск по памяти одной из строк в Unicode кодировке, мы видим, что строка «taskmgr» находится в секции .data. Неужели IDA соврала насчет строк? Не совсем. Пробуем еще раз, используя медленный бинарный поиск — и находим больше строк. Видимо, IDA не показывает Unicode строки при поиске по умолчанию. Можно поменять параметры поиска в IDA, нажав Alt+A и выбрав пункт Unicode.
Анализ новых строк раскрывает перед нами больше функциональности вредоносной программы.
Интересно.
Учитывая то, что наши попытки запустить Wireshark будут блокированы программой, необходимо найти функцию, отвечающую за принудительное завершение программ, и пропатчить её. Как это сделать? Поищем вызов api TerminateProcess().
Используя IDA, это не так уж сложно. В секции импорта находим ссылку на TerminateProcess.
Похоже на некий цикл, который просматривает имена процессов с помощью вызова CreateToolhelp32Snapshot и, если они удовлетворяют некому условию, завершает их. Похоже, что список имен процессов, который мы видели ранее, используется именно тут.
Итак, что же мы можем предпринять? Мы можем изменить логику программы так, что вместо вызова TerminateProcess будет происходить… а ничего не будет происходить. Проверив подпрограммы Xref-ом (eXternal REFerences), мы видимо, что функция вызывается из подпрограммы 0x00401D2A. В ней находится инструкция jnz, осуществляющая условный переход на подпрограмму, просматривающую процессы и завершающую их. Если мы сможем так пропатчить программу, что эта подпрограмма не будет вызываться, мы сможем запускать любые утилиты из черного списка.
Засучим рукава. Я предпочитаю патчить с помощью Immunity — это довольно просто, да и знаком я этим получше. Начнем с поиска продпрограммы в нашем exe. Инструкция с условным переходом находится по адресу 0x00401D4E. Нопаем всю область — таким образом, мы сразу переходим к выполнению ret вместо перехода по адресу 0x00401D2C, где происходило завершение неугодных процессов.
Возобновляем выполнение программы и пробуем запустить одну из запрещенных программ. Похоже на то, что все работает, раз regedit запустился, а Process Explorer не был принудительно завершен.
Наконец, можно провести детальный анализ сетевой активности, используя Wireshark, а также активности в файловой системе и реестре, используя procmon, да и вообще поиграться с работающей программой в Process Explorer.
Process Explorer показывает, что был отправлен SYN[5] пакет к нашему C&C серверу (да, тому самому, адрес которого мы вытащили из секции ресурсов) на 80й порт.
Wireshark дает немного больше информации. Тут мы видим не только SYN пакеты, отправляемые нашему HTTP C&C серверу, но еще и большое количество DNS запросов для получения информации о странных доменах. Что дальше?
Сервер продолжит стучаться домой, но мне это не нужно. Я мог бы модифицировать секцию ресурсов в нашем «golden_egg.exe» так, чтобы завернуть его на мой собственный HTTP сервер и исследовать его функциональность, но это довольно трудозатратно. У нас уже есть довольно многое: C&C сервер, распакованная программа, её HTTP сигнатура, а также мы знаем о её поведении. Дело закрыто. Еще одна 0day среда пришла и ушла.
Если вам хочется скачать вредонос и повозиться с ним, то можете взять его тут. Пароль «infected».
Надеюсь, это небольшое исследование окажется вам полезным. Удачного крякинга!
Автор Joe Giron
1. ↑ 0day (англ. zero day) — термин, обозначающий вредоносные программы, против которых еще не разработаны защитные механизмы или уязвимости, которые не устранены.
2. ↑ IDA Pro Disassembler (англ. Interactive DisAssembler) — интерактивный дизассемблер, который широко используется для реверс-инжиниринга.
3. ↑ Пакет Microsoft Foundation Classes (MFC) — библиотека на языке C++, разработанная Microsoft и призванная облегчить разработку GUI-приложений для Microsoft Windows путем использования богатого набора библиотечных классов.
4. ↑ UPX (the Ultimate Packer for eXecutables) — упаковщик исполняемых файлов, поддерживающий несколько различных платформ и форматов файлов.
5. ↑ SYN — пакет, отправляемый клиентом серверу для установки соединения.
Автор: foxin
