• Лабораторная работа 1-1 ..................................................................................... 477

• Лабораторная работа 1-2 ..................................................................................... 479

• Лабораторная работа 1-3 ..................................................................................... 480

• Лабораторная работа 1-4 ..................................................................................... 481

• Лабораторная работа 3-1 ..................................................................................... 482

• Лабораторная работа 3-2 ..................................................................................... 485

• Лабораторная работа 3-3 ..................................................................................... 490

• Лабораторная работа 3-4 ..................................................................................... 492

• Лабораторная работа 5-1 ..................................................................................... 494

• Лабораторная работа 6-1 ..................................................................................... 501

• Лабораторная работа 6-2 ..................................................................................... 503

• Лабораторная работа 6-3 ..................................................................................... 507

• Лабораторная работа 6-4 ..................................................................................... 511

• Лабораторная работа 7-1 ..................................................................................... 513

• Лабораторная работа 7-2 ..................................................................................... 517

• Лабораторная работа 7-3 ..................................................................................... 519

• Лабораторная работа 9-1 ..................................................................................... 530

• Лабораторная работа 9-2 ..................................................................................... 539

• Лабораторная работа 9-3 ..................................................................................... 545

• Лабораторная работа 10-1 ................................................................................... 548

• Лабораторная работа 10-2 ................................................................................... 554

• Лабораторная работа 10-3 ................................................................................... 560

• Лабораторная работа 11-1 ................................................................................... 566

• Лабораторная работа 11-2 ................................................................................... 571

• Лабораторная работа 11-3 ................................................................................... 581

• Лабораторная работа 12-1 ................................................................................... 586

• Лабораторная работа 12-2 ................................................................................... 590

• Лабораторная работа 12-3 ................................................................................... 597

• Лабораторная работа 12-4 ................................................................................... 599

• Лабораторная работа 13-1 ................................................................................... 607

• Лабораторная работа 13-2 ................................................................................... 612

• Лабораторная работа 13-3 ................................................................................... 617

• Лабораторная работа 14-1 ................................................................................... 626

• Лабораторная работа 14-2 ................................................................................... 632

• Лабораторная работа 14-3 ................................................................................... 637

• Лабораторная работа 15-1 ................................................................................... 645

• Лабораторная работа 15-2 ................................................................................... 646

• Лабораторная работа 15-3 ................................................................................... 652

• Лабораторная работа 16-1 ................................................................................... 655

• Лабораторная работа 16-2 ................................................................................... 660

• Лабораторная работа 16-3 ................................................................................... 665

• Лабораторная работа 17-1 ................................................................................... 670

• Лабораторная работа 17-2 ................................................................................... 673

• Лабораторная работа 17-3 ................................................................................... 678

• Лабораторная работа 18-1 ................................................................................... 684

• Лабораторная работа 18-2 ................................................................................... 685

• Лабораторная работа 18-3 ................................................................................... 686

• Лабораторная работа 18-4 ................................................................................... 689

• Лабораторная работа 18-5 ................................................................................... 691

• Лабораторная работа 19-1 ................................................................................... 696

• Лабораторная работа 19-2 ................................................................................... 699

• Лабораторная работа 19-3 ................................................................................... 703

• Лабораторная работа 20-1 ................................................................................... 712

• Лабораторная работа 20-2 ................................................................................... 713

• Лабораторная работа 20-3 ................................................................................... 717

• Лабораторная работа 21-1 ................................................................................... 723

• Лабораторная работа 21-2 ................................................................................... 728

INetSim также регистрирует все входящие запросы и соединения, что особенно полезно для определения подключения вредоносной программы к стандартной службе и просмотра выполняемых запросов. Кроме того, INetSim чрезвычайно гибко настраивается. Например, можно задать страницу или объект, возвращаемый после запроса. Если вы поняли, что исследуемая вредоносная программа ищет конкретную веб-страницу и только после неё продолжает исполнение, эту страницу можно предоставить. Также можно изменить порт прослушивания различных служб, что полезно, если вредоносная программа использует нестандартные порты.

Поскольку INetSim создавалась с расчётом на анализ вредоносных программ, в ней есть множество уникальных возможностей, например служба Dummy, регистрирующая все полученные от клиента данные независимо от порта. Dummy особенно полезна для захвата всего трафика, который клиент отправляет на порты, не занятые каким-либо другим модулем службы. С её помощью можно зарегистрировать все порты, к которым подключается вредоносная программа, и соответствующие отправляемые данные. Как минимум завершится установление TCP-соединения, а возможно, удастся собрать и дополнительные данные.

Базовые динамические средства на практике

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

1. Запустить procmon, установить фильтр по имени исполняемого файла вредоносной программы и очистить все события непосредственно перед запуском.

2. Запустить Process Explorer.

3. Сделать первый снимок реестра с помощью Regshot.

4. Настроить виртуальную сеть требуемым образом с помощью INetSim и ApateDNS.

5. Настроить регистрацию сетевого трафика с помощью Wireshark.

На рисунке 3-12 приведена схема виртуальной сети, которую можно создать для анализа вредоносных программ. Она содержит два узла: виртуальную машину Windows для анализа вредоносных программ и виртуальную машину Linux с работающей INetSim. Посредством INetSim виртуальная машина Linux прослушивает множество портов, включая HTTPS, FTP и HTTP. Виртуальная машина Windows прослушивает порт 53 для DNS-запросов с помощью ApateDNS. В качестве DNS-сервера виртуальной машины Windows настроен локальный компьютер 127.0.0.1. ApateDNS настроена на перенаправление к виртуальной машине Linux 192.168.117.169.

Если попытаться открыть сайт в браузере виртуальной машины Windows, DNS-запрос будет разрешён ApateDNS, которая перенаправит его на виртуальную машину Linux. Затем браузер выполнит запрос GET через порт 80 к серверу INetSim, прослушивающему этот порт в виртуальной машине Linux.

Рисунок 3-12. Пример виртуальной сети

Посмотрим, как эта настройка работает на практике, исследовав вредоносную программу msts.exe. Мы завершаем первоначальную настройку, а затем запускаем msts.exe в виртуальной машине для анализа. Через некоторое время останавливаем захват событий в procmon и создаём второй снимок Regshot. После этого начинаем анализ следующим образом:

1. Исследуем ApateDNS, чтобы выяснить, выполнялись ли DNS-запросы. Как показано на рисунке 3-13, вредоносная программа отправила DNS-запрос для www.malwareanalysisbook.com.

Рисунок 3-13. Запрос ApateDNS к www.malwareanalysisbook.com

2. Просматриваем результаты procmon на предмет изменений файловой системы. На рисунке 3-14 видны операции CreateFile и WriteFile с порядковыми номерами 141 и 142 для файла C:\WINDOWS\system32\winhlp2.exe. При дальнейшем исследовании мы сравниваем winhlp2.exe с msts.exe и видим, что они идентичны. Следовательно, вредоносная программа копирует себя в этот каталог.

Рисунок 3-14. Вывод Procmon с установленным фильтром msts.exe

3. Сравниваем два снимка Regshot для выявления изменений. В показанных ниже результатах видно, что вредоносная программа установила значение автозапуска winhlp в HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Записанные в это значение данные указывают место, куда программа скопировала себя, C:\WINDOWS\system32\winhlp2.exe, и этот новый двоичный файл будет исполнен при перезагрузке системы.

4. Используем Process Explorer, чтобы исследовать процесс и определить, создаёт ли он мьютексы или прослушивает входящие соединения. На рисунке 3-15 видно, что msts.exe создаёт мьютекс, также называемый mutant, с именем Evil1 под номером ①. Мьютексы подробно рассматриваются в главе 7, но сейчас достаточно знать, что msts.exe, вероятно, создала его, чтобы одновременно работал только один экземпляр вредоносной программы. Если мьютекс достаточно уникален, он может служить превосходным отпечатком вредоносной программы.

5. Просматриваем журналы INetSim на предмет запросов и попыток подключения к стандартным службам. Первая строка показанного ниже журнала сообщает, что вредоносная программа обменивается данными через порт 443, но не использует стандартный протокол Secure Sockets Layer (SSL), на что указывают ошибки под номером ①.

Рисунок 3-15. Исследование активного процесса msts.exe в Process Explorer

6. Просматриваем захват Wireshark в поисках сетевого трафика, созданного вредоносной программой. Используя INetSim во время захвата с помощью Wireshark, можно перехватить установление TCP-соединения и исходные пакеты данных, отправленные вредоносной программой. Как показано на рисунке 3-16, содержимое потока TCP через порт 443 представляет собой случайные данные ACSII, что часто указывает на нестандартный протокол.

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

Рисунок 3-16. Wireshark показывает нестандартный сетевой протокол

Заключение

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

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

Лабораторные работы Лабораторная работа 3-1

Проанализируйте вредоносную программу из файла Lab03-01.exe с помощью средств базового динамического анализа.

Вопросы

1. Какие импортируемые функции и строки содержит эта вредоносная программа?

2. Каковы индикаторы вредоносной программы на уровне компьютера?

3. Существуют ли полезные сетевые сигнатуры этой вредоносной программы? Если да, каковы они?

Лабораторная работа 3-2

Проанализируйте вредоносную программу из файла Lab03-02.dll с помощью средств базового динамического анализа.

Вопросы

1. Как заставить вредоносную программу установить себя?

2. Как запустить вредоносную программу после установки?

3. Как найти процесс, внутри которого работает эта вредоносная программа?

4. Какие фильтры можно установить в procmon для получения сведений?

5. Каковы индикаторы вредоносной программы на уровне компьютера?

6. Существуют ли полезные сетевые сигнатуры этой вредоносной программы?

Лабораторная работа 3-3

Запустите вредоносную программу из файла Lab03-03.exe в безопасной среде, наблюдая за ней с помощью средств базового динамического анализа.

Вопросы

1. Что вы замечаете при наблюдении за вредоносной программой в Process Explorer?

2. Удаётся ли определить какие-либо изменения в действующей памяти?

3. Каковы индикаторы вредоносной программы на уровне компьютера?

4. Каково назначение этой программы?

Лабораторная работа 3-4

Проанализируйте вредоносную программу из файла Lab03-04.exe с помощью средств базового динамического анализа. Эта программа дополнительно исследуется в лабораторных работах главы 9.

Вопросы

1. Что происходит при запуске этого файла?

2. Что создаёт препятствие для динамического анализа?

3. Существуют ли другие способы запустить эту программу?

Таблица 4-9. Условные переходы

Инструкции повторения

Инструкции повторения представляют собой набор инструкций для работы с буферами данных. Обычно буферы имеют форму массива байтов, но могут состоять также из одинарных или двойных слов. В этом разделе мы сосредоточимся на массивах байтов. (Intel называет эти инструкции строковыми, однако мы не будем использовать этот термин, чтобы не путать их со строками, которые обсуждались в главе 1.)

Самые распространённые инструкции работы с буферами данных - movsx, cmpsx, stosx и scasx, где x = b, w или d соответственно для байта, слова или двойного слова. Эти инструкции работают с данными любого типа, но в данном разделе нас интересуют байты, поэтому мы будем использовать movsb, cmpsb и так далее.

В этих операциях используются регистры ESI и EDI. ESI является регистром индекса источника, а EDI - регистром индекса назначения. ECX используется как переменная-счётчик.

Для работы с данными длиной более 1 этим инструкциям требуется префикс. Инструкция movsb перемещает только один байт и не использует регистр ECX.

В x86 для многобайтовых операций применяются префиксы повторения. Инструкция rep увеличивает смещения ESI и EDI и уменьшает регистр ECX. Префикс rep продолжает повторение, пока ECX не станет равен 0. Префиксы repe/repz и repne/repnz продолжают повторение, пока ECX не станет равен 0 либо пока ZF не станет равен соответственно 1 или 0. Это показано в таблице 4-10. Поэтому, чтобы инструкция rep была полезна, перед большинством инструкций работы с буферами данных необходимо правильно инициализировать ESI, EDI и ECX.

Таблица 4-10. Условия завершения инструкции rep

Инструкция movsb используется для перемещения последовательности байтов из одного места в другое. Префикс rep обычно применяется вместе с movsb для копирования последовательности байтов, размер которой задаётся в ECX. Инструкция rep movsb логически равнозначна функции C memcpy. Инструкция movsb получает байт по адресу ESI, сохраняет его по адресу EDI, а затем увеличивает или уменьшает регистры ESI и EDI на единицу в соответствии со значением флага направления (DF). Если DF = 0, они увеличиваются; в противном случае они уменьшаются.

В скомпилированном коде C такое встречается редко, однако в шелл-коде иногда переключают флаг направления, чтобы сохранять данные в обратном направлении. Если присутствует префикс rep, проверяется, содержит ли ECX ноль. Если нет, инструкция перемещает байт из ESI в EDI и уменьшает регистр ECX. Этот процесс повторяется, пока ECX не станет равен 0.

Инструкция cmpsb используется для сравнения двух последовательностей байтов с целью определить, содержат ли они одинаковые данные. cmpsb вычитает значение по адресу EDI из значения по адресу ESI и обновляет флаги. Обычно она применяется с префиксом repe. Вместе с префиксом repe инструкция cmpsb сравнивает каждый байт двух последовательностей, пока не найдёт различие между ними или не достигнет конца сравнения. Инструкция cmpsb получает байт по адресу ESI, сравнивает с ним значение по адресу EDI для установки флагов, а затем увеличивает регистры ESI и EDI на единицу. Если присутствует префикс repe, проверяется ECX, а также флаги; если ECX = 0 или ZF = 0, повторение операции прекращается. Это равнозначно функции C memcmp.

Инструкция scasb используется для поиска одного значения в последовательности байтов. Значение задаётся регистром AL. Она действует так же, как cmpsb, но сравнивает с AL байт по адресу ESI, а не байт по адресу EDI. Операция repe продолжается, пока байт не будет найден или ECX не станет равен 0. Если значение найдено в последовательности байтов, ESI хранит расположение этого значения.

Инструкция stosb используется для сохранения значений в расположении, указанном EDI. Она идентична scasb, однако указанный байт не ищется, а помещается в расположение, заданное EDI. Префикс rep используется с scasb для инициализации буфера памяти, каждый байт которого содержит одно и то же значение. Это равнозначно функции C memset. В таблице 4-11 показаны некоторые распространённые инструкции rep и описана их работа.

Таблица 4-11. Примеры инструкций rep

Метод main языка C и смещения

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

Стандартная программа C имеет два аргумента метода main, обычно в следующем виде:

Параметры argc и argv определяются во время выполнения. Параметр argc - целое число, содержащее количество аргументов командной строки, включая имя программы. Параметр argv - указатель на массив строк, содержащих аргументы командной строки. В следующем примере показана программа командной строки и значения argc и argv при её запуске.

В листинге 4-1 приведён код простой программы на C.

Листинг 4-1. Код C, пример метода main

В листинге 4-2 показан код C из листинга 4-1 в скомпилированном виде. Этот пример поможет понять, как в ассемблерном коде осуществляется доступ к параметрам, перечисленным в таблице 4-12. argc сравнивается с 3 в точке ❶, а argv[1] сравнивается с -r в точке ❷ с помощью strncmp. Обратите внимание, как осуществляется доступ к argv[1]: сначала в eax загружается расположение начала массива, а затем к eax прибавляется 4 (смещение), чтобы получить argv[1]. Число 4 используется потому, что каждый элемент массива argv является адресом строки, а размер каждого адреса в 32-разрядной системе составляет 4 байта. Если в командной строке указан параметр -r, будет выполнен код, начинающийся в точке ❸, где мы видим обращение к argv[2] со смещением 8 относительно argv и передачу его в качестве аргумента функции DeleteFileA.

Листинг 4-2. Ассемблерный код, параметры метода main языка C

Дополнительные сведения: руководства по архитектуре Intel x86

Что делать, если встретилась незнакомая инструкция? Если найти ответ с помощью поиска Google не удалось, полный комплект руководств по архитектуре x86 можно загрузить с сайта Intel по адресу intel.com. В комплект входят следующие документы:

Том 1: Basic Architecture

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

Том 2A: Instruction Set Reference, A-M, и том 2B: Instruction Set Reference, N-Z

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

Том 3A: System Programming Guide, Part 1, и том 3B: System Programming Guide, Part 2

Помимо регистров общего назначения, в x86 имеется множество регистров и инструкций специального назначения, влияющих на выполнение и поддерживающих работу операционной системы, в том числе отладку, управление памятью, защиту, управление задачами, обработку прерываний и исключений, поддержку многопроцессорности и многое другое. Если встретятся регистры специального назначения, обратитесь к System Programming Guide, чтобы узнать, как они влияют на выполнение.

Optimization Reference Manual

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

Заключение

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

Глава 6 развивает материал этой главы и даёт всестороннюю основу знаний ассемблера. Однако единственный реальный способ научиться хорошо разбираться в дизассемблировании - практиковаться. В следующей главе мы познакомимся с IDA Pro, инструментом, который значительно облегчит анализ дизассемблированного кода.

Здесь мы кратко познакомимся с двумя наиболее популярными способами написания сценариев: IDC и Python. Сценарии IDC и Python можно легко запускать как файлы командой File > Script File или как отдельные команды, выбрав File > IDC Command либо File > Python Command, как показано на рисунке 5-12. Окно вывода в нижней части рабочей области содержит журнал, широко используемый подключаемыми модулями для сообщений отладки и состояния.

Рисунок 5-12. Варианты загрузки сценариев IDC и Python

Таблица 5-4. Ручное дизассемблирование шелл-кода в документе paycuts.pdf

Использование сценариев IDC

IDA Pro уже давно имеет встроенный язык сценариев IDC, появившийся до широкого распространения таких языков сценариев, как Python и Ruby. Подкаталог IDC в каталоге установки IDA содержит несколько примеров сценариев IDC, которые IDA Pro использует для анализа дизассемблированных текстов. Обратитесь к этим программам, если хотите изучить IDC.

Сценарии IDC представляют собой программы из функций, причём все функции объявляются как static. Тип аргументов указывать не требуется, а для определения локальных переменных используется auto. В IDC имеется множество встроенных функций, описанных в справочном указателе IDA Pro или в файле idc.idc, который обычно прилагается к сценариям, использующим встроенные функции.

В главе 1 мы обсуждали инструмент PEiD и его подключаемый модуль Krypto ANALyzer (KANAL), способный экспортировать сценарий IDC. Такой сценарий устанавливает закладки и комментарии в базе данных IDA Pro для заданного двоичного файла, как показано в листинге 5-5.

Листинг 5-5. Сценарий IDC, созданный подключаемым модулем PEiD KANAL

Чтобы загрузить сценарий IDC, выберите File > Script File. Сценарий IDC должен выполниться немедленно, после чего откроется окно панели инструментов с одной кнопкой для редактирования и другой для повторного выполнения сценария при необходимости.

Использование IDAPython

IDAPython полностью интегрирован в текущую версию IDA Pro и привносит в анализ двоичных файлов мощь и удобство сценариев Python. IDAPython открывает доступ к значительной части функциональности SDK IDA Pro, позволяя создавать гораздо более мощные сценарии, чем IDC. В IDAPython имеются три модуля, предоставляющие доступ к API IDA (idaapi), интерфейсу IDC (idc) и вспомогательным функциям IDAPython (idautils).

Сценарии IDAPython представляют собой программы, в которых основным способом ссылки служит эффективный адрес (EA). Абстрактных типов данных нет, а большинство вызовов принимает либо EA, либо строку с именем символа. IDAPython содержит множество функций-обёрток для основных функций IDC.

В листинге 5-6 показан пример сценария IDAPython. Его цель - выделить цветом все инструкции call в idb, чтобы аналитик легче их замечал. Например, ScreenEA - распространённая функция, получающая расположение курсора. Функция Heads используется для обхода определённых элементов, в данном случае каждой инструкции. Собрав все вызовы функций в functionCalls, мы перебираем эти инструкции и с помощью SetColor задаём цвет.

Листинг 5-6. Полезный сценарий Python для выделения цветом всех вызовов функций

Использование коммерческих подключаемых модулей

Получив основательный опыт работы с IDA Pro, стоит подумать о приобретении нескольких коммерческих подключаемых модулей, например Hex-Rays Decompiler и zynamics BinDiff. Hex-Rays Decompiler - полезный подключаемый модуль, преобразующий дизассемблированный код IDA Pro в удобочитаемый псевдокод, похожий на C. Чтение кода, похожего на C, вместо дизассемблированного представления часто ускоряет анализ, поскольку приближает к исходному коду, написанному автором вредоносной программы.

zynamics BinDiff - полезный инструмент для сравнения двух баз данных IDA Pro. Он позволяет точно выявлять различия между вариантами вредоносной программы, включая новые функции и различия между похожими функциями. Одна из его возможностей - оценка сходства при сравнении двух образцов вредоносной программы. Эти расширения IDA Pro подробнее описаны в приложении B.

Заключение

Эта глава дала лишь беглое знакомство с IDA Pro. На протяжении книги мы будем использовать IDA Pro в лабораторных работах, демонстрируя интересные способы применения программы.

Как вы увидели, просмотр дизассемблированного кода - лишь малая часть возможностей IDA Pro. Настоящая сила IDA Pro заключается в интерактивности; мы обсудили способы разметки дизассемблированного представления, помогающие проводить анализ. Мы также рассмотрели способы просмотра ассемблерного кода в IDA Pro, включая навигацию, использование всей мощи перекрёстных ссылок и просмотр графов, каждый из которых ускоряет анализ.

Лабораторные работы Лабораторная работа 5-1

Проанализируйте вредоносную программу из файла Lab05-01.dll, используя только IDA Pro. Цель этой лабораторной работы - дать вам практический опыт работы с IDA Pro. Если вы уже работали с IDA Pro, можете не отвечать на эти вопросы и сосредоточиться на обратной разработке вредоносной программы.

Вопросы

1. Каков адрес DllMain?

2. Используйте окно Imports, чтобы перейти к gethostbyname. Где расположен импорт?

3. Сколько функций вызывают gethostbyname?

4. Сосредоточившись на вызове gethostbyname по адресу 0x10001757, можете ли вы выяснить, какой DNS-запрос будет сделан?

5. Сколько локальных переменных IDA Pro распознала для подпрограммы по адресу 0x10001656?

6. Сколько параметров IDA Pro распознала для подпрограммы по адресу 0x10001656?

7. С помощью окна Strings найдите в дизассемблированном коде строку \cmd.exe /c. Где она находится?

8. Что происходит в области кода, которая ссылается на \cmd.exe /c?

9. В той же области, по адресу 0x100101C8, dword_1008E5C4 выглядит как глобальная переменная, помогающая выбрать путь выполнения. Как вредоносная программа устанавливает dword_1008E5C4? (Подсказка: используйте перекрёстные ссылки dword_1008E5C4.)

10. Через несколько сотен строк после начала подпрограммы по адресу 0x1000FF58 последовательность сравнений использует memcmp для сравнения строк. Что происходит, если сравнение со строкой robotwork успешно (когда memcmp возвращает 0)?

11. Что делает экспортируемая функция PSLIST?

12. В графическом режиме постройте граф перекрёстных ссылок от sub_10004E79. Какие функции API могут быть вызваны при входе в эту функцию? Как можно переименовать эту функцию, судя только по функциям API?

13. Сколько функций Windows API DllMain вызывает непосредственно? А сколько на глубине 2?

14. По адресу 0x10001358 находится вызов Sleep (функции API, принимающей один параметр с числом миллисекунд приостановки). Просматривая код в обратном направлении, определите, как долго программа будет спать, если этот код выполнится.

15. По адресу 0x10001701 находится вызов socket. Каковы три его параметра?

16. Используя страницу MSDN для socket и функцию именованных символьных констант IDA Pro, можете ли вы сделать параметры более содержательными? Как выглядят параметры после внесения изменений?

17. Найдите использование инструкции in (код операции 0xED). Эта инструкция используется вместе с магической строкой VMXh для обнаружения VMware. Применяется ли она в этой вредоносной программе? Есть ли дополнительные признаки обнаружения VMware, если исследовать перекрёстные ссылки на функцию, выполняющую инструкцию in?

18. Переместите курсор к адресу 0x1001D988. Что вы обнаружите?

19. Если у вас установлен подключаемый модуль IDAPython (он входит в коммерческую версию IDA Pro), запустите Lab05-01.py, сценарий Python для IDA Pro, поставляемый вместе с вредоносной программой к этой книге. (Убедитесь, что курсор находится по адресу 0x1001D988.) Что произойдёт после запуска сценария?

20. Как, оставив курсор в том же месте, преобразовать эти данные в одну строку ASCII?

21. Откройте сценарий в текстовом редакторе. Как он работает?

В листинге 6-24 показаны два используемых одной программой массива, значения которых задаются при прохождении цикла for. Массив a определён локально, а массив b - глобально. Эти определения повлияют на ассемблерный код.

Листинг 6-24. Код C с массивом

В ассемблерном коде доступ к массиву выполняется с начальной точки, называемой базовым адресом. Размер каждого элемента не всегда очевиден, но его можно определить по способу индексирования массива. В листинге 6-25 показан ассемблерный код листинга 6-24.

Листинг 6-25. Ассемблерный код массива из листинга 6-24

В этом листинге базовому адресу массива b соответствует dword_40A000, а базовому адресу массива a - var_14. Поскольку оба массива состоят из целых чисел, размер каждого элемента равен 4, хотя инструкции обращения к массивам в точках ❶ и ❷ различаются. В обоих случаях в качестве индекса используется ecx, который умножается на 4 с учётом размера элементов. Полученное значение прибавляется к базовому адресу массива для обращения к нужному элементу.

Распознавание структур

Структуры (сокращённо structs) похожи на массивы, но состоят из элементов разных типов. Авторы вредоносных программ часто используют структуры для группировки информации. Иногда структура удобнее независимого сопровождения множества разных переменных, особенно если доступ к одной группе переменных требуется многим функциям. (Функции Windows API часто используют структуры, которые должна создавать и сопровождать вызывающая программа.)

В листинге 6-26 в точке ❶ определяется структура, состоящая из массива целых чисел, символа и значения double. В main мы выделяем память для структуры и передаём её функции test. Структура gms, определённая в точке ❷, является глобальной переменной.

Листинг 6-26. Код C с примером структуры

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

В листинге 6-27 показана дизассемблированная функция main из листинга 6-26. Поскольку структура gms является глобальной переменной, её базовым адресом будет область памяти dword_40EA30, как показано в листинге 6-27. Базовый адрес этой структуры передаётся функции sub_401000 (test) посредством инструкции push eax в точке ❶.

Листинг 6-27. Ассемблерный код функции main из примера структуры в листинге 6-26

В листинге 6-28 показано дизассемблированное представление метода test из листинга 6-26. arg_0 является базовым адресом структуры. По смещению 0x14 хранится символ структуры, а 0x61 соответствует букве a в ASCII.

Листинг 6-28. Ассемблерный код функции test из примера структуры в листинге 6-26

Мы можем определить, что по смещению 0x18 находится значение double, поскольку оно используется в инструкции с плавающей точкой в точке ❶. Исследуя цикл for и обращения к смещениям в точке ❷, можно также определить, что целые числа перемещаются по смещениям 0, 4, 8, 0xC и 0x10. На основании этого анализа можно сделать вывод о содержимом структуры.

В IDA Pro можно создавать структуры и назначать их ссылкам на память с помощью горячей клавиши T. В результате инструкция mov [eax+14h], 61h превратится в mov [eax + my_structure.y], 61h. Второй вариант легче читать, а разметка структур часто помогает быстрее понять дизассемблированный код, особенно если используемую структуру приходится просматривать постоянно. Для эффективного использования клавиши T в этом примере нужно вручную создать структуру my_structure в окне структур IDA Pro. Это может быть утомительно, но полезно для часто встречающихся структур.

Анализ обхода связанного списка

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

В листинге 6-29 показан пример связанного списка и его обхода на C. Этот связанный список состоит из последовательности структур узлов с именем pnode и обрабатывается двумя циклами. Первый цикл в точке ❶ создаёт 10 узлов и заполняет их данными. Второй цикл в точке ❷ перебирает все записи и выводит их содержимое.

Листинг 6-29. Код C с обходом связанного списка

Лучший способ понять дизассемблированный код - распознать две конструкции кода внутри метода main. В этом и состоит суть главы: способность распознавать такие конструкции упрощает анализ.

В листинге 6-30 сначала распознаётся цикл for. var_C соответствует i, счётчику цикла. var_8 соответствует переменной head, а var_4 - переменной curr. var_4 является указателем на структуру с двумя переменными, которым присваиваются значения (в точках ❶ и ❷).

Цикл while (от ❸ до ❺) выполняет обход связанного списка. Внутри цикла в точке ❹ var_4 устанавливается равной следующей записи списка.

Листинг 6-30. Ассемблерный код примера обхода связанного списка из листинга 6-29

Чтобы распознать связанный список, прежде всего необходимо понять, что некоторый объект содержит указатель на другой объект того же типа. Именно рекурсивная природа объектов делает их связанными, и именно её требуется распознать в дизассемблированном коде.

В этом примере в точке ❹ переменной var_4 присваивается eax, полученный из [eax+4], а сам eax до этого был получен из предыдущего присваивания var_4. Это означает, что структура, на которую указывает var_4, должна содержать указатель со смещением 4 байта. Он указывает на другую структуру, которая также должна содержать по смещению 4 байта указатель на следующую структуру, и так далее.

Заключение

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

Мы показали каждую из основных конструкций C как в коде C, так и в ассемблере, чтобы вы могли быстро распознавать наиболее распространённые конструкции при анализе. Мы также привели несколько примеров, где компилятор решил действовать иначе: в случае структур и, когда использовался совершенно другой компилятор, в случае вызовов функций. Развитие этого понимания поможет вам научиться распознавать новые конструкции, когда они встретятся в реальных условиях.

Лабораторные работы

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

Лабораторная работа 6-1

В этой лабораторной работе вы проанализируете вредоносную программу из файла Lab06-01.exe.

Вопросы

1. Какая основная конструкция кода находится в единственной подпрограмме, вызываемой функцией main?

2. Что представляет собой подпрограмма по адресу 0x40105F?

3. Каково назначение этой программы?

Лабораторная работа 6-2

Проанализируйте вредоносную программу из файла Lab06-02.exe.

Вопросы

1. Какую операцию выполняет первая подпрограмма, вызываемая main?

2. Что представляет собой подпрограмма по адресу 0x40117F?

3. Что делает вторая подпрограмма, вызываемая main?

4. Какой вид конструкции кода используется в этой подпрограмме?

5. Имеются ли сетевые индикаторы для этой программы?

6. Каково назначение этой вредоносной программы?

Лабораторная работа 6-3

В этой лабораторной работе мы проанализируем вредоносную программу из файла Lab06-03.exe.

Вопросы

1. Сравните вызовы в main с методом main лабораторной работы 6-2. Какая новая функция вызывается из main?

2. Какие параметры принимает эта новая функция?

3. Какую основную конструкцию кода содержит эта функция?

4. Что может делать эта функция?

5. Имеются ли индикаторы этой вредоносной программы на узле?

6. Каково назначение этой вредоносной программы?

Лабораторная работа 6-4

В этой лабораторной работе мы проанализируем вредоносную программу из файла Lab06-04.exe.

Вопросы

1. Чем вызовы из метода main лабораторной работы 6-4 отличаются от вызовов в лабораторной работе 6-3?

2. Какая новая конструкция кода добавлена в main?

3. Чем функция разбора HTML в этой лабораторной работе отличается от функций в предыдущих работах?

4. Как долго будет работать эта программа? (Предположите, что она подключена к Интернету.)

5. Имеются ли новые сетевые индикаторы этой вредоносной программы?

6. Каково назначение этой вредоносной программы?

В листинге 7-6 показано, как распознать второй приём по двум расположенным рядом вызовам CreateThread. (Показаны только системные вызовы для ThreadFunction1 и ThreadFunction2.) Этот код дважды вызывает CreateThread. Аргументы lpStartAddress сообщают, где искать код, который будет выполняться после запуска потоков.

Листинг 7-6. Основная функция примера с потоками

В листинге 7-6 стартовая функция первого вызова CreateThread ❷ помечена как ThreadFunction1 ❶, а для второго вызова ❹ - как ThreadFunction2 ❸. Чтобы определить назначение этих двух потоков, сначала перейдём к ThreadFunction1. Как показано в листинге 7-7, первая функция потока выполняет цикл, где вызывает ReadFile для чтения из канала, а затем пересылает данные в сокет функцией send.

Листинг 7-7. ThreadFunction1 из примера с потоками

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

Листинг 7-8. ThreadFunction2 из примера с потоками

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

Координация процессов с помощью мьютексов

Связанная с потоками и процессами тема - мьютексы, которые в ядре называются мутантами. Мьютексы являются глобальными объектами, координирующими несколько процессов и потоков.

Мьютексы главным образом используются для управления доступом к общим ресурсам и часто применяются вредоносными программами. Например, если два потока должны обращаться к структуре памяти, но безопасно делать это одновременно может лишь один, доступ можно регулировать мьютексом.

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

Поток получает доступ к мьютексу вызовом WaitForSingleObject, а все последующие потоки, пытающиеся получить доступ, должны ждать. Завершив работу с мьютексом, поток вызывает ReleaseMutex.

Мьютекс можно создать функцией CreateMutex. Один процесс может получить дескриптор мьютекса другого процесса с помощью вызова OpenMutex. Вредоносная программа часто создаёт мьютекс и пытается открыть существующий мьютекс с тем же именем, чтобы в каждый момент работал только один её экземпляр, как показано в листинге 7-9.

Листинг 7-9. Использование мьютекса, обеспечивающего работу только одной копии вредоносной программы

Код листинга 7-9 использует для мьютекса жёстко заданное имя HGL345. Сначала вызов OpenMutex в точке ❶ проверяет существование мьютекса с именем HGL345. Если возвращённое значение в точке ❷ равно NULL, переход в точке ❸ перепрыгивает через вызов exit, и выполнение продолжается. Если значение не равно NULL, в точке ❹ вызывается exit и процесс завершается. Если выполнение продолжается, в точке ❺ создаётся мьютекс, благодаря которому дополнительные экземпляры программы завершатся при достижении этого кода.

Службы

Ещё один способ выполнения вредоносной программой дополнительного кода - установка его как службы. Windows позволяет задачам работать без собственных процессов или потоков посредством фоновых приложений-служб; диспетчер служб Windows планирует и запускает код без участия пользователя. В любой момент в Windows работает несколько служб.

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

Службы также предоставляют ещё один способ закрепления в системе, поскольку их можно настроить на автоматический запуск вместе с операционной системой, а в диспетчере задач они могут даже не отображаться как процесс. Пользователь, просматривающий работающие приложения, не обнаружит ничего подозрительного, потому что вредоносная программа не работает как отдельный процесс.

Примечание. Работающие службы можно перечислить командой net start, однако она покажет только их имена. Дополнительные сведения о работающих службах можно собрать такими программами, как упомянутый ранее Autoruns.

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

• OpenSCManager. Возвращает дескриптор диспетчера управления службами, используемый всеми последующими функциями, связанными со службами. Любой код, взаимодействующий со службами, вызывает эту функцию.

• CreateService. Добавляет новую службу в диспетчер управления службами и позволяет указать, должна ли она автоматически запускаться при загрузке или запускаться вручную.

• StartService. Запускает службу и используется только для служб с ручным запуском.

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

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

Последний распространённый тип службы - KERNEL_DRIVER, используемый для загрузки кода в ядро. (Работа вредоносных программ в ядре рассматривается далее в этой главе и подробно в главе 10.)

Сведения о службах локальной системы хранятся в реестре. Каждая служба имеет подраздел в HKLM\SYSTEM\CurrentControlSet\Services. Например, на рисунке 7-2 показаны записи реестра для HKLM\SYSTEM\CurrentControlSet\Services\VMware NAT Service.

Рисунок 7-2. Запись реестра службы VMware NAT

Код службы VMware NAT хранится в C:\Windows\system32\vmnat.exe ❶. Значение типа 0x10 ❸ соответствует WIN32_OWN_PROCESS, а значение запуска 0x02 ❷ - AUTO_START.

Программа SC - входящий в Windows инструмент командной строки для исследования служб и управления ими. Она поддерживает команды добавления, удаления, запуска, остановки и запроса служб. Например, команда qc запрашивает параметры конфигурации службы, обращаясь к тем же сведениям, что и запись реестра на рисунке 7-2, но представляет их в более удобочитаемом виде. Работа программы SC показана в листинге 7-10.

Листинг 7-10. Команда запроса конфигурационных сведений программы SC

В листинге 7-10 показана команда запроса конфигурационных сведений. Эти данные идентичны хранящимся в реестре сведениям о службе VMware NAT, но их проще читать, поскольку числовые значения имеют содержательные метки, например WIN32_OWN_PROCESS ❶. У программы SC много разных команд; запуск SC без параметров выводит список доступных команд. (Подробнее о вредоносных программах, работающих как службы, см. в главе 11.)

Модель компонентных объектов

Microsoft Component Object Model (COM) - стандарт интерфейса, позволяющий разным программным компонентам вызывать код друг друга, не зная внутренних особенностей друг друга. При анализе вредоносной программы, использующей COM, необходимо уметь определять, какой код будет выполнен в результате вызова функции COM.

COM работает с любым языком программирования и была создана для поддержки повторно используемых программных компонентов, доступных всем программам. COM использует конструкцию объектов, хорошо подходящую объектно-ориентированным языкам программирования, но не ограничивается такими языками.

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

COM реализована как клиент-серверная архитектура. Клиенты - программы, использующие объекты COM, а серверы - повторно используемые программные компоненты, то есть сами объекты COM. Microsoft предоставляет программам большое число объектов COM.

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

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

CLSID, IID и использование объектов COM

Доступ к объектам COM осуществляется через их глобально уникальные идентификаторы (GUID), называемые идентификаторами классов (CLSID) и интерфейсов (IID).

Для получения доступа к функциям COM используется CoCreateInstance. Одна из распространённых функций, применяемых вредоносными программами, - Navigate, которая позволяет запустить Internet Explorer и обратиться к веб-адресу. Navigate входит в интерфейс IWebBrowser2, определяющий список функций, которые должны быть реализованы, но не указывающий программу, предоставляющую эту функциональность. Предоставляющая её программа является классом COM, реализующим интерфейс IWebBrowser2. В большинстве случаев этот интерфейс реализует Internet Explorer. Интерфейсы обозначаются GUID, называемым IID, а классы - GUID, называемым CLSID.

Рассмотрим пример вредоносной программы, использующей функцию Navigate интерфейса IWebBrowser2, реализованного Internet Explorer. Сначала вредоносная программа вызывает CoCreateInstance. Функция принимает CLSID и IID запрашиваемого объекта. Затем операционная система ищет сведения о классе и загружает программу, которая будет предоставлять функциональность, если та ещё не запущена. Класс CoCreateInstance возвращает указатель на структуру с указателями функций. Для использования функций сервера COM вредоносная программа вызывает функцию, указатель которой хранится в структуре, возвращённой CoCreateInstance. В листинге 7-11 показано, как код получает доступ к объекту IWebBrowser2.

Листинг 7-11. Обращение к объекту COM с помощью CoCreateInstance

Чтобы понять код, щёлкните структуры с IID и CLSID в точках ❶ и ❷. В коде указан IID D30C1661-CDAF-11D0-8A3E-00C04FC9E26E, представляющий интерфейс IWebBrowser2, и CLSID 0002DF01-0000-0000-C000-000000000046, представляющий Internet Explorer. IDA Pro может распознать и пометить IID IWebBrowser2, поскольку он широко используется. Разработчики могут создавать собственные IID, поэтому IDA Pro не всегда способна пометить используемый программой IID и никогда не может пометить CLSID, поскольку дизассемблированный код не содержит необходимых сведений.

Когда программа вызывает CoCreateInstance, операционная система по сведениям реестра определяет файл, содержащий запрошенный код COM. Разделы HKLM\SOFTWARE\Classes\CLSID\ и HKCU\SOFTWARE\Classes\CLSID хранят сведения о коде, который должен выполняться для сервера COM. Значение C:\Program Files\Internet Explorer\iexplore.exe в подразделе LocalServer32 раздела HKLM\SOFTWARE\Classes\CLSID\0002DF01-0000-0000-C000-000000000046 определяет исполняемый файл, который будет загружен при вызове CoCreateInstance.

После возврата структуры вызовом CoCreateInstance клиент COM вызывает функцию, адрес которой хранится по смещению в структуре. Вызов показан в листинге 7-12. Ссылка на объект COM хранится в стеке, а затем перемещается в EAX. Первое значение структуры указывает на таблицу указателей функций. По смещению 0x2C в таблице находится вызываемая функция Navigate.

Листинг 7-12. Вызов функции COM

Чтобы определить действия вредоносной программы при вызове функции COM, аналитик должен выяснить, по какому смещению хранится функция, а это может быть непросто. IDA Pro хранит смещения и структуры распространённых интерфейсов, доступные в окне структур. Нажмите INSERT, чтобы добавить структуру, затем выберите Add Standard Structure. Имя добавляемой структуры имеет вид InterfaceNameVtbl. В нашем примере с Navigate добавляется структура IWebBrowser2Vtbl. После добавления структуры щёлкните правой кнопкой мыши смещение в точке ❶ дизассемблированного кода, чтобы заменить метку 2Ch именем функции IwebBrowser2Vtbl.Navigate. Теперь IDA Pro добавит комментарии к инструкции вызова и параметрам, помещаемым в стек.

Для функций, отсутствующих в IDA Pro, одна из стратегий определения вызываемой клиентом COM функции - проверить заголовочные файлы интерфейса, указанного в вызове CoCreateInstance. Заголовочные файлы входят в Microsoft Visual Studio и Platform SDK, а также доступны в Интернете. Обычно функции объявлены в заголовочном файле в том же порядке, что и в таблице функций. Например, Navigate является двенадцатой функцией в файле .h, что соответствует смещению 0x2C. Первая функция находится по смещению 0, и каждая занимает 4 байта.

В предыдущем примере при вызове CoCreateInstance Internet Explorer загружался как отдельный процесс, но так происходит не всегда. Некоторые объекты COM реализованы как DLL, загружаемые в пространство процесса исполняемого файла клиента COM. Если объект COM настроен для загрузки как DLL, запись CLSID в реестре содержит подраздел InprocServer32, а не LocalServer32.

Вредоносная программа как сервер COM

Некоторые вредоносные программы реализуют вредоносный сервер COM, который затем используется другими приложениями. Распространённый способ реализации функций сервера COM вредоносной программой - Browser Helper Objects (BHO), сторонние подключаемые модули Internet Explorer. На BHO не накладывается ограничений, поэтому авторы вредоносных программ используют их для выполнения кода внутри процесса Internet Explorer. Это позволяет отслеживать интернет-трафик, следить за использованием браузера и взаимодействовать с Интернетом без собственного процесса.

Вредоносную программу, реализующую сервер COM, обычно легко обнаружить, поскольку она экспортирует несколько функций: DllCanUnloadNow, DllGetClassObject, DllInstall, DllRegisterServer и DllUnregisterServer, обязательных для всех серверов COM.

Исключения: когда что-то идёт не так

Исключения позволяют программе обрабатывать события за пределами обычного потока выполнения. Чаще всего они вызваны ошибками, например делением на ноль. При исключении выполнение передаётся специальной процедуре, разрешающей исключение. Некоторые исключения, например деление на ноль, возбуждаются оборудованием; другие, например недопустимое обращение к памяти, - операционной системой. Исключение также можно явно возбудить в коде вызовом RaiseException.

Structured Exception Handling (SEH) - механизм Windows для обработки исключений. В 32-разрядных системах сведения SEH хранятся в стеке. В листинге 7-13 показаны первые несколько строк дизассемблированной функции с обработкой исключений.

Листинг 7-13. Хранение сведений обработки исключений в fs:0

В начале функции кадр обработки исключений помещается в стек в точке ❶. Специальное расположение fs:0 указывает на адрес в стеке, хранящий сведения об исключении. В стеке находится адрес обработчика исключения, а также обработчик, использованный вызывающей функцией в точке ❷; он восстанавливается в конце функции. При исключении Windows ищет в fs:0 расположение стека со сведениями об исключении, после чего вызывает обработчик. После обработки исключения выполнение возвращается в основной поток.

Обработчики исключений вложены, и не каждый обработчик реагирует на все исключения. Если обработчик текущего кадра не обрабатывает исключение, оно передаётся обработчику кадра вызывающей функции. В конце концов, если ни один обработчик не отреагирует, обработчик верхнего уровня аварийно завершает приложение.

Обработчики исключений могут использоваться в коде эксплойта для получения управления. Указатель на сведения обработки исключений хранится в стеке, и при переполнении стека злоумышленник может его перезаписать. Указав новый обработчик, злоумышленник получает управление при возникновении исключения. Исключения подробнее рассматриваются в главах об отладке и противодействии отладке (главы 8-10, 15 и 16).

Режим ядра и пользовательский режим

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

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

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

Когда вызывается функция Windows API, изменяющая структуры ядра, она выполняет вызов в ядро. Наличие в дизассемблированном коде инструкции SYSENTER, SYSCALL или INT 0x2E указывает на вызов ядра. Поскольку напрямую перейти из пользовательского режима в ядро невозможно, эти инструкции используют таблицы поиска для нахождения заранее определённой функции, выполняемой в ядре.

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

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

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

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

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

Native API

Native API - низкоуровневый интерфейс взаимодействия с Windows, редко используемый обычными программами, но популярный среди авторов вредоносных программ. Вызов функций Native API позволяет обойти обычный Windows API.

При вызове функции Windows API она обычно не выполняет запрошенное действие непосредственно, поскольку большинство важных структур данных хранится в ядре, недоступном коду вне ядра, то есть коду пользовательского режима. Microsoft создала многоэтапный процесс, посредством которого пользовательские приложения получают необходимую функциональность. На рисунке 7-3 показано, как он работает для большинства вызовов API.

Рисунок 7-3. Пользовательский режим и режим ядра

Пользовательским приложениям предоставляется доступ к пользовательским API, например kernel32.dll и другим DLL, которые вызывают ntdll.dll, особую DLL, управляющую взаимодействием между пользовательским пространством и ядром. Затем процессор переключается в режим ядра и выполняет функцию ядра, обычно расположенную в ntoskrnl.exe. Процесс сложен, но разделение API ядра и пользователя позволяет Microsoft изменять ядро, не затрагивая существующие приложения.

Функции ntdll используют API и структуры, подобные применяемым в ядре. Эти функции и образуют Native API. Программы не должны вызывать Native API, но операционная система этому не препятствует. Хотя Microsoft не предоставляет подробной документации Native API, существуют сайты и книги, описывающие эти функции. Лучший справочник - Windows NT/2000 Native API Reference Гэри Неббетта (Sams, 2000), хотя он довольно стар. Более свежие сведения доступны в интернет-источниках, например undocumented.ntinternals.net.

Прямой вызов Native API привлекателен для авторов вредоносных программ, поскольку позволяет делать то, что иначе могло бы оказаться невозможным. Множество функций не представлено в обычном Windows API, но доступно через прямые вызовы Native API.

Кроме того, прямой вызов Native API иногда менее заметен. Многие антивирусы и средства защиты узла отслеживают системные вызовы процесса. Если процесс вызывает функцию Native API напрямую, он может обойти плохо спроектированное средство защиты.

На рисунке 7-4 показан системный вызов с плохо спроектированной защитной программой, отслеживающей вызовы kernel32.dll. Для обхода защиты гипотетическая вредоносная программа использует Native API. Вместо функций Windows ReadFile и WriteFile она вызывает NtReadFile и NtWriteFile. Эти функции находятся в ntdll.dll и не отслеживаются защитной программой. Хорошо спроектированное средство защиты контролирует вызовы на всех уровнях, включая ядро, чтобы этот приём не работал.

Рисунок 7-4. Использование Native API для обхода обнаружения

Существует ряд вызовов Native API для получения сведений о системе, процессах, потоках, дескрипторах и других элементах. К ним относятся NtQuerySystemInformation, NtQueryInformationProcess, NtQueryInformationThread, NtQueryInformationFile и NtQueryInformationKey. Эти вызовы предоставляют намного более подробные сведения, чем любые доступные вызовы Win32, а некоторые функции позволяют задавать детальные атрибуты файлов, процессов, потоков и так далее.

Ещё одна популярная среди авторов вредоносных программ функция Native API - NtContinue. Она используется для возврата из исключения и предназначена для передачи выполнения обратно в основной поток программы после обработки исключения. Однако расположение возврата задаётся в контексте исключения и может быть изменено. Вредоносные программы часто используют эту функцию для сложной передачи выполнения, чтобы запутать аналитика и усложнить отладку программы.

Примечание. Мы рассмотрели несколько функций с префиксом Nt. В некоторых местах, например в таблицах экспорта ntdll.dll, одна функция может иметь префикс Nt или Zw. Например, существуют функции NtReadFile и ZwReadFile. В пользовательском пространстве они действуют совершенно одинаково и обычно вызывают один и тот же код. При вызове из режима ядра иногда имеются небольшие различия, но аналитик вредоносных программ может смело их игнорировать.

Нативные приложения не используют подсистему Win32 и выполняют только вызовы Native API. Такие приложения редко встречаются среди вредоносных программ и почти не встречаются среди обычного программного обеспечения, поэтому нативное приложение, скорее всего, является вредоносным. Поле подсистемы в заголовке PE указывает, является ли программа нативным приложением.

Заключение

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

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

Лабораторные работы Лабораторная работа 7-1

Проанализируйте вредоносную программу из файла Lab07-01.exe.

Вопросы

1. Как программа обеспечивает продолжение своей работы (закрепление) после перезагрузки компьютера?

2. Почему программа использует мьютекс?

3. Какая сигнатура на узле подходит для обнаружения этой программы?

4. Какая сетевая сигнатура подходит для обнаружения этой вредоносной программы?

5. Каково назначение программы?

6. Когда программа завершит выполнение?

Лабораторная работа 7-2

Проанализируйте вредоносную программу из файла Lab07-02.exe.

Вопросы

1. Как программа закрепляется в системе?

2. Каково назначение программы?

3. Когда программа завершит выполнение?

Лабораторная работа 7-3

Для этой лабораторной работы мы получили вредоносный исполняемый файл Lab07-03.exe и DLL Lab07-03.dll до их выполнения. Это важно отметить, поскольку после запуска вредоносная программа может измениться. Оба файла были найдены в одном каталоге машины жертвы. При запуске программы убедитесь, что оба файла находятся в одном каталоге машины анализа. Видимая строка IP, начинающаяся с 127 (адрес обратной петли), подключается к локальной машине. (В настоящей версии вредоносной программы этот адрес подключается к удалённой машине, но для вашей защиты мы настроили подключение к localhost.)

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

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

Вопросы

1. Как программа закрепляется в системе, обеспечивая продолжение работы после перезагрузки компьютера?

2. Назовите две хорошие сигнатуры этой вредоносной программы на узле.

3. Каково назначение программы?

4. Как удалить эту вредоносную программу после установки?

• Используйте команды Trace Into и Trace Over. Они могут быть удобнее Add Selection, поскольку не требуют выбирать код для трассировки. Команда Trace Into заходит внутрь и записывает все выполняемые инструкции до срабатывания точки останова. Trace Over записывает только инструкции, выполняемые в текущей функции.

Предупреждение. Если использовать Trace Into и Trace Over, не установив точку останова, OllyDbg попытается трассировать всю программу, что может занять много времени и потребовать много памяти.

• Выберите Debug > Set Condition. Можно вести трассировку до выполнения условия, после чего программа приостановится. Это полезно, когда требуется прекратить трассировку при возникновении условия и выполнить от этого места обратную трассировку, чтобы увидеть, как или почему оно возникло. Пример такого применения приведён в следующем разделе.

Трассировка Poison Ivy

Вспомним из предыдущего обсуждения, что бэкдор Poison Ivy часто выделяет память для шелл-кода, получаемого от командно-контрольного сервера. Poison Ivy загружает шелл-код, копирует его в динамически выделенную область и выполняет. В некоторых случаях с помощью трассировки можно перехватить выполнение шелл-кода, когда EIP находится в куче. Трасса способна показать, как был запущен шелл-код.

На рисунке 9-11 показано условие, заданное для перехвата выполнения Poison Ivy в куче. Мы настроили OllyDbg на приостановку, когда EIP меньше обычного адреса образа (0x400000), ниже которого в простых программах обычно находятся стек, куча и другая динамически выделенная память. В нормальной программе EIP не должен находиться в этих областях. Затем мы выбираем Trace Into, и вся программа должна трассироваться до момента непосредственно перед выполнением шелл-кода.

В данном случае программа приостанавливается, когда EIP равен 0x142A88, то есть в начале шелл-кода. С помощью клавиши - можно переместиться назад и увидеть, как был выполнен шелл-код.

Рисунок 9-11. Условная трассировка

Обработка исключений

По умолчанию, когда при подключённом OllyDbg возникает исключение, программа прекращает выполнение, а управление сначала передаётся отладчику. Отладчик может обработать исключение либо передать его программе. При возникновении исключения OllyDbg приостанавливает выполнение, и вы можете передать исключение программе одним из следующих способов:

• SHIFT-F7 выполняет шаг с заходом в исключение.

• SHIFT-F8 выполняет шаг с обходом исключения.

• SHIFT-F9 запускает обработчик исключения.

В OllyDbg имеются параметры обработки исключений, показанные на рисунке 9-12. С их помощью можно указать отладчику игнорировать определённые исключения и передавать их непосредственно программе. (При анализе вредоносных программ часто имеет смысл игнорировать все исключения, поскольку вы отлаживаете программу не для исправления ошибок.)

Рисунок 9-12. Параметры обработки исключений в OllyDbg

Внесение исправлений

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

Инструкции или память можно изменить, выделив область, щёлкнув её правой кнопкой мыши и выбрав Binary > Edit. Появится окно, где можно добавить любые коды операций или данные. (В OllyDbg также есть специальные функции заполнения значениями 00 или инструкциями NOP.)

На рисунке 9-13 показан фрагмент кода защищённой паролем вредоносной программы, для настройки которой требуется ввести специальный ключ. В точке ❶ видны важная проверка и условный переход (JNZ), определяющие, принят ли ключ. Если переход выполняется, выводится сообщение Bad key; в противном случае выводится Key Accepted!. Простой способ заставить программу пойти по пути принятого ключа - внести исправление. Как показано на рисунке 9-13, выделите инструкцию условного перехода, щёлкните её правой кнопкой мыши и выберите Binary > Fill with NOPs, как в точке ❷. Инструкция JNZ будет заменена инструкциями NOP, и программа решит, что ключ принят.

Рисунок 9-13. Параметры внесения исправлений в OllyDbg

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

Рисунок 9-14. Двухэтапный процесс копирования исправления из оперативной памяти в исполняемый файл на диске

Чтобы применить изменение, щёлкните правой кнопкой мыши окно дизассемблера в месте исправления кода и выберите Copy to Executable > All Modifications, как показано в точке ❶. Все внесённые в оперативной памяти изменения будут скопированы, и появится новое окно, показанное в нижней части рисунка 9-14. Выберите Save File, как показано в точке ❷, чтобы сохранить файл на диск.

Обратите внимание, что рисунок 9-14 содержит тот же код, что и рисунок 9-13, за исключением того, что инструкция JNZ заменена двумя инструкциями NOP. Эта процедура навсегда запишет NOP в соответствующее место исполняемого файла на диске, а значит, вредоносная программа будет всегда принимать любой ключ. Такой приём может быть полезен, когда требуется необратимо изменить вредоносную программу, чтобы упростить её анализ.

Анализ шелл-кода

В OllyDbg имеется простой, хотя и недокументированный, способ анализа шелл-кода. Чтобы воспользоваться им, выполните следующие действия:

1. Скопируйте шелл-код из шестнадцатеричного редактора в буфер обмена.

2. На карте памяти выберите область памяти типа Priv. Это частная память, выделенная процессу, в отличие от доступных только для чтения образов исполняемых файлов, совместно используемых несколькими процессами.

3. Дважды щёлкайте строки карты памяти, чтобы открыть шестнадцатеричный дамп и изучить содержимое. Выбранная область должна содержать несколько сотен непрерывных нулевых байтов.

4. Щёлкните выбранную область в окне Memory Map правой кнопкой мыши и выберите Set Access > Full Access, чтобы предоставить ей разрешения на чтение, запись и выполнение.

5. Вернитесь в окно дампа памяти. Выделите заполненную нулевыми байтами область, достаточно большую для всего шелл-кода, щёлкните выделение правой кнопкой мыши и выберите Binary > Binary Paste. Шелл-код будет вставлен в выбранную область.

6. Установите в регистре EIP адрес изменённой области памяти. (Значение регистра EIP легко задать, щёлкнув правой кнопкой мыши инструкцию в окне дизассемблера и выбрав New Origin Here.)

Теперь шелл-код можно запускать, отлаживать и выполнять пошагово так же, как обычную программу.

Вспомогательные возможности

OllyDbg предоставляет множество механизмов, помогающих анализу, включая следующие:

• Журнал. OllyDbg ведёт постоянно доступный журнал событий. Чтобы открыть его, выберите View > Log. В журнале показано, какие исполняемые модули были загружены, какие точки останова сработали, и другие сведения. Во время анализа журнал помогает выяснить, какие действия привели к определённому состоянию.

• Окно Watches. OllyDbg поддерживает окно Watches, позволяющее наблюдать за значением созданного вами выражения. Выражение постоянно обновляется в этом окне, которое можно открыть командой View > Watches. Чтобы задать выражение в окне Watches, нажмите клавишу пробела.

• Справка. Пункт Help > Contents в OllyDbg содержит подробные инструкции по написанию выражений в разделе Evaluation of Expressions. Это полезно, если требуется наблюдать за конкретным фрагментом данных или сложной функцией. Например, для наблюдения за областью памяти EAX+ESP+4 следует ввести выражение [EAX+ESP+4].

• Метки. Как и IDA Pro, OllyDbg позволяет назначать метки подпрограммам и циклам. Метка в OllyDbg - это просто символическое имя, присвоенное адресу отлаживаемой программы. Чтобы задать метку в окне дизассемблера, щёлкните адрес правой кнопкой мыши и выберите Label. Появится окно с запросом имени метки. Теперь во всех ссылках на это место вместо адреса будет использоваться данная метка. На рисунке 9-15 показан пример добавления метки password_loop. Обратите внимание, как ссылка по адресу 0x401141 изменяется и отражает новое имя.

Рисунок 9-15. Назначение метки в OllyDbg

Подключаемые модули

У OllyDbg есть стандартные подключаемые модули и множество дополнительных, доступных для загрузки. Неплохую коллекцию модулей OllyDbg, полезных для анализа вредоносных программ, можно найти по адресу http://www.openrce.org/downloads/browse/OllyDbg_Plugins.

Подключаемые модули OllyDbg поставляются в виде DLL, которые помещаются в корневой каталог установки OllyDbg. После помещения в этот каталог модули должны автоматически распознаться и добавиться в меню Plugins.

Примечание. Написание подключаемых модулей OllyDbg может быть утомительным. Если вы хотите расширить функциональность OllyDbg, рекомендуем писать сценарии Python, как описано далее в этой главе, в разделе «Сценарная отладка» на странице 200.

OllyDump

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

На рисунке 9-16 показано окно OllyDump. При выгрузке можно вручную задать точку входа и смещения разделов, хотя мы рекомендуем позволить OllyDbg определить их автоматически.

Рисунок 9-16. Окно подключаемого модуля OllyDump

Hide Debugger

Подключаемый модуль Hide Debugger использует ряд методов, чтобы скрыть OllyDbg от средств обнаружения отладчика. Многие аналитики вредоносных программ постоянно запускают этот модуль на случай, если вредоносная программа применяет противодействие отладке.

В частности, этот модуль защищает от проверок IsDebuggerPresent, проверок FindWindow, приёмов с необработанными исключениями и эксплуатации OutputDebugString против OllyDbg. (Методы противодействия отладке обсуждаются в главе 16.)

Command Line

Подключаемый модуль Command Line предоставляет доступ к OllyDbg из командной строки. Командная строка может создать впечатление работы с WinDbg, хотя немногие пользователи OllyDbg пользуются этой возможностью. (Отладчик WinDbg обсуждается в следующей главе.)

Чтобы активировать окно командной строки, выберите Plugins > Command Line > Command Line. В таблице 9-3 перечислены распространённые команды. Дополнительные команды можно найти в файле справки, поставляемом с подключаемым модулем Command Line.

Таблица 9-3. Команды командной строки OllyDbg

Во время отладки часто требуется остановить выполнение в начале импортированной функции, чтобы увидеть передаваемые ей параметры. С помощью командной строки можно быстро установить точку останова в начале импортированной функции.

В примере на рисунке 9-17 строки вредоносной программы скрыты, но программа импортирует gethostbyname. Как показано на рисунке, в командной строке мы выполняем команду bp gethostbyname, устанавливающую точку останова в начале функции gethostbyname. Установив точку, мы запускаем программу, и она останавливается в начале gethostbyname. Рассмотрев параметры, мы видим имя узла, которое программа намерена разрешить: в данном примере это malwareanalysisbook.com.

Рисунок 9-17. Использование командной строки для быстрой установки точек останова

Bookmarks

Подключаемый модуль Bookmarks по умолчанию входит в состав OllyDbg. Он позволяет добавлять закладки для областей памяти, чтобы в дальнейшем легко возвращаться к ним, не запоминая адреса.

Чтобы добавить закладку, щёлкните правой кнопкой мыши окно дизассемблера и выберите Bookmark > Insert Bookmark. Для просмотра закладок выберите Plugins > Bookmarks > Bookmarks, а затем щёлкните любую закладку, чтобы перейти в соответствующее место.

Сценарная отладка

Поскольку подключаемые модули OllyDbg компилируются в DLL, создание или изменение модуля обычно представляет собой сложный процесс. Поэтому для расширения функциональности мы применяем ImmDbg, который использует сценарии Python и имеет простой в использовании API.

Python API ImmDbg включает множество утилит и функций. Например, сценарии можно интегрировать в отладчик как собственный код для создания пользовательских таблиц, графиков и всевозможных интерфейсов. Среди распространённых причин написания сценариев для анализа вредоносных программ - внесение исправлений против обнаружения отладчика, встраиваемый перехват функций и журналирование параметров функций; многие такие сценарии можно найти в Интернете.

Наиболее распространённый вид сценария Python для ImmDbg называется PyCommand. Это сценарий Python, расположенный в каталоге PyCommands\ внутри каталога установки ImmDbg. После написания сценария необходимо скопировать его в этот каталог, чтобы получить возможность запуска. Такие команды Python выполняются из командной строки с предшествующим символом !. Чтобы просмотреть список доступных PyCommand, введите в командной строке !list.

PyCommand имеет следующую структуру:

• Несколько операторов импорта могут использоваться для подключения модулей Python, как в любом сценарии Python. Доступ к функциям самого ImmDbg осуществляется через модуль immlib или immutils.

• Функция main читает аргументы командной строки, переданные в виде списка Python.

• Код реализует действия PyCommand.

• Оператор return возвращает строку. После завершения сценария эта строка появится в главной строке состояния отладчика.

В листинге 9-3 показан простой сценарий, реализованный как PyCommand. С его помощью можно помешать вредоносной программе удалять файл из системы.

Листинг 9-3. Сценарий PyCommand для обезвреживания DeleteFile

Вредоносные программы часто вызывают DeleteFile, чтобы удалить файлы из системы до того, как вы успеете скопировать их в другое место. Если запустить этот сценарий командой !scriptname, он внесёт исправление в функцию DeleteFileA, сделав её бесполезной. Метод main, определённый в точке ❶, вызывает Patch_DeleteFileA. Эту функцию мы определили в точке ❷; она получает адрес DeleteFileA посредством вызова функции getAddress из API ImmDbg. Получив адрес, можно перезаписать функцию собственным кодом. В данном случае она перезаписывается кодом исправления в точке ❸. Этот код устанавливает EAX в 0 и возвращает управление из вызова DeleteFileA. Из-за исправления DeleteFile всегда будет завершаться неудачно, не позволяя вредоносной программе удалять файлы из системы.

Дополнительные сведения о написании сценариев Python можно получить, используя в качестве примеров сценарии команд Python, созданные в ImmDbg. Более подробные пояснения по написанию сценариев Python для ImmDbg приведены в книге Джастина Зейтца «Gray Hat Python» (No Starch Press, 2009).

Заключение

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

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

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

Хотя OllyDbg является самым популярным отладчиком пользовательского режима, следующая глава посвящена самому популярному отладчику режима ядра: WinDbg. Поскольку OllyDbg не может отлаживать вредоносные программы режима ядра, такие как руткиты и драйверы устройств, вам следует познакомиться с WinDbg, если вы хотите выполнять динамический анализ вредоносных программ этого типа.

Лабораторные работы Лабораторная работа 9-1

Проанализируйте с помощью OllyDbg и IDA Pro вредоносную программу из файла Lab09-01.exe и ответьте на следующие вопросы. Эта программа первоначально анализировалась в лабораторных работах главы 3 с помощью основных методов статического и динамического анализа.

Вопросы

1. Как заставить эту вредоносную программу установить себя?

2. Какие параметры командной строки имеет эта программа? Каково требование к паролю?

3. Как с помощью OllyDbg внести в эту вредоносную программу постоянное исправление, чтобы ей не требовался специальный пароль командной строки?

4. Каковы узловые индикаторы этой вредоносной программы?

5. Какие различные действия можно приказать этой вредоносной программе выполнить по сети?

6. Имеются ли полезные сетевые сигнатуры этой вредоносной программы?

Лабораторная работа 9-2

Проанализируйте с помощью OllyDbg вредоносную программу из файла Lab09-02.exe и ответьте на следующие вопросы.

Вопросы

1. Какие строки видны при статическом просмотре двоичного файла?

2. Что происходит при запуске этого двоичного файла?

3. Как заставить этот образец выполнить свою вредоносную полезную нагрузку?

4. Что происходит по адресу 0x00401133?

5. Какие аргументы передаются подпрограмме 0x00401089?

6. Какое доменное имя использует эта вредоносная программа?

7. Какая процедура кодирования используется для сокрытия доменного имени?

8. В чём состоит значение вызова CreateProcessA по адресу 0x0040106E?

Лабораторная работа 9-3

Проанализируйте с помощью OllyDbg и IDA Pro вредоносную программу из файла Lab09-03.exe. Эта программа загружает три включённые DLL (DLL1.dll, DLL2.dll и DLL3.dll), каждая из которых рассчитана на загрузку в одну и ту же область памяти. Поэтому при просмотре этих DLL в OllyDbg и IDA Pro код может отображаться по разным адресам памяти. Цель этой лабораторной работы - научить вас уверенно находить правильное расположение кода в IDA Pro при просмотре кода в OllyDbg.

Вопросы

1. Какие DLL импортирует Lab09-03.exe?

2. Какой базовый адрес запрашивают DLL1.dll, DLL2.dll и DLL3.dll?

3. Какой базовый адрес назначен DLL1.dll, DLL2.dll и DLL3.dll при отладке Lab09-03.exe в OllyDbg?

4. Что делает импортированная функция из DLL1.dll, когда Lab09-03.exe вызывает её?

5. Каково имя файла, в который Lab09-03.exe записывает данные при вызове WriteFile?

6. Откуда Lab09-03.exe получает данные для второго параметра, когда создаёт задание с помощью NetScheduleJobAdd?

7. При выполнении или отладке программа выводит три фрагмента загадочных данных. Что представляют собой следующие значения: загадочные данные 1 из DLL 1, загадочные данные 2 из DLL 2 и загадочные данные 3 из DLL 3?

8. Как загрузить DLL2.dll в IDA Pro, чтобы адрес загрузки совпадал с используемым OllyDbg?

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

Руткиты

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

Большинство используемых руткитов тем или иным образом изменяет ядро. Хотя руткиты могут применять широкий спектр методов, на практике один из них используется чаще всех остальных: перехват таблицы дескрипторов системных служб (System Service Descriptor Table, SSDT). Этот метод существует несколько лет, и по сравнению с другими методами руткитов его легко обнаружить. Тем не менее вредоносные программы продолжают его использовать, поскольку он понятен, гибок и прост в реализации.

Таблица дескрипторов системных служб, которую иногда называют таблицей диспетчеризации системных служб (System Service Dispatch Table), используется Microsoft внутри системы для поиска вызовов функций ядра. Обычно к ней не обращаются сторонние приложения или драйверы. Вспомним из главы 7, что код ядра доступен из пользовательского пространства только посредством инструкций SYSCALL, SYSENTER или INT 0x2E. Современные версии Windows используют инструкцию SYSENTER, которая получает инструкции из кода функции, хранящегося в регистре EAX. В листинге 10-11 показан код из ntdll.dll, реализующий функцию NtCreateFile и выполняющий переходы из пользовательского пространства в пространство ядра при каждом вызове NtCreateFile.

Листинг 10-11. Код функции NtCreateFile

Вызов dword ptr [edx] перейдёт к следующим инструкциям:

В листинге 10-11 регистр EAX получает значение 0x25 в точке ❶, указатель стека сохраняется в EDX, а затем вызывается инструкция sysenter. Значение в EAX - номер функции NtCreateFile, который после перехода кода в ядро используется как индекс в SSDT. В частности, в режиме ядра будет вызван адрес со смещением 0x25 в точке ❶ таблицы SSDT. В листинге 10-12 показаны несколько записей SSDT, в том числе запись NtCreateFile со смещением 25.

Листинг 10-12. Несколько записей таблицы SSDT, включая NtCreateFile

Когда руткит перехватывает одну из этих функций, он изменяет значение в SSDT, чтобы вместо предусмотренной функции ядра вызывался код руткита. В предыдущем примере запись 0x25 была бы изменена так, чтобы указывать на функцию внутри вредоносного драйвера. Это изменение способно модифицировать функцию таким образом, чтобы открыть и изучить вредоносный файл стало невозможно. Обычно в руткитах это реализуется вызовом исходной NtCreateFile с фильтрацией результатов в соответствии с настройками руткита. Руткит просто удаляет из результатов все файлы, которые хочет скрыть, не позволяя другим приложениям получить их дескрипторы.

Руткит, перехватывающий только NtCreateFile, не сможет скрыть файл из списка каталога. В лабораторных работах этой главы вы увидите более реалистичный руткит, скрывающий файлы из списков каталогов.

Практический анализ руткита

Теперь рассмотрим пример руткита, перехватывающего SSDT. Мы проанализируем гипотетически заражённую систему, в которой, по нашему мнению, установлен вредоносный драйвер.

Первый и самый очевидный способ проверить перехват SSDT - изучить саму SSDT. В WinDbg её можно просмотреть по смещению, хранящемуся в nt!KeServiceDescriptorTable. Все смещения функций в SSDT должны указывать на функции внутри границ модуля NT, поэтому сначала мы получили эти границы. В нашем случае ntoskrnl.exe начинается по адресу 804d7000 и заканчивается по адресу 806cd580. Если руткит перехватывает одну из функций, скорее всего, она будет указывать не внутрь модуля NT. Изучая SSDT, мы видим одну функцию, которая, похоже, не вписывается в него. В листинге 10-13 приведена сокращённая версия SSDT.

Листинг 10-13. Пример таблицы SSDT с одной записью, перезаписанной руткитом

Значение по смещению 0x25 этой таблицы в точке ❶ указывает на функцию за пределами модуля ntoskrnl, поэтому, вероятно, эту функцию перехватывает руткит. В данном случае перехватывается NtCreateFile. Определить, какая функция перехвачена, можно, изучив SSDT в системе без установленного руткита и посмотрев, какая функция находится по этому смещению. Узнать, какой модуль содержит адрес перехвата, можно, перечислив открытые модули командой lm, как показано в листинге 10-14. В ядре все перечисленные модули являются драйверами. Мы находим драйвер, содержащий адрес 0xf7ad94a4, и видим, что этот адрес находится внутри драйвера с именем Rootkit.

Листинг 10-14. Поиск командой lm драйвера, содержащего определённый адрес

Определив драйвер, мы найдём код перехвата и начнём анализ. Нас интересуют две вещи: фрагмент кода, устанавливающий перехват, и функция, выполняющая перехват. Проще всего найти функцию, устанавливающую перехват, выполнив в IDA Pro поиск ссылок данных на функцию перехвата. В листинге 10-15 приведён ассемблерный код, перехватывающий SSDT.

Листинг 10-15. Код руткита, устанавливающий перехват в SSDT

Этот код перехватывает функцию NtCreateFile. Первые два вызова функций в точках ❶ и ❷ создают строки NtCreateFile и KeServiceDescriptorTable, которые используются для поиска адресов экспортируемых значений. Они экспортируются ntoskrnl.exe и могут импортироваться драйверами ядра подобно любым другим значениям. Эти экспортируемые значения также можно получить во время выполнения. В режиме ядра нельзя загрузить GetProcAddress, но её эквивалентом является MmGetSystemRoutineAddress. Он немного отличается от GetProcAddress, поскольку может получать адреса экспортируемых значений только из модулей ядра hal и ntoskrnl.

Первый вызов MmGetSystemRoutineAddress в точке ❸ раскрывает адрес функции NtCreateFile, который вредоносная программа использует для определения перезаписываемого адреса в SSDT. Второй вызов MmGetSystemRoutineAddress даёт адрес самой SSDT.

Затем цикл от точки ❹ до точки ❺ перебирает SSDT, пока не найдёт значение, совпадающее с адресом NtCreateFile; оно и будет перезаписано перехватывающей функцией.

Перехват устанавливает последняя инструкция листинга в точке ❻, копирующая адрес процедуры в область памяти.

Функция перехвата выполняет несколько простых задач. Она отфильтровывает определённые запросы, а остальные передаёт исходной NtCreateFile. Функция перехвата показана в листинге 10-16.

Листинг 10-16. Код функции перехвата руткита

Для одних запросов функция перехвата переходит к исходной функции NtCreateFile, а для других возвращает значение 0xC0000034. Значение 0xC0000034 соответствует STATUS_OBJECT_NAME_NOT_FOUND. Вызов в точке ❶ содержит код, который не показан и оценивает ObjectAttributes файла, то есть сведения об объекте, например имя файла, к которому обращается программа пользовательского пространства.

Функция перехвата возвращает ненулевое значение, если функции NtCreateFile разрешено продолжить работу, и ноль, если руткит блокирует открытие файла. Если функция перехвата возвращает ноль, приложения пользовательского пространства получают ошибку, сообщающую, что файл не существует. Это не позволяет пользовательским приложениям получать дескрипторы определённых файлов, не мешая другим вызовам NtCreateFile.

Прерывания

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

Драйверы или руткиты иногда используют прерывания для выполнения кода. Драйвер вызывает IoConnectInterrupt, чтобы зарегистрировать обработчик определённого кода прерывания, а затем задаёт процедуру обслуживания прерывания (interrupt service routine, ISR), которую ОС будет вызывать при каждом возникновении данного кода прерывания.

Таблица дескрипторов прерываний (Interrupt Descriptor Table, IDT) хранит сведения об ISR, которые можно просмотреть командой !idt. В листинге 10-17 показана обычная IDT, где все прерывания направляются известным драйверам, подписанным Microsoft.

Листинг 10-17. Пример IDT

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

Загрузка драйверов

На протяжении этой главы мы предполагали, что анализируемая вредоносная программа содержит компонент пользовательского пространства для своей загрузки. Если у вас есть вредоносный драйвер, но нет устанавливающего его приложения пользовательского пространства, драйвер можно загрузить с помощью загрузчика, например OSR Driver Loader, показанного на рисунке 10-4. Этот загрузчик драйверов очень прост в использовании и бесплатен, но требует регистрации. После установки OSR Driver Loader просто запустите загрузчик, укажите загружаемый драйвер, а затем нажмите Register Service и Start Service, чтобы запустить драйвер.

Рисунок 10-4. Окно OSR Driver Loader

Особенности ядра в Windows Vista, Windows 7 и версиях x64

В новых версиях Windows было внесено несколько крупных изменений, влияющих на процесс отладки ядра и эффективность вредоносных программ ядра. Большинство вредоносных программ всё ещё нацелено на компьютеры x86 под управлением Windows XP, но по мере роста популярности Windows 7 и x64 будет становиться больше и вредоносных программ для этих систем.

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

Самое значительное изменение безопасности - реализация механизма защиты от исправлений ядра, обычно называемого PatchGuard, в версиях Windows x64 начиная с Windows XP. Защита от исправлений ядра не позволяет стороннему коду изменять ядро. Сюда относятся изменения самого кода ядра, таблиц системных служб, IDT и применение других методов исправления. При появлении эта функция вызвала некоторые споры, поскольку исправление ядра используется как вредоносными, так и невредоносными программами. Например, межсетевые экраны, антивирусы и другие защитные продукты регулярно исправляют ядро для обнаружения и предотвращения вредоносной деятельности.

Защита от исправлений ядра также может мешать отладке в 64-разрядной системе, поскольку при вставке точек останова отладчик вносит исправления в код. Поэтому, если отладчик ядра подключён к ОС во время загрузки, защита от исправлений не запускается. Однако если подключить отладчик ядра после загрузки системы, PatchGuard вызовет сбой системы.

Начиная с Vista в 64-разрядных версиях Windows обязательна подпись драйверов. Это означает, что загрузить драйвер на компьютер с Windows Vista можно только при наличии цифровой подписи. Вредоносные программы обычно не подписаны, поэтому данная мера эффективно защищает от вредоносных драйверов ядра. Фактически вредоносные программы ядра для систем x64 почти не существуют, но по мере распространения версий Windows x64 они, несомненно, будут развиваться, чтобы обходить этот барьер. Если необходимо загрузить неподписанный драйвер в системе x64 Vista, параметры загрузки можно изменить с помощью утилиты BCDEdit. В частности, параметр nointegritychecks отключает требование подписи драйверов.

Заключение

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

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

Лабораторные работы Лабораторная работа 10-1

Эта лабораторная работа включает драйвер и исполняемый файл. Исполняемый файл можно запускать из любого места, но для правильной работы программы драйвер необходимо поместить в каталог C:\Windows\System32, где он первоначально был найден на компьютере жертвы. Исполняемый файл называется Lab10-01.exe, а драйвер - Lab10-01.sys.

Вопросы

1. Вносит ли эта программа какие-либо непосредственные изменения в реестр? (Проверьте с помощью procmon.)

2. Программа пользовательского пространства вызывает функцию ControlService. Можете ли вы установить в WinDbg точку останова, чтобы увидеть, что в результате вызова ControlService выполняется в ядре?

3. Что делает эта программа?

Лабораторная работа 10-2

Файл этой лабораторной работы называется Lab10-02.exe.

Вопросы

1. Создаёт ли эта программа какие-либо файлы? Если да, то какие?

2. Есть ли у этой программы компонент ядра?

3. Что делает эта программа?

Лабораторная работа 10-3

Эта лабораторная работа включает драйвер и исполняемый файл. Исполняемый файл можно запускать из любого места, но для правильной работы программы драйвер необходимо поместить в каталог C:\Windows\System32, где он первоначально был найден на компьютере жертвы. Исполняемый файл называется Lab10-03.exe, а драйвер - Lab10-03.sys.

Вопросы

1. Что делает эта программа?

2. Как остановить эту программу после запуска?

3. Что делает компонент ядра?

6. Каталоги, перечисленные в переменной среды PATH.

В Windows XP процесс поиска DLL можно обойти с помощью ключа реестра KnownDLLs, содержащего список конкретных расположений DLL, обычно в .../Windows/System32/. Механизм KnownDLLs предназначен для повышения безопасности, поскольку вредоносные DLL нельзя поместить выше в порядке загрузки, и скорости, поскольку Windows не требуется выполнять стандартный поиск по приведённому списку. Однако этот ключ содержит лишь короткий список важнейших DLL.

Перехват порядка загрузки DLL можно применять к двоичным файлам в каталогах за пределами /System32, которые загружают из /System32 DLL, не защищённые KnownDLLs. Например, explorer.exe в каталоге /Windows загружает ntshrui.dll, находящуюся в /System32. Поскольку ntshrui.dll не является известной DLL, выполняется стандартный поиск, при котором каталог /Windows проверяется раньше /System32. Если поместить в /Windows вредоносную DLL с именем ntshrui.dll, она будет загружена вместо законной. Затем вредоносная DLL может загрузить настоящую библиотеку, чтобы система продолжала правильно работать.

Любой запускаемый при старте двоичный файл не из /System32 уязвим для этой атаки, а у explorer.exe имеется около 50 уязвимых DLL. Кроме того, известные DLL защищены не полностью из-за рекурсивного импорта и потому, что многие DLL загружают другие DLL, следующие стандартному порядку поиска.

Повышение привилегий

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

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

Большинство атак повышения привилегий представляет собой известные эксплойты или атаки нулевого дня против локальной ОС. Многие из них можно найти в Metasploit Framework (http://www.metasploit.com/). Даже перехват порядка загрузки DLL можно использовать для повышения привилегий. Если пользователь может записывать в каталог, где находится вредоносная DLL, а загружающий её процесс выполняется с более высоким уровнем привилегий, вредоносная DLL получит повышенные привилегии. Вредоносные программы с повышением привилегий встречаются относительно редко, но достаточно часто, чтобы аналитик умел их распознавать.

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

Использование SeDebugPrivilege

Запущенные пользователем процессы не имеют свободного доступа ко всему и, например, не могут вызывать для удалённых процессов такие функции, как TerminateProcess или CreateRemoteThread. Один из способов получения вредоносной программой доступа к подобным функциям - изменение прав маркера доступа для включения SeDebugPrivilege. В системах Windows маркер доступа является объектом, содержащим дескриптор безопасности процесса. Дескриптор безопасности задаёт права доступа владельца, в данном случае процесса. Маркер доступа можно изменить вызовом AdjustTokenPrivileges.

Привилегия SeDebugPrivilege создавалась как средство отладки на уровне системы, но авторы вредоносных программ используют её для получения полного доступа к системному процессу. По умолчанию SeDebugPrivilege предоставляется только учётным записям локальных администраторов, и считается, что её предоставление кому-либо по сути равнозначно доступу к учётной записи LocalSystem. Обычная учётная запись пользователя не может предоставить себе SeDebugPrivilege: запрос будет отклонён.

В листинге 11-6 показано, как вредоносная программа включает свою привилегию SeDebugPrivilege.

Листинг 11-6. Настройка маркера доступа на SeDebugPrivilege

Маркер доступа получают вызовом OpenProcessToken в точке ❶, передавая дескриптор процесса, полученный вызовом GetCurrentProcess, и требуемый доступ, в данном случае запрос и изменение привилегий. Затем вредоносная программа вызывает LookupPrivilegeValueA, которая получает локально уникальный идентификатор (LUID). LUID - структура, представляющая указанную привилегию, в данном случае SeDebugPrivilege.

Сведения, полученные от OpenProcessToken и LookupPrivilegeValueA, используются при вызове AdjustTokenPrivileges в точке ❷. Важная структура PTOKEN_PRIVILEGES, которую IDA Pro обозначила как NewState, также передаётся AdjustTokenPrivileges. Обратите внимание, что эта структура задаёт младшую и старшую части LUID по результату LookupPrivilegeValueA в два этапа, показанных в точках ❸ и ❹. Полю Attributes структуры NewState присваивается значение SE_PRIVILEGE_ENABLED в точке ❺, чтобы включить SeDebugPrivilege.

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

Сокрытие следов: руткиты пользовательского режима

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

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

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

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

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

Перехват IAT

Перехват IAT - классический метод руткита пользовательского пространства, скрывающий файлы, процессы или сетевые соединения в локальной системе. Этот метод изменяет таблицу адресов импорта (IAT) или таблицу адресов экспорта (EAT). Пример перехвата IAT показан на рисунке 11-4. Законная программа вызывает функцию TerminateProcess, как видно в точке ❶. Обычно код использует IAT для доступа к целевой функции в Kernel32.dll, но если установлен перехват IAT, как показано в точке ❷, вместо неё вызывается вредоносный код руткита. После изменения некоторых параметров код руткита возвращается в законную программу и позволяет выполнить функцию TerminateProcess. В данном примере перехват IAT не даёт законной программе завершить процесс.

Рисунок 11-4. Перехват IAT функции TerminateProcess: верхний путь является нормальным потоком, а нижний - потоком с руткитом

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

Встраиваемый перехват

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

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

Пример встраиваемого перехвата функции ZwDeviceIoControlFile показан в листинге 11-7. Эта функция используется такими программами, как Netstat, для получения сетевых сведений из системы.

Листинг 11-7. Пример встраиваемого перехвата

Адрес перехватываемой функции получается в точке ❶. Цель этого руткита - установить 7-байтовый встраиваемый перехват в начале находящейся в памяти функции ZwDeviceIoControlFile. В таблице 11-2 показана инициализация перехвата: слева приведены необработанные байты, справа - ассемблерный код.

Таблица 11-2. 7-байтовый встраиваемый перехват

Ассемблерный код начинается с кода операции 0xB8 (mov imm/r), за которым следуют четыре нулевых байта, а затем коды операций 0xFF 0xE0 (jmp eax). Перед установкой перехвата руткит заполняет эти нулевые байты адресом, чтобы инструкция jmp стала допустимой. В IDA Pro этот вид можно активировать клавишей C.

Руткит использует простой memcpy, чтобы заменить нулевые байты адресом своей перехватывающей функции, скрывающей трафик, направленный к порту 443. Обратите внимание, что указанный адрес (10004011) совпадает с адресом нулевых байтов в предыдущем примере.

Затем байты исправления (10004010) и адрес перехвата передаются функции, устанавливающей встраиваемый перехват, как показано в листинге 11-8.

Листинг 11-8. Установка встраиваемого перехвата

Теперь ZwDeviceIoControlFile сначала вызывает функцию руткита. Перехватывающая функция руткита удаляет весь трафик, направленный к порту 443, а затем вызывает настоящую ZwDeviceIoControlFile, поэтому всё продолжает работать так же, как до установки перехвата.

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

Заключение

В этой главе мы кратко познакомились с некоторыми распространёнными возможностями вредоносных программ. Сначала рассмотрели различные типы бэкдоров. Затем изучили, как вредоносные программы крадут учётные данные жертвы. Далее разобрали различные способы закрепления вредоносной программы в системе. Наконец, показали, как она скрывает следы, чтобы её было нелегко обнаружить. Теперь вы знакомы с наиболее распространёнными вариантами поведения вредоносных программ.

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

Лабораторные работы Лабораторная работа 11-1

Проанализируйте вредоносную программу из файла Lab11-01.exe.

Вопросы

1. Что вредоносная программа сохраняет на диск?

2. Как вредоносная программа закрепляется в системе?

3. Как вредоносная программа похищает учётные данные пользователей?

4. Что вредоносная программа делает с похищенными учётными данными?

5. Как использовать эту вредоносную программу, чтобы получить учётные данные пользователей из тестовой среды?

Лабораторная работа 11-2

Проанализируйте вредоносную программу из файла Lab11-02.dll. Предположите, что вместе с ней также найден подозрительный файл Lab11-02.ini.

Вопросы

1. Какие экспортируемые функции имеются у этой вредоносной DLL?

2. Что происходит после попытки установить эту вредоносную программу с помощью rundll32.exe?

3. Где должен находиться Lab11-02.ini, чтобы вредоносная программа установилась правильно?

4. Как эта вредоносная программа устанавливается для закрепления?

5. Какой метод руткита пользовательского пространства применяет эта вредоносная программа?

6. Что делает код перехвата?

7. Какие процессы атакует эта вредоносная программа и почему?

8. Каково значение файла .ini?

9. Как динамически перехватить деятельность этой вредоносной программы с помощью Wireshark?

Лабораторная работа 11-3

Проанализируйте вредоносные программы из файлов Lab11-03.exe и Lab11-03.dll. Во время анализа убедитесь, что оба файла находятся в одном каталоге.

Вопросы

1. Какие интересные направления анализа можно обнаружить с помощью базового статического анализа?

2. Что происходит при запуске этой вредоносной программы?

3. Как Lab11-03.exe устанавливает Lab11-03.dll для постоянного закрепления?

4. Какой системный файл Windows заражает вредоносная программа?

5. Что делает Lab11-03.dll?

6. Где вредоносная программа хранит собранные данные?