Реверсинг малвари для начинающих. Инструменты скрытия вредоносной активности

В сегодняшнем материале мы разберем технологии скрытия вредоносной активности в целевой системе, усвоим, что такое rootkits- и bootkits-инструментарий, узнаем об инжектах (внедрениях) в процессы и DLL-библиотеки и, конечно же, рассмотрим, как все это детектировать и анализировать на живых примерах.

WARNING

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи. Если ты что-то делаешь — будь уверен и понимай, что ты делаешь!

Malware tools, или искусство сокрытия

В предыдущих уроках мы анализировали живые примеры малвари — от самых простых семплов до многократно запакованных. В одной из прошлых статей мы также рассказывали о способах противодействия анализу, заложенных в код малвари. Это шифрование с упаковкой, антиотладочные методы, фичи, препятствующие дисассемблированию, запуску малвари на виртуальных машинах, и так далее. Отличительной особенностью всех этих примеров было то, что код, противодействующий анализу, содержался непосредственно в самом файле семпла (exe-файле). Но совершенствование современных алгоритмов сигнатурного и эвристического сканирования, поведенческий анализ, использование изолированных сред (типа песочниц) заставляют вирусописателей изобретать новые и хитрые способы противодействия.

Поэтому речь сегодня о malware tools — это специальное программное обеспечение, которое само по себе не вредоносно, но загружается на целевую систему, чтобы заразить ее малварью и скрыть все следы. Самый идеальный вариант для злоумышленника — это когда антивирус или подобное ему ПО просто не может детектировать малварь, запущенную на зараженной машине. А раз нет прецедента, соответственно, нет и паники, нет и действий для активного лечения системы. И для достижения этих целей писатели вредоносного кода используют техники, скрывающие его присутствие в системе. Некоторые из них мы разберем более подробно.

Rootkit: невидимый ниндзя

Руткит (англ. rootkit) — это набор программных средств (к примеру, исполняемых файлов, скриптов, некоторых конфигурационных файлов), скрывающих присутствие запущенного malware-кода в целевой системе. В числе их действий:

• маскировка объектов (таких как процессы в памяти, файлы и директории);
• нелегитимное управление системой (изменение событий, происходящих в зараженной системе);
• сбор различных данных (hardware- и software-параметров, конфирмации TCP/IP, рабочего окружения и так далее).

Сам термин rootkit пришел из мира UNIX, где под этим словом понимается набор системных утилит или специальный модуль ядра, который злоумышленник устанавливает на взломанной системе сразу после получения прав суперпользователя. Эти утилиты преимущественно служат для «заметания следов» вторжения в систему, делают незаметными запущенные в системе снифферы, сканеры, кейлоггеры, троянские программы, замещающие основные утилиты в операционной системе UNIX/Linux. Помимо этого, rootkit-утилиты позволяют злоумышленнику закрепиться во взломанной системе и спрятать следы своей деятельности, скрывая файлы, процессы в памяти, а также само присутствие руткита в системе.

Как мы выяснили из описания, руткит работает в привилегированном режиме (от имени root’a или учетки NT AUTHORITY\\System) и, соответственно, имеет самые высокие привилегии на исполнение кода и доступ к ресурсам системы. По уровню привилегий все руткиты можно разделить на руткиты:

• уровня пользователя (user-mode, режим, в котором выполняются все основные программы);
• уровня ядра (kernel-mode, в том числе драйверы), или так называемое ring 0.

Другие статьи в выпуске:

Xakep #218. Смотри во все глаза

• Содержание выпуска
• Подписка на «Хакер»-60%

По принципу действия в зараженной системе:

• изменяющие алгоритмы выполнения системных функций (Modify execution path);
• изменяющие системные структуры данных (Direct kernel object manipulation).

Более подробно о связи ring 0 и rootkits можно почитать в этой статье, в статье на форуме АНТИЧАТ и в небольшом описании для Linux.

Семейство ОС Windows также подвержено заражению руткитами. Здесь наиболее распространены такие методы, как захват таблиц вызовов (IAT, IDT, SSDT, GDT), перехват функций (например, модификацией начальных байтов), непосредственное изменение системных объектов (DKOM), методы использования драйверов.

Если очень кратко, то наиболее вероятные варианты — это либо захват таблиц вызова, либо перехват системных вызовов в режиме работы системного драйвера. Для первого случая таблица вызовов представляет собой некий массив, в котором каждый его элемент хранит адрес соответствующей процедуры. Такие таблицы существуют и в режиме ядра (IDT, CPU MSRs, GDT, SSDT, IRP dispatch table), и в режиме пользователя (Import Address Table, IAT).

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

• блокировать вызовы, производимые определенными приложениями (например, антивирус);
• замещать исходную процедуру (подмена бинарного кода);
• вести мониторинг системы, перехватывая вводимые параметры;
• фильтровать или вовсе отбрасывать выходные параметры.

Для второго случая при работе руткита в режиме системного драйвера используется схожая схема. Модель драйверов Microsoft поддерживает многоуровневую архитектуру, поэтому запрос ввода/вывода (I/O request, обмен данными между приложениями и драйверами) может обслуживаться серией подключенных драйверов, каждый из которых выполняет свою задачу. В актуальной на сегодня модели WDM определено три типа драйверов: драйвер шины, функциональные драйверы и драйверы-фильтры.

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

Более подробно о программировании и функционировании программы в режиме драйвера можно почитать в архивах WASM — раздел «Секреты Win32. Драйверы режима ядра».

В операционных системах UNIX/Linux заражение руткитами реализуется:

• подменой основных системных утилит;
• загрузкой модифицированного модуля ядра, который позволяет перехватывать таблицы системных вызовов (sys_call_table);
• закладкой, основанной на модификации физической памяти ядра.

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

Для тех, кто хочет подробно покопаться в коде, на этом ресурсе выложены исходники WinNT-руткита Nerzhul Rootkit, написанного на C, и код руткита Agony ring 0. В одной из старых статей нашего журнала можно почитать, как написать свой non-kernel-руткит на Perl.

Bootkit

Более изощренный метод реализации руткитов — модификацию загрузочной записи MBR и загрузку руткита до старта ядра операционной системы — используют так называемые буткиты.

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

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

Более подробно о методах работы буткитов можно почитать здесь, здесь и еще вот здесь.

Методы детектирования и борьба с руткитами

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

К примеру, известен алгоритм отлова MEP-руткитов. Его суть заключается в том, что одна и та же информация регистрируется несколькими способами — с использованием API и «напрямую», после чего полученные данные сравниваются в поисках расхождений. Наиболее часто сканируются таблицы импорта и таблицы вызовов Native API, а также структурно вся файловая система.

Базовый арсенал средств отлова руткитов основывается на следующих методах.

1. Сигнатурный поиск. Применяется еще со времен первых антивирусов и представляет собой поиск в проверяемом файле уникальной цепочки байтов (сигнатуры), присущей вредоносной программе.
2. Эвристический или поведенческий анализатор. Эта технология основывается на поиске отклонений в настройках системы, конфигурационных файлах Linux или реестре Windows, подозрительном поведении процессов и модулей и так далее.
3. Контроль целостности. Этот тип поиска основан на сравнении контрольной суммы (MD5 и тому подобное) или цифровой подписи разнообразных системных файлов с базой, содержащей контрольную сумму оригинальных файлов. В случае несовпадения программа делает вывод, что файл был модифицирован или вовсе заменен.

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

В качестве более полного ликбеза на данную тему могу порекомендовать почитать эту статью и вот эту книжку: A Comparitive Analysis of Rootkit Detection Techniques, которая доступна для загрузки и чтения в формате PDF. И не забудь ознакомиться с работой нашего соотечественника Игоря Коркина, посвященной форензике оперативной памяти и поиску в ней руткитов, — Applying memory forensics to rootkit detection.

INFO

Malware tools, такие как загрузчики (downloaders and droppers), rootkits, bootkits, в большинстве случаев сами по себе не являются вредоносным ПО в классическом понимании. Однако с помощью подобного инструментария злоумышленник может инфицировать целевую систему, при этом заметая следы взлома и заражения, что значительно усложняет последующий поиск и детектирование malware внутри системы.

Внедрение в процесс, или DLL Injection

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

Неплохой пример кода с DLL-инжектом (внедрением в код процесса) можно посмотреть в статье на Хабре. Об усовершенствованном методе, а именно как внедрить DLL в чужой процесс незаметно, то есть не храня на диске файл самой DLL, можно узнать в одной из статей нашего журнала.

Использование Native API для внедрения в процесс

Нативный API-интерфейс Windows фактически предлагает нам ряд функций, которые позволяют внедряться в исполняемый код и управлять другими приложениями. Более подробно можно узнать из MSDN-документации.

В целом весь процесс взлома можно разделить на четыре самостоятельных этапа:

• присоединение к родительскому процессу;
• выделение в процессе памяти, необходимой под внедряемый код;
• копирование DLL в память процесса с определением в соответствующие адреса памяти;
• запуск в процессе секции с внедренным кодом присоединенной библиотеки DLL.

Каждый из этих шагов может быть реализован с помощью одного или нескольких методов программирования. Важно помнить, что каждый метод инжекта имеет как достоинства, так и недостатки. Более подробно об инжекте в процессы с описанием примеров на С++ можно почитать в блоге OpenSecurity.

Winlogon hook

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

HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\

Svchost hook

Более продвинутый, чем предыдущий, и наиболее широко используемый хук. Вредоносные программы часто устанавливаются в систему в качестве службы Windows. После инсталляции в систему малварь висит в процессах как общесистемная служба svchost.exe, что делает ее менее приметной.

Как известно, svchost.exe — это универсальное имя для всех хост-процессов в виде сервисов (служб) Windows, которые стартуют при запуске системы нативных DLL-библиотек, обеспечивающих различную функциональность ОС — сетевое взаимодействие, печать, обнаружение внешних подключаемых устройств и работу с ними и так далее. Очень часто каждый запущенный в памяти экземпляр svchost.exe содержит группу потоков (тредов, от англ. thread — нить).

Соответствующая этим службам ветка реестра располагается по данному адресу:

HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Svchost

А сами названия служб определены в реестре по следующему адресу:

HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services\\ServiceName

Keylogger hook

Еще один вариант системного хука — перехват событий, поступающих от клавиатуры (WM_KEYDOWN, KEYBOARD_INPUT_DATA) или мыши (PS/2- или USB-драйвер порта).

Замещение процесса в оперативной памяти

Еще вариант запустить вредоносный код в системе — не внедрять malware-код в DLL или запущенный процесс, а полностью заменить легитимный процесс на вредоносный, то есть перезаписать память запущенного процесса на содержимое вредоносного исполняемого файла. Замещение процесса используется, когда автор вредоноса хочет замаскировать малварь под полностью легитимный процесс, без риска вызвать сбой или вовсе крах процесса, как это возможно при DLL Injection. Этот метод позволяет выполняться вредоносной программе с теми же привилегиями, что и процесс, который был запущен легитимно от имени пользователя или системы.

Эта процедура выполняется только в приостановленном состоянии (SUSPEND). Иными словами, это означает, что, пока процесс будет загружаться в память, его основной поток (thread) попадает в состояние приостановки. Легитимная программа не сможет ничего сделать, пока внешняя (вирусная) программа не возобновит основной поток, вызывая основную программу к запуску. Под отладчиком это можно заметить, когда мы видим, что используется функция CREATE_SUSPENDED (0x4), запущенная с параметром dwCreationFlags при выполнении вызова на CreateProcess.

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

ExpandedWrap disabled
void AntiInject ()
{
  HANDLE hProc = GetCurrentProcess();
  while (TRUE) {
    BlockAPI(hProc, "NTDLL.DLL", "LdrLoadDll");
    Sleep (100);
  }
}

BOOLEAN BlockAPI (HANDLE hProcess, CHAR *libName, CHAR *apiName)
{
  CHAR pRet[]={0xC3};
  HINSTANCE hLib = NULL;
  VOID *pAddr = NULL;
  BOOL bRet = FALSE;
  DWORD dwRet = 0;

  hLib = LoadLibrary (libName);
  if (hLib) {
    pAddr = (VOID*)GetProcAddress (hLib, apiName);
    if (pAddr) {
      if (WriteProcessMemory (hProcess,
                      (LPVOID)pAddr,
                      (LPVOID)pRet,
                      sizeof (pRet),
                      &dwRet )) {
        if (dwRet) {
          bRet = TRUE;
        }
      }
    }
    FreeLibrary (hLib);
  }
  return bRet;
}

Если посмотреть внимательно на код, то мы сможем понять суть его работы: он затирает адрес LdrLoadDll, в результате чего все последующие вызовы LoadLibrary приведут к однозначному падению программы.

Основные инструменты анализа

Отладчик ядра WinDbg

Программа WinDbg — это отладчик уровня ядра от всем известной Microsoft. Он менее популярен, чем OllyDbg, но имеет много преимуществ, наиболее весомое из которых — возможность исследования ядра системы в режиме отладки. Помимо графического (GUI) интерфейса, в WinDbg реализован интерфейс командной строки (CLI), содержащий почти все необходимые для наших исследований функциональные возможности.

Рабочее окно отладчика WinDbg поддерживает просмотр памяти напрямую из командной строки. Для этого используется команда чтения стека адресов в памяти:

dx addressToRead

где dx — это один из нескольких вариантов того, как данные будут отображаться.

Загрузчик драйверов OSR Driver Loader

Данная утилита позволяет в ручном и автоматическом (запуск Windows-служб) режиме устанавливать, удалять, запускать и приостанавливать драйверы, загружаемые в память из файлов, хранящихся на жестком диске. Эта весьма полезная тулза будет помогать нам в дальнейшем при выполнении лабораторных работ.

VirtualKD Faster Windows Kernel debugging with Virtual Machines

VirtualKD — это быстрый, легкий отладчик режима ядра, адаптированный под виртуальные машины VMware и VirtualBox.

Программа интегрируется с WinDbg и значительно сокращает время отладки.

 

Литература и WWW

Тема malware tools очень обширна и часто заслуживает минимум нескольких статей, посвященных всем аспектам использования руткитов, буткитов, firmware-закладок, хуков, внедрений в исполняемые процессы и замещений. Поскольку объем данной статьи не позволяет рассказать обо всем, мы можем порекомендовать тебе, дорогой друг, несколько хороших книг и ресурсов в сети Интернет для самостоятельного изучения матчасти :).

 

Rootkits: Subverting the Windows Kernel (Greg Hoglund, Jamie Butler)

Подробнее: на Amazon.

Одна из немногих книг, в целом посвященная руткитам и технологиям их обнаружения в Windows-системах. Настоящий must have для начинающего исследователя, неискушенного в тонкостях функционирования Windows.

 

Inside Windows Debugging (Developer Reference)

Подробнее: на Amazon.

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

 

Rootkits and Bootkits. Reversing Modern Malware and Next Generation Threats

Подробнее: на сайте No Starch Press.

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

 

Архив WASM.RU, посвященный низкоуровневому программированию

Где взять: здесь :).

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

WARNING

Будь осторожен при скачивании и распаковке архивов с образцами malware на компьютер. Все исследования выполняй только в изолированной виртуальной среде! Не выполняй действий, в которых на 100% не уверен! И не забывай делать регулярные snapshot системы для быстрого отката.

Анализ семпла malware01

Инструменты:

1. IDA Pro.
2. VirtualKD.
3. Cerbero Profiler или Cerbero PE Insider.
4. WinDbg (GUI).

Первым делом запускаем PEiD и смотрим, что за файл перед нами. Итак, файл ничем не упакован, написан на С++ и по структуре представляет собой Win32-приложение. Что ж, идем дальше. На очереди программа, к которой мы еще не обращались, Cerbero Profiler, — она часто используется в форензике и позволяет заглянуть внутрь нашего семпла. На первый взгляд все чисто, однако есть подозрения, что наш исполняемый файл — это контейнер и содержит в себе несколько PE-файлов, которые, очевидно, будут распакованы при запуске семпла на исполнение.

Откроем нашего старого друга IDA Pro и загрузим туда семпл.

Смотрим главный графический вывод программы и замечаем, что наш семпл действительно контейнер и после запуска он распаковывает в системную директорию Windows некий файл, похожий на драйвер: C:\\Windows\\System32\\Mlwx486.sys.

Идем по этому пути, открываем директорию, и что мы видим? Такого файла там нет! Как быть? Очень просто — попробуем выдернуть этот файл из самого экзешника. Возвращаемся к IDA Pro, скроллим листинг и видим функцию DriverEntry, которая позволяет нам предположить, что извлеченный файл все-таки программа, работающая в режиме драйвера.

Функция DriverEntry приводит нас к коду в подпрограмме (с 0x10706). Вредонос пытается изменить поток таблицы дескрипторов ядра и установить перехватывающий хук, вызывающий NtQueryDirectoryFile. После этого вредонос вызывает MmGetSystemRoutineAddress, чтобы получить указатель на NtQueryDirectoryFile и KeServiceDescriptorTable подпрограммы. После этого он просматривает таблицу дескрипторов и ищет нужный адрес NtQueryDirectoryFile.

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

Смотрим дальше. В драйвере используется функция NtQueryDirectoryFile. Как говорит нам документация MSDN, эта функция возвращает информацию о файлах в каталоге, указанных на данный дескриптор файла. Мы видим также, что вызывается функция RtlCompareMemory.

Дальше идет поиск и сравнение, и если обнаружено совпадение между именем и строкой, содержащей значение Mlwx, то данный файл будет скрыт. Теперь введем команду через WinDbg:

kd> dps nt!KiServiceTable l 100

и смотрим вывод, а именно данные в таблице.

Также нам необходимо поставить точку останова с помощью команды bu Mlwx486!DriverEntry. Еще раз запускаем семпл и смотрим WinDbg. Произошел останов выполнения кода в точке nt!IopLoadDriver+0x66a. После этого идет код загрузки драйвера в память !object \\Driver. Однако функция DriverInit еще не была выполнена, и ты можешь установить в этом месте еще один брейк-пойнт. Ставим его.

Запускаем команду:

runing kd> dps nt!KiServiceTable l 100

Видим, что таблица дескрипторов была изменена! Вот оно! 🙂 То, что и требовалось найти! В целом можно сказать, что малварь использует ring 0 привилегии и детектируется как руткит, позволяющий скрывать вредоносные файлы.

Анализ семпла malware02

Инструменты:

1. IDA Pro.
2. OllyDbg.
3. Process Monitor.

Первым делом, как и ранее, грузим наш семпл в PEiD. Что показывает программа? Файл ничем не упакован и не зашифрован. Что ж, распаковку мы проходили в прошлом уроке, сегодня же сосредоточимся на изучении других особенностей малвари. Открываем IDA Pro и грузим наш файл, смотрим импорт, видим две строки: Installe и DllEntryPoint... Ничего не напоминает?

Запускаем семпл и подключаем наш следующий инструмент, а именно Process Monitor, и сразу наблюдаем следующую картину — малварь добавила запись в раздел реестра:

HKLM\\SOFTWARE\\Microsoft\\WindowsNT\\CurrentVersion\\Windows\\AppInit_DLLS

А также распаковала себя и скопировала как DLL-библиотеку в следующую директорию:

C:\\Windows\\System32\\spoolvxx32.dll

И завершающим аккордом стало открытие INI-файла (ого, привет из девяностых. — Прим. ред.) в директории

C:\\Windows\\System32\\Lab11-02.ini

Запускаем OllyDbg, ниже мы видим код, ответственный за загрузку конфигурационных параметров малвари из INI-файла.

Если обратиться к нативной документации MSDN, то можно прочитать, что AppInit_DLLs — это специальный механизм, который позволяет загружать произвольный список DLL-библиотек в каждый процесс памяти с привилегиями пользователя. Добавив AppInit_DLLs в ветку реестра

HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\ 

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

Если мы посмотрим на подпрограмму @0x100012A3, то увидим, что этот код пытается получить адрес, связанный с wsock32.dll. Затем он передает управление подпрограмме @0x10001203.

Подпрограмма @0x10001203 использует технику хуков (последовательных перехватов). Код сначала получает значение байтового смещения от начала функции, содержащей хук. Затем он использует метод virtualprotect, чтобы выбрать 5 байт от начала подпрограммы по адресу PAGE_EXECUTE_READWRITE. Это позволит переписать код jmp (перехода) на функцию хука. Наконец-то можно будет очистить 5 байт памяти и вернуться к старым атрибутам. Смотрим скриншот с куском кода в IDA Pro.

Итак, как видим, малварь содержит хук для трех программ: THEBAT.EXE, OUTLOOK.EXE, MSIMM.EXE. Что-нибудь узнаем? 🙂

Используя хук на wsock32.dll, малварь может отправить какие-то входные данные для этих почтовых программ.

Быть может, мы что-то забыли? У малвари есть INI-файл, давай посмотрим для чего. После считывания данных из этого конфигурационного файла вредонос расшифровывает его с помощью вызова подпрограммы @0x100016CA.

Если мы погрузимся в эту подпрограмму, то достаточно легко сможем понять, что это xor-функции декодирования. Вернемся к OllyDbg, чтобы посмотреть, что получится при трассировке выполнения кода малвари. Эта декодированная строка будет использоваться в следующей функции:

Мы видим, что при выполнении кода создается новый буфер для некоторого адреса billy@malwareanalysisbook.com>\\r\\n, что позволяет этой части кода отправлять данные через оригинальную функцию отправки в почтовой программе. По сути, программа перехватывает легитимный адрес почты и подменяет его на указанный. А INI-файл служит хранилищем этих данных, зашифрованных через xor-функцию.

Заключение

Сегодня наша копилка знаний пополнилась еще одним важным элементом из мира реверсинга малвари. Мы рассмотрели malware tools, коснулись теории вопроса, рассмотрели основные методы и способы скрытия присутствия инфекции в системе. Безусловно, в одной статье всего не объять, так что дерзай, изучай, анализируй и прокачивай свои скиллы исследователя! Как всегда, буду признателен за комментарии и готов ответить на все возникающие вопросы, так что смело пиши.

Всем удачи в исследованиях! И до новых встреч!

WWW

Исходные семплы малвари (пароль — malware)