R0 CREW

Malware Analysis Tutorial 19: Anatomy of Infected Driver (Перевод: ximera)

Перейти к содержанию

Цели урока:

  1. Выполнить сравнение бинарных файлов
  2. Попрактиковаться в технике отладки
  3. Изучить заголовки исполняемых файлов

1. Введение

Сейчас мы продолжим наш анализ представленный в Уроках 17 и 18. На этот раз, нас интересует рассмотрение заражённого драйвера, и сравнение его со своей чистой (не зараженной) копией. Для этого, нам нужно выполнить некоторые «хирургические вмешательства» над вирусом и операционной системой, чтобы получить две разные версии драйвера. Напомним, что руткит заражает драйвера случайным образом, поэтому мы должны быть осторожны во время этого процесса.

Мы должны перехватить работу Max++ в двух критических точках:

  1. Сразу после того, как Max++ случайно образом выберет имя драйвера.
  2. Перед тем как Max++ вызовет функцию ZwLoadDriver() для загрузки заражённого драйвера. Мы скопируем зараженную версию драйвера из ОС для последующего сравнения.

Затем мы сможем свободно выполнить сравнение двух бинарных версий драйвера. Для этого мы будем использовать удобную утилиту под названием WinDiff. Пожалуйста, следуйте описанию, приведённому ниже, чтобы получить две разные версии драйвера.

2. Подготовка (Извлечение бинарных фалов драйверов)

(*) Скачайте и установите WinDiff.

(0) Запустите Guest XP в режиме ОТЛАДКИ. Теперь на вашей Host XP, запустите консоль windows и перейдите в каталог «C:\Program Files\Debugging Tools for Windows (x86)» (каталог в который установлен WinDBG). Наберите в консоли «windbg -b -k com:pipe,port=\.\pipe\com_12» (проверьте номер COM порта в настройках вашей виртуальной машины). После того как WinDbg проинициализируется, нажмите «g» дважды чтобы продолжить.

(1) Теперь запустите IMM (Immunity Debugger) в WinXP, очистите все программные брэйкпойнты, а так же аппаратные брэйкпойнты в IMM (их можно найти в View->Breakpoints и View->Hardware Breakpoints).

(2) Перейдите по адресу 0x4012DC и установите аппаратный брэйкпойнт. (Почему не программный? Потому что эта секция самораспаковывающаяся и перезаписывающаяся, поэтому программные брэйкпойнты будут потеряны). Обратите особое внимание при переходе на 0x4012DC, щелкните правой кнопкой по этой строке и установите аппаратный брэйкпойнт(сейчас это совершенно бредовый код).

(3) Нажмите F9 через некоторое время выполнение дойдёт до 0x4012DC. Вы столкнётесь с несколькими брэйкпойнтами перед тем как попадете на 0x4012DC. Если вы получите предупреждение, они будут вызваны трюками «int 2d» (которые объяснялись в главах: 3, 4 и 5 данного руководства). Просто игнорируйте их, и продолжайте(используя F9) выполнение до 0x4012DC.

На рис.1 изображён код, который вы должны увидеть. Как вы видите сразу перед вызовом RtlAddVectoredException, аппаратный брэйкпойнт устанавливает прерывание на вызов LdrLoadDll. (Детали смотрите в главе 11)

Рис. 1. Код по адресу 0x4012DC

(4) Теперь пролистайте вниз на 2 страницы и установите ПРОГРАММННЫЙ БРЭЙКПОЙНТ на 0x401417. Это находится сразу после вызова LdrLoadDll(«lz32.dll»), где Max++ завершает загрузку lz32.dll. Затем нажмите SHIFT+F9 пока не достигнете 0x401417 (вы попадёте на 0x7C90D500 дважды, это находится где-то внутри ntdll.zwMapViewSection который вызывается из LdrLoadDll).

Рис. 2. Код по адресу 0x401407

(5) Теперь мы установим брэйкпойнт на 0x3C1E77. Перейдите на 0x3C1E77. Нажмите SHIFT+F9 для продолжения до 0x3C1E77. (Вы должны увидеть предупреждение о выходе за пределы сегмента кода, просто игнорируйте их.)

На рис 3. изображён код, который вы должны увидеть по адресу: 0x3C1E77. Это сразу после циклически-случайного подбора системных модулей для заражения. Как показано на рисунке, на данный момент, драйвером для заражения является «afd.sys».

*** Теперь скопируйте adf.sys из c:\Windows\System32\Drivers на ваш рабочий стол и переименуйте его в afd_v1.sys

Рис. 3. Случайный выбор имени файла

(6) Теперь мы установим брэйкпойнт на 0x3C1B3E. (как показано на Рис.4) Это сразу перед тем как zwLoadDriver вызывается для причинения вреда системе.

*** Теперь перейдите в c:\Windows\System32\Drivers и снова скопируйте afd.sys и переименуйте его в afd_v2.sys. Теперь наша работа по извлечению файлов закончена. Мы можем закрыть IMM.

Рис.4. Получаем заражённый драйвер

3. Сравнивание чистого и заражённого файлов

На рисунке 5 показано сравнивание «чистого» и заражённого файла драйвера, с использованием утилиты WinDiff. Давайте взглянем. Слева на изображении, вы можете увидеть две цветные линии, одна соответствует afd_v1.sys, вторая соответствует afd_v2.sys. Вы можете заметить, это что afd_v2.sys немного шире.

Первое различие между двумя файлами это блок 1 (потому что число байтов в блоках файлов поменялось когда Max++ сделал инъекцию дополнительной логики),

Рис. 5. Сравнивание чистого и заражённого файла с помощью WinDiff

Второе различие это участок( отмеченный блок 2) начиная с 2й и до 28й строки. Это потому что Max++ заинжектил (фактически вставил) много информации. Красная линия соответствует оригинальному содержанию, а жёлтая линия соответствует новому, вставленному коду. Если вы взгляните на выделенную область (справа на рис.5) вы можете найти много интересной информации:

  1. Это HTTP запрос для /install/setup.php.
  2. Строка «C2CAD972#4079…» - это имя скрытого дискового раздела.

Остальная часть этих двух фалов тоже очень интересна. Если вы обратите внимание на остальную часть двух полос (отмеченный блок 2 слева). Он показывает то что Max++ проделал отличную работу по сохранению оригинальной логики afd.sys. Это сделано для того чтобы вставить дополнительную логику в начале, и таким образом повторно проходит в потоке управления, чтобы после вредоносного кода, драйвер выполнял свою первоначальную функциональность.

На рис. 6, показан дизассемблированный код afd_v2.sys. Вы можете увидеть некоторые действия связанные с HTTP запросами и скрытыми дисками. Обратите внимание если бы вы попробовали загрузить afd_v2.sys используя Immunity Debugger напрямую, IMM просто покрашился бы. Вам нужно отладить IMM и перезаписать некоторые его инструкции для того чтобы сделать его рабочим когда будет происходить ошибка сегментации памяти.

По факту, с тех пор как мы стали выполнять отладку на уровне ядра (драйверов), IMM не вполне соответствует для данных операций. В следующей части, мы покажем вам, как использовать WinDbg для выполения анализа.

Рис. 6. Дизассемблированный код afd v2.sys

Вопросы дня:

  1. Каков размер внедренного кода.
  2. Можете ли вы определить, где начинаются и где заканчиваются внутренности Max++, сразу после того, как он записал свой код в файл драйвера.

© Translated by ximera from r0 Crew

UP