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

ПК состоит из печатных плат, которые соединяют различные компоненты и предоставляют разъёмы для периферийных устройств. Главная плата такой системы - материнская плата - обеспечивает соединения, позволяющие компонентам системы обмениваться данными. Эти каналы связи обычно называют компьютерными шинами. В этом разделе рассматриваются компоненты и шины, с которыми должен быть знаком следователь. На рис. 1-1 показано типичное расположение различных компонентов, описываемых в этом разделе.

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

Рисунок 1-1. Физическая организация современной системы

Чтение из основной памяти зачастую происходит значительно медленнее, чем чтение из собственной памяти ЦП. Поэтому в современных системах для уменьшения этого разрыва используется несколько уровней быстрой памяти, называемой кешем. Каждый следующий уровень кеша (L1, L2 и так далее) относительно медленнее и больше предыдущего. В большинстве систем эти кеши встроены в процессор и каждое его ядро. Если данные не найдены в определённом кеше, их приходится извлекать из кеша следующего уровня или из основной памяти.

Чтобы определить, где хранятся данные, ЦП использует блок управления памятью (memory management unit, MMU). MMU - это аппаратный блок, преобразующий адрес, запрошенный процессором, в соответствующий адрес основной памяти. Как будет рассказано далее в этой главе, структуры данных, управляющие преобразованием адресов, также хранятся в основной памяти. Поскольку для одного преобразования может потребоваться несколько операций чтения из памяти, процессор использует специальный кеш таблицы преобразований MMU - буфер ассоциативной трансляции (translation lookaside buffer, TLB). Перед каждым обращением к памяти сначала проверяется TLB, и лишь затем MMU предлагается выполнить дорогостоящую операцию преобразования адреса.

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

Для управления обменом данными с основной памятью ЦП использует контроллер памяти. Контроллер памяти согласует потенциально одновременные запросы к системной памяти, поступающие от одного или нескольких процессоров и устройств. Он может быть реализован в отдельной микросхеме или встроен в сам процессор. В старых ПК ЦП соединялся с северным мостом (концентратором контроллера памяти) посредством системной шины, а северный мост подключался к основной памяти через шину памяти. Устройства, например сетевые платы и дисковые контроллеры, подключались через другую микросхему, называемую южным мостом или концентратором контроллера ввода-вывода. Для доступа к памяти и ЦП у неё имелось одно общее соединение с северным мостом.

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

Для повышения общей производительности большинство современных систем позволяет устройствам ввода-вывода напрямую передавать данные, хранящиеся в системной памяти, без вмешательства процессора. Эта возможность называется прямым доступом к памяти (direct memory access, DMA). До появления DMA ЦП был полностью занят во время операций ввода-вывода и нередко выступал посредником при передаче. В современных архитектурах ЦП может инициировать передачу данных и поручить управление ею контроллеру DMA, а устройство ввода-вывода способно начать передачу независимо от ЦП.

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

Другой пример - интерфейс IEEE 1394, широко известный как FireWire. Микросхема хост-контроллера IEEE 1394 предоставляет одноранговую последовательную шину расширения, предназначенную для подключения к ПК высокоскоростных периферийных устройств. Хотя встроенный интерфейс IEEE 1394 обычно встречается лишь в системах верхнего ценового диапазона, его можно добавить как в настольный, так и в портативный компьютер с помощью платы расширения.

Основная память ПК реализована на основе памяти с произвольным доступом (random access memory, RAM), в которой хранятся код и данные, активно считываемые и записываемые процессором. В отличие от устройств хранения с последовательным доступом, обычно представленных дисками, произвольный доступ означает, что время доступа остаётся постоянным независимо от местоположения данных на носителе.

В большинстве ПК основная память представляет собой динамическую RAM (dynamic RAM, DRAM). Динамической она называется потому, что для хранения одного бита данных использует различие между заряженным и разряженным состояниями конденсатора. Чтобы конденсатор сохранял это состояние, его необходимо периодически обновлять; обычно эту задачу выполняет контроллер памяти.

RAM считается энергозависимой памятью, поскольку для сохранения доступности данных ей требуется питание. Поэтому после выключения ПК энергозависимая память утрачивается, за исключением случаев атаки с холодной перезагрузкой (citp.princeton.edu). Именно поэтому тактика реагирования на инциденты «выдернуть вилку из розетки» не рекомендуется, если требуется сохранить свидетельства текущего состояния системы.

Как уже говорилось, ЦП является одним из важнейших компонентов компьютерной системы. Чтобы эффективно извлекать структуру из физической памяти и понимать, каким образом вредоносный код способен нарушить безопасность системы, необходимо хорошо знать программную модель доступа к памяти, предоставляемую ЦП. Предыдущий раздел был посвящён физической организации аппаратного обеспечения, тогда как в этом рассматривается его логическая организация, видимая операционной системе. Сначала обсуждаются некоторые общие вопросы, относящиеся к архитектурам ЦП, а затем выделяются особенности, важные для анализа памяти. В частности, основное внимание уделяется 32-разрядной (IA-32) и 64-разрядной (Intel 64) организации, описанной в руководстве разработчика программного обеспечения по архитектурам Intel 64 и IA-32 (intel.com).

Чтобы ЦП мог выполнять инструкции и обращаться к данным, хранящимся в основной памяти, он должен указывать уникальный адрес этих данных. Рассматриваемые в книге процессоры используют побайтовую адресацию, и доступ к памяти осуществляется как к последовательности байтов. Адресным пространством называется диапазон допустимых адресов, служащих для идентификации данных в пределах конечного выделенного объёма памяти. В частности, эта книга посвящена системам, в которых байт определяется как 8-разрядная величина. При такой схеме адресация обычно начинается с байта 0 и заканчивается смещением последнего байта выделенной памяти. Единое непрерывное адресное пространство, предоставляемое выполняющейся программе, называется линейным адресным пространством. С учётом рассматриваемых в книге моделей памяти и применения в них страничной организации термины «линейный адрес» и «виртуальный адрес» используются как взаимозаменяемые. Термином «физическое адресное пространство» мы обозначаем адреса, которые процессор запрашивает для доступа к физической памяти. Эти адреса получают путём преобразования линейных адресов в физические с помощью одной или нескольких таблиц страниц.

Таблицы страниц подробнее рассматриваются далее. В следующих разделах описана реализация адресных пространств памяти в разных процессорных архитектурах.

Под архитектурой IA-32 обычно понимают семейство архитектур x86, поддерживающих 32-разрядные вычисления. В частности, она определяет набор инструкций и программную среду 32-разрядных процессоров Intel. IA-32 использует порядок байтов от младшего к старшему и побайтовую адресацию. Программное обеспечение, выполняющееся на процессоре IA-32, может располагать линейным адресным пространством и физическим адресным пространством объёмом до 4 Гбайт. Как будет показано далее, с помощью расширения физических адресов IA-32 (Physical Address Extension, PAE) объём физической памяти можно увеличить до 64 Гбайт. В этом разделе и далее по всей книге рассматривается работа архитектуры IA-32 в защищённом режиме, который поддерживает такие возможности, как виртуальная память, страничная организация, уровни привилегий и сегментация. Это основное состояние процессора и одновременно режим, в котором работает большинство современных операционных систем.

Архитектура IA-32 определяет небольшой объём чрезвычайно быстрой памяти, называемой регистрами, которую ЦП использует для временного хранения данных во время обработки. Каждое процессорное ядро содержит восемь 32-разрядных регистров общего назначения для выполнения логических и арифметических операций, а также несколько других регистров, управляющих поведением процессора. Здесь мы рассмотрим несколько управляющих регистров, имеющих значение для анализа памяти.

Регистр EIP, также называемый счётчиком команд, содержит линейный адрес следующей выполняемой инструкции. В архитектуре IA-32 предусмотрено также пять управляющих регистров, которые задают конфигурацию процессора и характеристики выполняемой задачи. CR0 содержит флаги, управляющие режимом работы процессора, в том числе флаг включения страничной организации памяти. CR1 зарезервирован, и обращаться к нему не следует. CR2 содержит линейный адрес, вызвавший ошибку страницы. CR3 содержит физический адрес начальной структуры, используемой для преобразования адресов. Он обновляется при переключении контекста, когда на выполнение назначается новая задача. CR4 служит для включения архитектурных расширений, в том числе PAE.

Процессоры IA-32 реализуют два механизма управления памятью: сегментацию и страничную организацию. Сегментация делит 32-разрядное линейное адресное пространство на несколько сегментов переменной длины.

Во всех обращениях к памяти IA-32 используется 16-разрядный селектор сегмента, указывающий на определённый дескриптор сегмента, и 32-разрядное смещение внутри указанного сегмента. Дескриптор сегмента - это находящаяся в памяти структура данных, определяющая расположение, размер, тип и разрешения конкретного сегмента. Каждое процессорное ядро содержит два специальных регистра, GDTR и LDTR, которые указывают соответственно на таблицы дескрипторов сегментов, называемые глобальной таблицей дескрипторов (Global Descriptor Table, GDT) и локальной таблицей дескрипторов (Local Descriptor Table, LDT). Регистры сегментов CS (код), SS (стек), а также DS, ES, FS и GS (данные) всегда должны содержать допустимые селекторы сегментов.

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

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

Архитектура IA-32 поддерживает также страницы размером 4 Мбайт, для преобразования которых требуется только каталог страниц. Используя разные структуры страничной организации для разных процессов, операционная система может посредством виртуализированного линейного адресного пространства создавать для каждого процесса видимость среды, в которой выполняется только одна программа. На рис. 1-3 более подробно показано разбиение разрядов, преобразующих виртуальный адрес в смещение в физической памяти.

Рисунок 1-2. Преобразование адреса для страницы размером 4 Кбайт при 32-разрядной страничной организации

Рисунок 1-3. Форматы адресов структур страничной организации, используемых при 32-разрядной страничной организации

Чтобы вычислить адрес элемента каталога страниц (page directory entry, PDE), объединяют разряды 31:12 регистра CR3 с разрядами 31:22 виртуального адреса. Затем элемент таблицы страниц (page table entry, PTE) находят, объединяя разряды 31:12 PDE с разрядами 21:12 виртуального адреса. Наконец, физический адрес (physical address, PA) получают, объединяя разряды 31:12 PTE с разрядами 11:0 виртуального адреса. В следующем разделе эти вычисления будут применены при пошаговом ручном преобразовании адреса.

Чтобы в полной мере поддерживать архитектуру ЦП с виртуальной памятью, программное обеспечение для экспертизы памяти, например Volatility, должно имитировать виртуальное адресное пространство и прозрачно выполнять преобразование виртуальных адресов в физические. Ручное прохождение всех этапов преобразования адреса помогает закрепить понимание работы таких инструментов и даёт необходимые знания для устранения причин неожиданного поведения.

Для этого упражнения предположим, что вы анализируете один из образцов памяти ENG-USTXHOU-148, включённых в ноябрьское состязание Джека Крука по компьютерной криминалистике 2012 года (см. blog.handlerdiaries.com). Во время анализа вы обнаружили ссылку на виртуальный адрес 0x10016270 в виртуальном адресном пространстве процесса svchost.exe с PID 1024. База каталога страниц (CR3) для PID 1024 равна 0x7401000. Требуется найти соответствующий физический адрес, чтобы выяснить, какие ещё данные могут располагаться рядом с ним в памяти.

Сначала преобразуем виртуальный адрес 0x10016270 из шестнадцатеричного представления в двоичное, поскольку далее предстоит работать с диапазонами разрядов адреса:

Затем адрес разбивается на соответствующие смещения, используемые при преобразовании. Результат показан в табл. 1-1.

Таблица 1-1. Разбиение разрядов при преобразовании виртуального адреса

Как видно на рис. 1-2 и 1-3, физический адрес PDE можно вычислить, умножив индекс каталога страниц на размер элемента (4 байта), а затем прибавив базу каталога страниц 0x7401000. Десять разрядов виртуального адреса позволяют индексировать 1024 (2^10) элемента каталога страниц.

Далее необходимо прочитать из физической памяти значение, хранящееся по адресу PDE. Не забудьте учесть, что это значение хранится в формате с порядком байтов от младшего к старшему. Теперь известно, что значение PDE равно 0x17bf9067. Согласно рис. 1-3, разряды 31:12 PDE задают физический адрес базы таблицы страниц. Разряды 21:12 виртуального адреса задают индекс таблицы страниц, поскольку таблица страниц состоит из 1024 (2^10) элементов. Физический адрес PTE можно вычислить, умножив размер элемента (4 байта) на индекс таблицы страниц и затем прибавив полученное значение к базе таблицы страниц.

Значение PTE, хранящееся по этому адресу, равно 0x170b6067. Согласно рис. 1-3, разряды 31:12 физического адреса берутся из PTE, а разряды 11:0 - из виртуального адреса. Следовательно, окончательный преобразованный физический адрес вычисляется так:

Завершив преобразование, мы установили, что виртуальный адрес 0x10016270 соответствует физическому адресу 0x170b6270. На рис. 1-4 наглядно показаны выполненные шаги. Можно найти в образце памяти байт с этим смещением и проверить, нет ли в непосредственной близости связанных с ним артефактов. Именно эту процедуру адресное пространство Volatility IA32PagedMemory выполняет при каждом обращении к виртуальному адресу. Далее будет показано, как расширить этот процесс для поддержки более крупных виртуальных адресных пространств.

Рисунок 1-4. Пример преобразования адреса для страницы размером 4 Кбайт при 32-разрядной страничной организации

Механизм страничной организации архитектуры IA-32 поддерживает также PAE. Это расширение позволяет процессору работать с физическими адресными пространствами размером более 4 Гбайт. Хотя линейные адресные пространства программ по-прежнему ограничены 4 Гбайт, блок управления памятью отображает эти адреса в расширенное 64-гигабайтное физическое адресное пространство. В системах с включённым PAE линейный адрес делится на четыре индекса:

• таблица указателей каталогов страниц (page directory pointer table, PDPT);

• каталог страниц (page directory, PD);

• таблица страниц (page table, PT);

• смещение страницы.

На рис. 1-5 показан пример преобразования адреса для страницы размером 4 Кбайт при 32-разрядной страничной организации с PAE. Основные различия заключаются в появлении в иерархии структур страничной организации дополнительного уровня, называемого таблицей указателей каталогов страниц, и в том, что элементы структур страничной организации теперь имеют длину 64 бита. С учётом этих изменений регистр CR3 теперь содержит физический адрес таблицы указателей каталогов страниц.

На рис. 1-6 показаны форматы адресов структур страничной организации, используемых при 32-разрядной страничной организации с PAE. Когда PAE включено, первая таблица страничной организации содержит только 4 (2^2) элемента. Разряды 31:30 виртуального адреса выбирают элемент таблицы указателей каталогов страниц (page directory pointer table entry, PDPTE). Разряды 29:21 служат индексом для выбора одного из 512 (2^9) PDE. Если установлен флаг PS, PDE отображает страницу размером 2 Мбайт. В противном случае 9 разрядов, извлечённых из разрядов 20:12, выбирают один из 512 (2^9) PTE. Если все элементы допустимы и адрес отображается в страницу размером 4 Кбайт, последние 12 разрядов виртуального адреса задают смещение внутри страницы для соответствующего PA.

Рисунок 1-5. Преобразование адреса для страницы размером 4 Кбайт при 32-разрядной страничной организации с PAE

Рисунок 1-6. Форматы адресов структур страничной организации, используемых при 32-разрядной страничной организации с PAE

Среда выполнения архитектуры Intel 64 похожа на IA-32, но имеет несколько отличий. Регистры, отмеченные при описании архитектуры IA-32, сохранились и в Intel 64, однако были расширены до 64 разрядов. Самое существенное изменение состоит в том, что Intel 64 теперь поддерживает 64-разрядные линейные адреса. Поэтому архитектура Intel 64 допускает линейное адресное пространство объёмом до 2^64 байт. Следует учитывать, что новейшие на момент написания книги реализации этой архитектуры поддерживают не все 64 разряда, а только 48-разрядные линейные адреса. Вследствие этого виртуальные адреса в таких системах имеют каноническую форму. Это означает, что разряды 63:48 заполняются либо одними единицами, либо одними нулями в зависимости от значения разряда 47. Например, в адресе 0xfffffa800ccc0b30 разряды 63:48 установлены, поскольку установлен разряд 47; это также называют знаковым расширением.

Особенно важно обратить внимание на изменения в управлении памятью, поскольку они непосредственно влияют на экспертизу памяти. Главное отличие состоит в том, что архитектура Intel 64 поддерживает дополнительный уровень структур страничной организации, называемый таблицей страниц уровня 4 (page map level 4, PML4). Все элементы иерархии структур страничной организации имеют длину 64 бита и могут отображать виртуальные адреса на страницы размером 4 Кбайт, 2 Мбайт или 1 Гбайт. На рис. 1-7 показан пример преобразования адреса для страницы размером 4 Кбайт при 64-разрядной страничной организации IA-32e.

Рисунок 1-7. Преобразование адреса для страницы размером 4 Кбайт при 64-разрядной страничной организации IA-32e

На рис. 1-8 показаны форматы адресов структур страничной организации, используемых при 64-разрядной страничной организации IA-32e. Каждая структура страничной организации состоит из 512 элементов (2^9) и индексируется значениями, извлечёнными из следующих диапазонов 48-разрядного виртуального адреса:

• разряды 47:39 (смещение PML4E);

• разряды 38:30 (смещение PDPTE);

• разряды 29:21 (смещение PDE);

• разряды 20:12 (смещение PTE).

Если в PDPTE установлен флаг PS, элемент отображает страницу размером 1 Гбайт, при условии что такой размер поддерживается. Аналогично, если флаг PS установлен в PDE, этот PDE отображает страницу размером 2 Мбайт. Если все промежуточные элементы присутствуют, последние 12 разрядов задают байтовое смещение внутри физической страницы.

Если вас интересуют подробности того, как различные флаги элементов структур страничной организации влияют на экспертизу памяти, рекомендуем обратиться к руководству Intel и реализации адресного пространства Volatility AMD64PagedMemory.

Рисунок 1-8. Форматы адресов структур страничной организации, используемых при 64-разрядной страничной организации IA-32e

Архитектуры ПК обычно предоставляют механизм, позволяющий прервать выполнение процесса и передать управление программной процедуре, работающей в привилегированном режиме. В архитектурах IA-32 и Intel 64 такие процедуры хранятся в таблице дескрипторов прерываний (Interrupt Descriptor Table, IDT). У каждого процессора имеется собственная IDT, состоящая из 256 элементов размером 8 или 16 байт, причём первые 32 элемента зарезервированы для определённых процессором исключений и прерываний. Каждый элемент содержит адрес процедуры обслуживания прерывания (interrupt service routine, ISR), способной обработать конкретное прерывание или исключение. При возникновении прерывания или исключения его номер служит индексом в IDT, которая косвенно ссылается на сегмент в GDT, после чего ЦП вызывает соответствующий обработчик.

После большинства прерываний операционная система возобновляет выполнение с места, в котором оно было прервано. Например, попытка потока обратиться к недопустимой странице памяти вызывает ошибку страницы. В архитектурах x86 и Intel 64 ошибки страниц обрабатываются исключением с номером 0xE. Поэтому элемент IDT с индексом 0xE содержит указатель на функцию обработчика ошибок страниц операционной системы. После выполнения обработчика управление может вернуться к потоку, пытавшемуся обратиться к странице памяти. Операционные системы используют IDT также для хранения обработчиков множества других событий, включая системные вызовы, точки останова отладчика и прочие ошибки.

В этом разделе даётся общий обзор аспектов современных операционных систем, влияющих на экспертизу памяти. В частности, внимание сосредоточено на важных возможностях, общих для трёх рассматриваемых в книге операционных систем: Microsoft Windows, Linux и Mac OS X. Даже если эти темы вам уже знакомы, здесь они обсуждаются применительно к экспертизе памяти. Исследователи, хорошо знающие внутреннее устройство операционных систем, могут пропустить большую часть материала этого раздела либо использовать его как справочник по темам, рассматриваемым в последующих главах.

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

Архитектура процессоров IA-32 обеспечивает это разделение посредством четырёх уровней привилегий, обычно называемых кольцами защиты. В большинстве операционных систем режим ядра реализован в кольце 0 с наивысшими привилегиями, а пользовательский режим - в кольце 3 с наименьшими. Когда процессор выполняет код в режиме ядра, этот код имеет неограниченный доступ к лежащему в основе аппаратному обеспечению, в том числе к привилегированным инструкциям, а также к ядру и областям памяти процессов. Исключение составляют новые системы с SMEP, где выполнение пользовательских страниц в кольце 0 запрещено. Чтобы пользовательское приложение могло обратиться к критически важным компонентам операционной системы, оно переходит из пользовательского режима в режим ядра посредством строго определённого набора системных вызовов. Понимание того, какой уровень доступа получил вредоносный код, даёт ценные сведения о том, какие изменения он способен внести в систему.

Операционные системы предназначены для предоставления служб пользовательским приложениям. Пользовательское приложение запрашивает службу у ядра операционной системы с помощью системного вызова. Например, системные вызовы необходимы, когда приложению требуется работать с файлом, обмениваться данными по сети или породить другой процесс. Таким образом, системные вызовы определяют низкоуровневый API между пользовательскими приложениями и ядром операционной системы. Обратите внимание, что большинство приложений не реализуется непосредственно через системные вызовы. Вместо этого большинство операционных систем определяет набор стабильных API, каждый из которых отображается на один или несколько системных вызовов. Примером служат API, предоставляемые файлами ntdll.dll и kernel32.dll в Windows.

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

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

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

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

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

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

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

Набор управляемых ресурсов и структуры данных, используемые для их учёта, в разных операционных системах часто различаются. Например, Windows поручает контроль использования системных ресурсов диспетчеру объектов, а сведения об этом хранит в таблице дескрипторов. Дескриптор предоставляет процессу уникальный идентификатор для доступа к системным ресурсам и работы с ними. Он также применяется для управления доступом к этим ресурсам и учёта их использования. В Linux и Mac сходную роль выполняют файловые дескрипторы. Далее в книге мы расскажем, как извлекать эти сведения из таблиц дескрипторов или файловых дескрипторов и как использовать их, чтобы получить представление о деятельности процесса.

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

Операционная система предоставляет каждому процессу собственное закрытое виртуальное адресное пространство. Эта абстракция отделяет логическую память, видимую процессу, от фактической физической памяти, установленной в компьютере. Благодаря этому программы можно писать так, словно им доступно всё адресное пространство и все его диапазоны находятся в памяти. В действительности некоторые страницы адресного пространства могут отсутствовать в физической памяти. Диспетчер памяти незаметно переносит области памяти во вторичное хранилище, освобождая место в физической памяти. Во время выполнения диспетчер памяти и MMU совместно преобразуют виртуальные адреса в физические. Если поток обращается по виртуальному адресу, данные которого были перемещены во вторичное хранилище, эти данные возвращаются в физическую память, как правило посредством ошибки страницы. Это взаимодействие показано на рис. 1-9.

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

Рисунок 1-9. Несколько виртуальных адресных пространств совместно используют память и вторичное хранилище

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

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

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

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

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

Рисунок 1-10. Пример отображения разделяемой памяти между двумя процессами

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

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

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

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

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

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

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

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

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

Операционные системы используют драйверы и для реализации виртуальных, исключительно программных устройств. Например, некоторые операционные системы предоставляют представление физической памяти через программное устройство, такое как \Device\PhysicalMemory в Windows. Этот интерфейс устройства широко использовался для получения криминалистических образцов физической памяти. Следует учитывать, что память и регистры устройства также могут отображаться в память, а это способно иметь интересные последствия для получения памяти (см. главу 4).

Управляющие команды ввода-вывода (I/O Control, IOCTL) - ещё один распространённый механизм взаимодействия между пользовательским режимом и режимом ядра. Хотя системные вызовы предоставляют удобный интерфейс доступа к фиксированным службам операционной системы, пользовательским приложениям может потребоваться взаимодействие с разнообразными периферийными устройствами или другими компонентами операционной системы. IOCTL позволяют пользовательскому приложению обмениваться данными с драйвером устройства, работающим в режиме ядра. Кроме того, они дают сторонним аппаратным устройствам и драйверам механизм для определения собственных интерфейсов и функциональных возможностей.

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

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

В этой книге основное внимание уделяется базовым типам данных языка программирования C. Благодаря пригодности для системного программирования и средствам непосредственного управления выделением памяти C часто встречается при анализе находящегося в памяти состояния современных операционных систем. В табл. 2-1 приведены базовые типы данных языка C и обычно занимаемые ими объёмы памяти в 32-разрядных и 64-разрядных архитектурах.

Таблица 2-1. Обычно занимаемый объём памяти для базовых типов данных C

Базовые типы из табл. 2-1 определены стандартом C. Они широко используются в ядрах Windows, Linux и Mac OS X. Кроме того, Windows определяет на основе этих базовых типов множество собственных типов, встречающихся в заголовочных файлах и документации Windows. Некоторые из них описаны в табл. 2-2.

Таблица 2-2. Обычно занимаемый объём памяти для некоторых типов Windows

Фактический размер памяти, выделенной для базовых типов данных, определяет компилятор, и часто он зависит от аппаратной платформы. Необходимо помнить, что большинство базовых типов данных занимает несколько байтов, а порядок байтов также определяется аппаратным обеспечением, обрабатывающим данные. В следующих разделах на примерах показаны механизмы языка C, позволяющие объединять базовые типы в составные типы данных, из которых реализуются структуры данных.

Перед рассмотрением конкретных примеров структур данных познакомимся с принципами хранения на уровне абстрактных типов данных. Абстрактные типы данных предоставляют модели как самих данных, так и выполняемых над ними операций. Эти модели не зависят от конкретного языка программирования и не относятся к особенностям хранимых данных.

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

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

Простейший механизм объединения данных - одномерный массив. Это набор пар <индекс, элемент>, в котором все элементы имеют однородный тип данных. Тип хранимых элементов обычно называют типом массива. Важная особенность массива состоит в том, что его размер фиксируется при создании экземпляра и тем самым ограничивает количество хранимых элементов. Доступ к элементу массива получают, указывая индекс массива, который соответствует положению элемента в наборе. Пример одномерного массива показан на рис. 2-1.

Рисунок 2-1. Пример одномерного массива

На рис. 2-1 приведён массив, способный содержать пять элементов. Он используется для хранения символов и поэтому называется массивом символов. В соответствии с распространённым соглашением, которое неоднократно встретится в книге, первый элемент массива находится по индексу 0. Следовательно, элемент с индексом 2 имеет значение C. Если массиву присвоено имя grades, этот элемент можно также обозначить как grades[2].

Массивы применяются часто, поскольку многие языки программирования предлагают реализации, обеспечивающие чрезвычайно эффективный доступ к хранимым данным. Например, в языке C требования к объёму памяти имеют фиксированную величину, а компилятор выделяет непрерывный блок памяти для хранения элементов массива. На местоположение массива обычно ссылаются по адресу его первого элемента, который называется базовым адресом массива. Доступ к последующим элементам получают по смещению относительно базового адреса. Например, если массив хранится по базовому адресу X, а размер его элементов равен S, адрес элемента с индексом I можно вычислить по следующей формуле:

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

Поскольку массивы обеспечивают чрезвычайно эффективный доступ к данным, при анализе памяти они встречаются часто. Особенно это относится к анализу структур данных операционной системы. В частности, операционная система обычно хранит массивы указателей и других элементов фиксированного размера, к которым требуется быстро обращаться по фиксированным индексам. Например, в главе 21 вы узнаете, как Linux хранит в массиве файловые дескрипторы, связанные с процессом. Индексом массива в этом случае служит номер файлового дескриптора. Кроме того, в главе 13 рассматривается таблица Microsoft MajorFunction: массив указателей на функции, позволяющих приложению взаимодействовать с драйвером. Каждый элемент массива содержит адрес кода, то есть диспетчерской процедуры, которая выполняется для обслуживания запроса ввода-вывода. Индекс массива соответствует заранее определённому коду операции, например 0 - чтение, 1 - запись, 2 - удаление.

На рис. 2-2 показано, как указатели на функции из таблицы MajorFunction драйвера хранятся в памяти системы на базе IA-32, если первый элемент находится по адресу base_address.

Рисунок 2-2. Часть массива указателей на функции из таблицы MajorFunction драйвера

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

Разновидность массива, используемая для представления множеств, называется битовой картой, битовым вектором или битовым массивом. В этом случае индекс представляет фиксированное количество последовательных целых чисел, а элементы хранят логическое значение {1, 0}. При анализе памяти битовые карты обычно применяют для эффективного определения принадлежности конкретного объекта к множеству: например, занята или свободна область памяти, имеет объект низкий или высокий приоритет и так далее. Битовая карта хранится как массив битов, называемый картой, где каждый бит показывает, действителен ли один объект. Битовые карты позволяют представить восемь объектов одним байтом и поэтому хорошо масштабируются на большие наборы данных. Например, ядро Windows ведёт битовую карту выделенных сетевых портов. Сетевые порты представлены беззнаковым типом short, который занимает 2 байта и допускает (2^16) - 1, то есть 65 535 вариантов. Это большое количество портов представлено битовой картой длиной 65 535 бит, или приблизительно 8 Кбайт. Пример такой структуры Windows показан на рис. 2-3.

Рисунок 2-3. Пример битовой карты используемых сетевых портов Windows

На рисунке битовая карта показана как на уровне битов, так и на уровне байтов. В представлении на уровне байтов видно, что первый индекс имеет шестнадцатеричное значение 4e, которое в двоичном виде равно 1001110. Это двоичное значение означает, что порты 1, 2, 3 и 6 используются, поскольку именно в соответствующих им позициях установлены биты.

Ещё один широко применяемый механизм объединения данных - тип «запись», или «структура». В отличие от массива, все элементы которого должны иметь один тип данных, запись может состоять из разнородных элементов. Она представляет собой набор полей, каждое из которых задаётся парой <имя, элемент>. Поле также часто называют членом записи. Поскольку записи, подобно массивам, статичны, состав элементов и их порядок фиксируются при создании экземпляра записи. Доступ к элементам записи получают, указывая имя нужного члена, которое выступает ключом или индексом. Набор элементов можно объединить внутри записи и тем самым создать новый элемент. Точно так же элемент записи может сам быть массивом или записью.

На рис. 2-4 приведён пример записи о сетевом соединении, состоящей из четырёх членов, описывающих его характеристики: id, port, addr и hostname. Хотя члены могут иметь разные типы данных и соответствующие размеры, объединение их в запись позволяет хранить и упорядочивать связанные объекты.

Рисунок 2-4. Пример записи о сетевом соединении

В языке C записи реализуются с помощью структур. Структура позволяет программисту задать имя, тип и порядок членов. Как и у массива, размер структуры C известен при создании экземпляра; структуры хранятся в непрерывном блоке памяти, а доступ к элементам выполняется вычислением базового адреса и смещения. Смещения относительно начала записи зависят от размера хранимых типов данных. Компилятор определяет смещение для доступа к элементу по размеру типов данных, предшествующих ему в структуре. Например, определение структуры C для сведений о сетевом соединении с рис. 2-4 выглядело бы так:

Как видно, идентификатор Connection является именем структуры, а id, port, addr и hostname - именами её членов. Первое поле структуры называется id, занимает 2 байта и хранит уникальный идентификатор этой записи. Второе поле, port, также занимает 2 байта и хранит прослушиваемый порт удалённого компьютера. Третье поле с именем addr хранит IP-адрес удалённого компьютера в виде 4 байт двоичных данных. Четвёртое поле называется hostname и хранит имя удалённого компьютера, используя 32 байта. По сведениям о типах данных компилятор может определить правильные смещения для доступа к каждому полю: 0, 2, 4 и 8. Члены Connection и соответствующие им смещения перечислены в табл. 2-3.

Таблица 2-3. Сведения о типе структуры из примера сетевого соединения

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

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

В качестве примера изменим тип структуры из табл. 2-3, удалив поле port. Если затем заново скомпилировать программу компилятором, настроенным на выравнивание по 32-разрядным границам, в памяти обнаружатся следующие данные:

В выводе видно, что, несмотря на удаление поля port, остальные поля (id, addr, hostname) по-прежнему находятся по тем же смещениям 0, 4 и 8. Кроме того, байты 2-3, содержащие 0000 и прежде хранившие значение порта, теперь используются исключительно для заполнения.

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

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

Первая рассматриваемая реализация - строка в стиле C. Она очень похожа на реализацию массивов в языке программирования C. В частности, нас будут интересовать строки в стиле C, элементы которых имеют тип char, то есть базовый тип C, и кодируются в ASCII. Эта кодировка назначает символам американского варианта английского языка 7-разрядные числовые значения, которые почти всегда хранятся в полном байте. Главное различие между строкой в стиле C и массивом состоит в том, что строка в стиле C неявно хранит свою длину. Для этого конец строки отмечается встроенным символом завершения. В строках в стиле C таким символом служит ASCII-символ NULL со значением 0x00. Длину строки можно вычислить как количество символов между начальным адресом строки и символом завершения.

В качестве примера вернёмся к рассмотренной ранее структуре данных для хранения сетевых сведений, тип которой был приведён в табл. 2-3. Четвёртый элемент структуры, предназначенный для имени компьютера, является строкой в стиле C. На рис. 2-5 показано, как такая строка хранится в памяти при использовании кодировки ASCII. Строка начинается со смещения 8 и продолжается до символа завершения 0x00 по смещению 36. Следовательно, можно определить, что строка хранит 28 символов и символ завершения.

Рисунок 2-5. Имя компьютера в кодировке ASCII, представленное строкой в стиле C

При анализе памяти, связанной с операционной системой Microsoft Windows, вам часто будет встречаться другая реализация строк. Мы будем называть её реализацией _UNICODE_STRING, поскольку именно так называется поддерживающая её структура данных. В отличие от строк в стиле C, которые используют ASCII и хранят однобайтовые элементы, _UNICODE_STRING поддерживает кодировку Unicode, позволяя элементам занимать более одного байта, и потому способна представлять символы не только американского английского языка.

Если не указано иное, элементы _UNICODE_STRING кодируются в варианте Unicode UTF-16. Это означает, что символы хранятся как 2- или 4-байтовые значения. Ещё одно отличие от строки в стиле C состоит в том, что _UNICODE_STRING не требует завершающего символа, а хранит длину явно. Как уже отмечалось, _UNICODE_STRING реализована структурой, содержащей длину строки в байтах (Length), максимальное число байтов, которое может храниться в данной строке (MaximumLength), и указатель на начальный адрес памяти, где находятся символы (Buffer). Формат структуры данных _UNICODE_STRING приведён в табл. 2-4.

Таблица 2-4. Определение типа структуры _UNICODE_STRING в 64-разрядных версиях Windows

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

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

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

Хеш-таблицы часто применяются, когда требуется эффективная вставка и поиск данных, хранящихся в виде пар <ключ, элемент>. Например, в операционных системах хеш-таблицы используются для хранения сведений об активных процессах, сетевых соединениях, смонтированных файловых системах и кешированных файлах. Распространённая при анализе памяти реализация представляет собой хеш-таблицу из массива связных списков, также называемую хеш-таблицей с разрешением коллизий методом цепочек. Преимущество этой реализации состоит в большей динамичности структуры данных. Хеш-функция h(x) преобразует ключ в индекс массива, а коллизии, то есть значения с одинаковым ключом, хранятся в связном списке, соответствующем элементу хеш-таблицы. На рис. 2-8 приведён пример хеш-таблицы, реализованной как массив связных списков.

Рисунок 2-8. Пример хеш-таблицы с разрешением коллизий методом цепочек

В этом примере поиск определённого ключа, для которого возникла коллизия, может потребовать обхода связного списка коллизий, но в идеальном случае это намного быстрее обхода списка всех ключей. Например, если хеш-таблица основана на массиве из 16 000 индексов и содержит 64 000 элементов, оптимальная хеш-функция помещает по 4 элемента в каждый индекс массива. Тогда при поиске хешированный ключ указывает на список всего из 4 элементов, вместо того чтобы при каждом обращении потенциально обходить 64 000 элементов.

Linux использует хеш-таблицу с цепочками, известную как хеш-таблица идентификаторов процессов, для сопоставления идентификаторов процессов со структурами процессов. В главе 21 объясняется, как инструменты экспертизы памяти используют эту хеш-таблицу для поиска активных процессов.

Каждый основной выпуск Volatility распространяется в нескольких форматах, включая автономный исполняемый файл Windows, установщик модуля Python для Windows и пакеты исходного кода в архивах ZIP и GZIP/TAR. Пользователи обычно выбирают формат с учётом основной операционной системы, в которой планируют запускать Volatility, и предполагаемых способов работы с платформой: только анализировать дампы памяти либо также разрабатывать решения и интегрировать их с внешними инструментами. Форматы описаны в следующих разделах.

Исполняемый файл - самый быстрый и простой способ начать работу с Volatility на аналитической машине Windows. Он включает интерпретатор Python 2.7 и все зависимости Volatility. Установка не требуется: достаточно запустить исполняемый файл из командной строки, как показано в следующем примере:

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

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

По умолчанию исходные файлы копируются в C:\PythonXX\Lib\site-packages\volatility, где XX - версия Python, а основной сценарий vol.py - в C:\PythonXX\Scripts. После этого платформу можно использовать следующим образом:

Это наиболее универсальный формат: его можно использовать в Windows, Linux или Mac при наличии работающего интерпретатора Python 2.7 и необходимых зависимостей. Однако важно помнить, что после извлечения содержимого пакета код можно установить двумя способами. У каждого есть свои преимущества:

• Способ 1 (с помощью setup.py). Извлеките архив и выполните команду python setup.py install. Для завершения установки могут потребоваться права администратора. Этот способ копирует файлы в правильные места на диске, чтобы пространство имён Volatility было доступно другим сценариям Python. Если вы не собираетесь импортировать Volatility как библиотеку в проекты разработки, рассмотрите вместо этого способ 2. Недостаток первого способа состоит в сложности обновления и удаления.

• Способ 2 (без setup.py). Извлеките архив в выбранный каталог. Когда потребуется Volatility, просто выполните python /PATH/TO/vol.py. Этот способ часто считается более чистым, поскольку файлы не перемещаются за пределы выбранного каталога, а права администратора не нужны. Кроме того, можно без труда одновременно иметь несколько версий Volatility, храня их в отдельных каталогах. Для удаления достаточно удалить каталог.

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

В последних версиях Mac средства управления исходным кодом по умолчанию встроены в операционную систему, а в большинстве дистрибутивов Linux доступны через диспетчеры пакетов. Например, в Debian или Ubuntu можно ввести apt-get install git, а в CentOS или Red Hat - yum install git-core. Для Windows можно загрузить mysysGit (msysgit.github.io) или воспользоваться приложением GitHub (windows.github.com). Установив инструменты, можно получить рабочую копию исходного кода Volatility. Ниже приведён пример клонирования репозитория в Linux или Mac:

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

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

• Distorm3. Мощная библиотека дизассемблирования x86/AMD64 (code.google.com). От неё зависят плагины Volatility apihooks, callbacks, impscan, volshell, linux_volshell, mac_volshell и linux_check_syscall.

• Yara. Инструмент обнаружения и классификации вредоносных программ (code.google.com). От него зависят плагины Volatility yarascan, mac_yarascan и linux_yarascan.

• PyCrypto. Набор криптографических средств Python (dlitz.net). От этой библиотеки зависят плагины Volatility lsadump и hashdump.

• PIL. Библиотека изображений Python (pythonware.com). От неё зависит плагин screenshot.

• OpenPyxl. Библиотека Python для чтения и записи файлов Excel (bitbucket.org). От неё зависит плагин timeliner при использовании режима вывода xlsx.

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

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

Наложения позволяют исправлять, или накладывать заплаты на, автоматически созданные определения структур. Это важно для экспертизы памяти, поскольку код операционной системы часто широко использует в структурах указатели void (void *). Указатель void указывает на данные, тип которых во время выделения неизвестен или может быть произвольным. К сожалению, отладочные символы не содержат достаточно сведений для автоматического определения типов, а при анализе может потребоваться переходить по таким указателям, то есть разыменовывать их. Определив тип конкретного члена структуры, обычно путём обратной разработки или проб и ошибок, можно применить наложение, которое переопределит автоматически созданное определение VType.

В предыдущем разделе использовалась структура process с членом void * ptv. Если известно, что ptv в действительности является указателем на другую структуру process, можно создать следующее наложение:

Обратите внимание на два значения None, расположенные на местах, где обычно хранятся размер структуры и смещения членов. None указывает, что соответствующие части определения не меняются. Это наложение изменяет только тип ptv с void * на process *. После применения такого наложения при обращении к ptv в плагинах Volatility платформа будет знать, что это ссылка на структуру process.

Наложения не только уточняют определения структур, но и полезны для удобства и единообразия. Например, Windows хранит многие временные метки в структуре _LARGE_INTEGER. Она содержит два 32-разрядных целых числа, младшую и старшую части, которые объединяются в 64-разрядное значение временной метки. Значение 1325230153 после преобразования означает 2011-12-30 07:29:13 UTC+0000. Многим плагинам Volatility требуется выводить временные метки в таком удобочитаемом виде. Поэтому имеет смысл глобально заменять в структурах тип _LARGE_INTEGER, используемый для хранения временных меток, специальным типом, который выполняет преобразование автоматически.

Объект Volatility, далее просто объект, - это экземпляр структуры, существующий по определённому адресу в адресном пространстве (address space, AS). С адресными пространствами мы познакомимся позднее, а пока считайте AS интерфейсом к файлу дампа памяти, похожим на файловый дескриптор. Например, объект можно создать, разместив экземпляр структуры _EPROCESS по адресу 0x80dc1a70 дампа памяти. После создания объекта, обычно вызовом API Volatility obj.Object(), можно обращаться к любому члену лежащей в его основе структуры, выводить значения, выполнять основанные на них вычисления и так далее.

Класс объекта позволяет расширять функциональные возможности объекта. Иными словами, к объекту можно присоединить методы или свойства, которые затем станут доступны всем его экземплярам. Это превосходный способ совместно использовать код в нескольких плагинах, который также упрощает применение API платформы. Например, если разные плагины создают объекты _EPROCESS и всем им часто требуется по нескольким признакам определять подозрительность процесса, такую логику можно добавить с помощью класса объекта. Простой пример приведён ниже:

Показанный метод проверяет несколько характеристик процесса: совпадает ли его имя с fakeav.exe, равен ли PID значению 0x31337 и содержит ли полный путь к процессу на диске подстроку temp. Хотя это далеко не полный аудит процесса, а с другими способами анализа процессов вы познакомитесь далее в книге, пример по крайней мере демонстрирует общую идею присоединения API к объектам. Везде, где в плагинах Volatility используется объект процесса, проверку можно вызвать как process.is_suspicious().

Профиль - это набор VTypes, наложений и классов объектов для конкретной версии операционной системы и аппаратной архитектуры: x86, x64 или ARM. Помимо этих компонентов профиль включает следующее:

• Метаданные. Такие сведения, как имя операционной системы, например windows, mac или linux, версия ядра и номера сборок.

• Сведения о системных вызовах. Индексы и имена системных вызовов.

• Постоянные значения. Глобальные переменные, которые в некоторых операционных системах находятся по жёстко заданным адресам.

• Машинные типы. Низкоуровневые типы машинных языков, обычно C, включая размеры целых чисел, типов long и так далее.

• Карта системы. Адреса критически важных глобальных переменных и функций, только для Linux и Mac.

Каждый профиль имеет уникальное имя, обычно образованное от имени операционной системы, версии, пакета обновления и архитектуры. Например, Win7SP1x64 - имя профиля 64-разрядной Windows 7 Service Pack 1. Аналогично, Win2012SP0x64 соответствует 64-разрядной Windows Server 2012. В следующем разделе «Использование Volatility» объясняется, как получить полный список имён профилей, поддерживаемых установленной версией Volatility.

Помимо Windows, Volatility поддерживает дампы памяти Linux, Mac и Android. Дополнительные сведения о создании и подключении профилей этих систем приведены в части III «Экспертиза памяти Linux» и части IV «Экспертиза памяти Mac».

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

Для разработки аналитического плагина создаётся класс Python, наследующий commands.Command и переопределяющий несколько базовых методов. В частности, две основные настраиваемые функции - calculate, где выполняется большая часть работы плагина, и render_text, где результаты форматируются для текстового вывода. Иными словами, код calculate отвечает за поиск и анализ объектов в памяти. Результаты вычислений передаются render_text для отображения в терминале. Следующий код представляет минимальный аналитический плагин, который просто выводит имена всех процессов системы. Имя плагина образуется от имени класса ExamplePlugin.

Чтобы выполнить плагин, переместите содержащий этот код файл Python в каталог volatility/plugins или любой его подкаталог. Система плагинов автоматически обнаружит и зарегистрирует его.

Основная платформа Volatility включает более 200 аналитических плагинов. Ради краткости мы не станем перечислять их здесь, но важно хотя бы бегло просмотреть названия и описания, чтобы получить общее представление о возможностях, которые стоит начать изучать, когда вы приступите к делу. В любой момент можно также вывести список плагинов, доступных в вашей версии Volatility, командой vol.py --info.

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

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

Пример:

При использовании автономного исполняемого файла Windows синтаксис выглядит так:

У показанной базовой команды есть несколько исключений: вызов Volatility с -h/--help для просмотра глобальных параметров, с --info для просмотра всех доступных AS, плагинов и профилей, а также ситуация, когда нужный профиль ещё неизвестен.

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

Чтобы открыть главное меню справки, передайте в командной строке -h/--help. Будут показаны глобальные параметры, включая значения по умолчанию, если они применимы, и список плагинов, доступных для указанного в данный момент профиля. Если профиль не задан, используется профиль по умолчанию WinXPSP2x86, поэтому вы увидите только плагины, допустимые для этой операционной системы и архитектуры. Например, в списке не будет плагинов Linux или плагинов Windows, работающих только в Vista. Ниже приведён пример:

Плагины Volatility также могут регистрировать собственные параметры. Чтобы просмотреть их, передайте имя плагина вместе с -h/--help. Следующая команда показывает параметры плагина handles:

Один из наиболее часто используемых параметров глобального меню справки - --profile. Он сообщает Volatility, из системы какого типа получен дамп памяти, чтобы платформа могла выбрать правильные структуры данных, алгоритмы и символы. Внутри задан профиль по умолчанию WinXPSP2x86, поэтому при анализе дампа памяти 32-разрядной Windows XP SP2 параметр --profile можно вообще не передавать. Во всех остальных случаях необходимо указать правильное имя профиля.

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

Можно заметить, что предлагается несколько профилей: обнаруженные операционные системы имеют много общих особенностей и поэтому могут выглядеть очень похоже. Логика, по которой imageinfo подбирает профили, в действительности основана на функциях второго плагина, kdbgscan. Его имя подсказывает способ подбора возможных профилей: плагин находит и анализирует характеристики блока данных отладчика ядра (_KDDEBUGGER_DATA64).

Структура данных отладчика обычно располагается внутри модуля ядра NT (nt!KdDebuggerDataBlock). Она содержит строку сборки, например 3790.srv03_sp2_rtm.070216-1710, числовые значения основного и дополнительного номеров сборки и уровень пакета обновления целевой операционной системы. Ниже приведён пример вывода этого плагина:

Как видно, все признаки указывают, что файл memory.raw получен из 64-разрядной Windows 7 Service Pack 0. Поэтому при запуске других плагинов теперь можно передавать --profile=Win7SP0x64. Поскольку блок данных отладчика содержит также указатели на начало списков активных процессов и загруженных модулей, плагин kdbgscan сообщает количество элементов в каждом списке. В данном случае это 32 процесса и 133 модуля. Эти значения помогают отличать случаи обнаружения «устаревшего» блока данных отладчика, которые рассматриваются далее в разделе о проблемах.

Volatility сканирует память в поисках _KDDEBUGGER_DATA64, проверяя встроенные в структуру постоянные значения, в том числе жёстко заданную 4-байтовую сигнатуру KDBG. Эти сигнатуры не нужны для правильной работы операционной системы, поэтому вредоносная программа в ядре может перезаписать их, пытаясь сбить с толку инструменты, которые полагаются на поиск сигнатуры. Другие средства экспертизы памяти обращаются к дате и времени компиляции в заголовке PE модуля ядра NT, но эти сведения также не являются необходимыми и могут быть злонамеренно изменены. Именно поэтому Volatility предоставляет параметр --profile: если автоматическое определение ОС не сработает из-за намеренных или случайных изменений, профиль можно задать вручную.

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

Обратите внимание, что в следующей команде kdbgscan находит две структуры:

• недопустимую, с 0 процессов и 0 модулей, по адресу 0xf80001172cb0;

• допустимую, с 37 процессами и 116 модулями, по адресу 0xf80001175cf0.

Как уже отмечалось, многие плагины Volatility полагаются на обнаружение блока данных отладчика с последующим обходом списков активных процессов и загруженных модулей. По умолчанию эти плагины принимают первую найденную сканированием структуру отладчика, однако, как мы только что убедились, первый вариант не всегда лучший. В таких случаях после ручной проверки более точного значения с помощью kdbgscan можно задать глобальный параметр --kdbg=0xf80001175cf0. Это не только гарантирует использование правильного значения Volatility, но и экономит время при выполнении нескольких команд, поскольку повторное сканирование больше не требуется.

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

В аналитической системе Linux или Mac параметры можно задать, экспортировав их в командной оболочке, как показано ниже:

При задании параметров таким способом следует учитывать несколько важных моментов:

• Соглашение об именовании. Переменная среды должна называться как исходный параметр, но с префиксом VOLATILITY. Например, вместо параметра командной строки --profile используется эквивалентная переменная среды VOLATILITY_PROFILE.

• Местоположение вместо имени файла. При задании пути к файлу дампа памяти используйте VOLATILITY_LOCATION и обязательно добавляйте к пути префикс file:///, даже если анализ выполняется на машине Windows.

• Сохранение значений. Заданные таким способом переменные среды действуют лишь пока открыта текущая командная оболочка. После её закрытия или при открытии другой оболочки переменные придётся задать заново. Можно также добавить их в файл ~/.bashrc или /etc/profile, путь может различаться в зависимости от ОС, чтобы они инициализировались при каждом запуске оболочки.

Использовать файлы конфигурации столь же просто. По умолчанию Volatility ищет файл .volatilityrc в текущем каталоге или ~/.volatilityrc в домашнем каталоге пользователя, либо по пути, заданному параметром --conf-file. В конфигурационном файле применяется стандартный формат INI. Обязательно создайте раздел DEFAULT, после которого укажите нужные параметры. В этом случае префикс VOLATILITY к параметрам не добавляется.

Задав параметры любым из описанных в этом разделе способов, можно запускать плагины Volatility командами вроде python vol.py pslist, не вводя остальные параметры.

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

Первая команда использует обычное перенаправление терминала, а вторая - параметр Volatility --output-file. Обе создают текстовый файл с результатами плагина pslist. Мы упоминаем оба способа потому, что это подводит нас к выводу в формате, отличном от текстового. Формат можно выбирать отдельно для каждого плагина, если тот поддерживает другие режимы вывода. Например, плагин mftparser выводит результаты в популярном формате body (wiki.sleuthkit.org), если вызвать его с параметром --output=body. Другой пример - плагин impscan, который с параметром --output=idc создаёт вывод на языке сценариев IDA Pro. В будущем плагины могут получить общую поддержку вывода данных в JSON, XML, CSV, HTML и других форматах.

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

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

Атомарной называется операция, которая для остальной системы выглядит мгновенно завершившейся, без прерывания со стороны параллельных процессов. Получение памяти не является атомарной операцией, поскольку содержимое RAM постоянно меняется даже в простаивающей системе, а во время самого получения особенно. Дэн Фармер и Витсе Венема писали: «Память [...] может изменяться настолько быстро, что точно и своевременно записать даже основную массу этих колебаний невозможно без серьёзного нарушения работы типичной компьютерной системы» (см. Forensic Discovery).

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

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

Физическая память - это схема логической адресации, позволяющая единообразно обращаться к разрозненным ресурсам материнской платы. На компьютерах x86/x64 микропрограмма BIOS предоставляет ОС карту физической памяти, где отдельные области отмечены как зарезервированные для микропрограммы, шин ISA или PCI либо различных устройств материнской платы. Далее они называются областями памяти устройств.

На рис. 4-2 приведена упрощённая схема расположения физической памяти с учётом «дыр», возникающих из-за областей памяти устройств. В 32-разрядных системах с объёмом памяти менее 4 Гбайт эти «дыры» приводят к тому, что общий объём памяти, доступный ОС, немного меньше заявленной ёмкости микросхем RAM. Это явление известно как «эффективное ограничение памяти 32-разрядного клиента». Дополнительные сведения приведены в статье Марка Руссиновича Pushing the Limits of Windows: Physical Memory (blogs.technet.com). Обратите внимание, что функция MmGetPhysicalMemoryRanges исключает диапазоны физической памяти, зарезервированные устройствами. Иными словами, этот API позволяет обходить области памяти устройств.

Непреднамеренное чтение одной из зарезервированных областей может быть опасно. В зависимости от характера устройства чтение по физическому адресу внутри области способно либо получить хранящиеся там данные, либо изменить состояние устройства. Например, существуют физические адреса, отображённые на регистры устройств, состояние которых меняется при каждом чтении соответствующей физической ячейки. Такое изменение может запутать драйверы устройств или микропрограмму, зависящие от значений этих регистров, и в конечном счёте привести к зависанию системы. Особенно часто система зависает при чтении адресов, занятых набором микросхем видеоадаптера, высокоточным таймером событий (High Precision Event Timer, HPET) или малоизвестными устаревшими устройствами PCI. Дополнительную сложность создаёт то, что большинство таких устройств не рассчитано на одновременный доступ более чем одного процессора.

Рисунок 4-2. В расположении физической памяти совместимой системы x86/x64 присутствуют различные «дыры», обусловленные областями памяти устройств

Несмотря на риск получения областей памяти устройств, в них могут находиться доказательства высокой криминалистической ценности. Например, эти области способны содержать таблицу векторов прерываний реального режима (interrupt vector table, IVT) с артефактами, оставленными руткитами микропрограммы. Можно также обнаружить свидетельства руткитов BIOS, внедряющих код в верхнюю часть памяти реального режима. Кроме того, область CMOS можно использовать для изменения порядка загрузки, а регистры косвенного доступа IOAPIC - для перенаправления прерываний. Из программных средств получения памяти, рассматриваемых далее в главе, только KnTDD компании GMG Systems способно получать эти области с приемлемой надёжностью и точностью.

Для повышения производительности современные процессоры оснащены одним или несколькими внутренними кешами памяти. В элементе таблицы страниц можно задать разные атрибуты кеширования памяти: отсутствие кеширования, кеширование или комбинированную запись. Эти атрибуты определяют способ доступа процессора к странице физической памяти. Процессоры имеют документированное конструктивное ограничение: они не рассчитаны на одновременное отображение одного физического адреса с несколькими атрибутами кеширования. Это способно вызвать неопределённое поведение процессора, включая, помимо прочего, повреждение буфера ассоциативной трансляции (TLB) и данных по указанному адресу памяти. Поэтому плохо написанное средство получения легко может испортить ту самую память, которую получает. См. Intel 64 and IA-32 Architectures Developer’s Manual, том 3A, раздел 11.12.4.

Согласованность кешей - одна из основных причин, по которым Microsoft предостерегает разработчиков драйверов Windows от отображения физических страниц, если драйвер сам не выделил память через API, гарантирующий, что никакой другой компонент системы не отобразил тот же диапазон памяти с иным типом кеширования (msdn.microsoft.com). Распространено заблуждение, будто средства получения защищены от конфликтов кеширования, если отображают физические страницы из \Device\PhysicalMemory с помощью ZwMapViewOfSection. Для некоторых версий Windows это, возможно, верно, но правило применимо не ко всем выпускам и не предотвращает конфликты кеширования при отображении страниц памяти, которые в данный момент не выделены.

В Windows 2000 API позволял указывать конфликтующие атрибуты кеширования (см. ntsecurity.nu). Начиная с Windows XP API сравнивает запрошенные и существующие атрибуты и при несовпадении безопасно отказывает, возвращая ошибку STATUS_CONFLICTING_ADDRESSES. Однако начиная с Windows 7 и 2008 R2 эта ошибка больше не создаётся. Современные версии Windows молча подставляют атрибуты кеширования из базы данных PFN, даже если целевая страница в данный момент не выделена, а значения соответствующего элемента базы PFN уже недействительны.

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

В этом случае память сохраняется на внешний накопитель USB, eSATA или FireWire, подключённый к целевой системе. Никогда не рекомендуется сохранять дамп памяти на локальные диски целевой системы, например в раздел C:, поскольку при этом будет перезаписан значительный объём доказательств, способных иметь отношение к делу, включая неиспользуемое пространство. Из-за объёма RAM современных компьютеров убедитесь, что целевой накопитель отформатирован в NTFS или другую высокопроизводительную файловую систему. Помните также, что вредоносные программы часто распространяются заражением внешних носителей. Дополнительные рекомендации по локальному получению:

• никогда не подключайте один и тот же съёмный носитель более чем к одному потенциально заражённому компьютеру, чтобы при сборе доказательств не распространять заражение;

• не подключайте потенциально заражённый съёмный носитель непосредственно к криминалистической рабочей станции. Сначала подключите его к промежуточной «расходной» системе и исследуйте. Затем скопируйте доказательства на криминалистическую рабочую станцию через небольшую изолированную сеть, например через концентратор или неуправляемый коммутатор;

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

В простейшем сценарии удалённого получения инструменты обычно передают по сети на целевую машину с помощью PsExec (technet.microsoft.com) либо копируют в общий ресурс C$ или ADMIN$ по протоколу Server Message Block (SMB). Затем на целевой системе можно запланировать задачу или установить службу, которая запустит инструменты и отправит содержимое физической памяти обратно через слушатель netcat или другой протокол обратного подключения. Основные проблемы этого способа - раскрытие учётных данных администратора и передача содержимого RAM целевой системы по сети открытым текстом. Основная память компьютера содержит много конфиденциальных сведений, которые могут быть раскрыты при получении открытым текстом через открытую сеть.

В доменной или корпоративной среде учётные данные администратора домена дают удобный доступ к целевой системе. Однако, если целевой компьютер уже скомпрометирован, злоумышленники могут извлечь из памяти созданные токены проверки подлинности и применить их в атаках Pass the Hash (microsoft.com). Лучше создать временную учётную запись администратора, которой разрешён доступ только к целевой системе. После завершения получения отключите её и отслеживайте последующие попытки использования этих учётных данных. Можно также заблокировать на межсетевом экране или маршрутизаторе соединения с целевой машины, кроме соединений с системами, участвующими в удалённом получении. Это помешает вредоносной программе или злоумышленникам воспользоваться похищенными учётными данными для дальнейшего проникновения в сеть.

Получение в общий сетевой ресурс следует использовать только в крайнем случае, хотя иногда оно необходимо. Начиная с SMB 3.0 в Windows Server 2012 поддерживается сквозное шифрование. Кроме того, некоторые инструменты, например CryptCat, KnTDD и F-Response Enterprise, поддерживают получение доказательств по сети с применением SSL/TLS. Чтобы сократить время передачи и требуемую пропускную способность, доказательства можно предварительно сжать. Не забудьте вычислить хеши целостности до и после передачи, чтобы убедиться, что доказательства не изменились при пересылке.

Опрос во время выполнения позволяет быстро обследовать всю организацию и проверить конкретные индикаторы в физической памяти вместо получения полного дампа памяти каждой системы. Обычно такой анализ выполняется автоматически. Различные коммерческие комплексы, включая F-Response, AccessData Enterprise и EnCase Enterprise, предоставляют возможности корпоративного уровня для опроса физической памяти.

Из-за упомянутых ранее ограничений аппаратное получение подробно в этой книге не рассматривается. Тем не менее стоит отметить, что Volatility поддерживает получение и опрос памяти через FireWire. Потребуются библиотека libforensic1394 (freddie.witherden.org), стек JuJu FireWire и специальный вызов Volatility. Обратите внимание на параметр -l вместо -f:

<devno> - номер устройства, обычно 0, если подключено только одно устройство FireWire. Для получения памяти используйте плагин imagecopy, а для опроса работающей системы - любой другой аналитический плагин, но помните о рассмотренном ранее ограничении в 4 Гбайт.

Ещё один вариант аппаратного анализа памяти - разблокировка рабочих станций. Например, инструмент Inception Карстена Мортмана-Мё (breaknenter.org) находит и исправляет инструкции, позволяя входить в защищённые паролем компьютеры Windows, Linux и Mac OS X даже без учётных данных. Однако, как указано на сайте инструмента, если нужные инструкции не найдены в нижних 4 Гбайт памяти, надёжная работа не гарантируется.

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

• способ, используемый большинством, если не всеми, коммерческими инструментами, вызывает API операционной системы для создания элемента таблицы страниц. Обычно применяются функции ZwMapViewOfSection для \Device\PhysicalMemory, MmMapIoSpace, MmMapLockedPagesSpecifyCache и MmMapMemoryDumpMdl;

• второй возможный способ вызывает другие API ОС, чтобы выделить пустой элемент таблицы страниц, а затем вручную кодирует в нём нужную физическую страницу.

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

Средства получения различаются и способом выбора физических адресов, которые включаются в захват или исключаются из него. Некоторые начинают с физического адреса 0 и увеличивают счётчик на номинальный размер страницы, пока не достигнут ожидаемого, что само по себе является ещё одной переменной, предела физической памяти. Большинство, если не все, инструменты пропускает области памяти устройств, показанные на рис. 4-2. Эта мера делает получение устойчивее, но исключает значительный объём доказательств из памяти, где могут находиться артефакты сложных руткитов. С другой стороны, некоторые приложения позволяют получать все физические адреса от страницы 0 до предполагаемого конца физического адресного пространства. Это рискованнее, особенно в системах с памятью более 4 Гбайт, но позволяет получить более полное представление памяти целевой системы. В идеале следует использовать инструмент, способный безопасно получать представляющие интерес данные из областей памяти устройств. Например, если средство получения умеет определить устройство, занимающее конкретную область физической памяти, оно может применить подходящий этому устройству метод.

В отличие от средств создания образов дисков, для инструментов получения памяти не разработаны формальные спецификации и не проводились оценки. Фактически это по-прежнему открытая область исследований и предмет горячих споров. Одна из основных трудностей оценки средств получения памяти состоит в том, что они могут работать по-разному в зависимости от версии и конфигурации ОС и установленного аппаратного обеспечения. Следует также подчеркнуть, что платформы виртуализации зачастую гораздо предсказуемее и однороднее реального оборудования, поэтому их результаты могут плохо показывать поведение инструмента в неоднородном мире физических машин. Тем не менее ведутся многообещающие исследования. Например, в 2013 году Штефан Фёмель и Йоханнес Штюттген опубликовали статью, где представили платформу оценки программного обеспечения для криминалистического получения памяти An Evaluation Platform for Forensic Memory Acquisition Software (dfrws.org). Кроме того, GMG Systems, Inc. предлагает клиентам методику проверки точности и полноты своих средств получения памяти (MAUT).

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

Не забывайте: если инструмент не вызвал сбой или зависание целевой машины, это ещё не означает, что он создал точный и полный «образ» памяти. В системах Microsoft Windows с помощью средства проверки драйверов Microsoft (support.microsoft.com) можно определить, проявил ли поставщик разумную осторожность при разработке инструмента. Помимо этого, лучшая защита - проверять средство на системах, максимально похожих на те, где оно будет использоваться на практике. К сожалению, из-за множества сочетаний аппаратного и программного обеспечения это не всегда возможно.

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

• GMG Systems, Inc., KnTTools. К основным достоинствам относятся модули удалённого развёртывания, криптографическая проверка целостности, сбор доказательств по SSL, сжатие вывода, необязательное ограничение пропускной способности, автоматический сбор данных о текущем состоянии пользователя для перекрёстной проверки, захват файла подкачки, надёжное журналирование ошибок, строгие испытания и документация. Инструмент также получает ROM, EEPROM и NVRAM из BIOS и память периферийных устройств: PCI, видеоадаптера и сетевого адаптера.

• F-Response. Комплекс продуктов F-Response впервые предоставил революционную для экспертизы памяти возможность: удалённый опрос работающих систем через соединение iSCSI только для чтения. F-Response показывает физическую память и жёсткие диски целевой системы независимо от поставщика и ОС. Поэтому обращаться к ним можно с аналитических станций Windows, Mac OS X или Linux и обрабатывать любыми инструментами.

• Mandiant Memoryze. Инструмент легко запускается со съёмного носителя и поддерживает получение из большинства распространённых версий Microsoft Windows. XML-вывод Memoryze можно импортировать в Mandiant Redline для графического анализа объектов физической памяти.

• HBGary FastDump. По заявлению поставщика, инструмент оставляет минимально возможный след, умеет получать файлы подкачки и физическую память в единый выходной файл HPAK и зондировать память процессов. Последняя потенциально инвазивная операция принудительно возвращает выгруженные страницы в RAM перед получением.

• MoonSols Windows Memory Toolkit. Семейство MWMT включает win32dd, win64dd и новейшую версию DumpIt - утилиту, объединяющую 32- и 64-разрядные средства сохранения дампа памяти в исполняемом файле, для работы которого достаточно одного щелчка. Дальнейшее взаимодействие не требуется. При необходимости доступны расширенные параметры: выбор формата вывода, включение шифрования RC4 и запуск по сценарию на нескольких машинах.

• AccessData FTK Imager. Инструмент поддерживает получение многих видов данных, включая RAM. AccessData продаёт также предварительно настроенный USB-набор для реагирования в работающей системе, который помимо физической памяти получает журналы чатов, сетевые соединения и другие данные.

• EnCase/WinEn. Средство получения Guidance Software сохраняет дамп памяти в сжатом виде и записывает метаданные в заголовки, например название дела и имя аналитика. В версии EnCase Enterprise сходный код работает в агенте для удалённого опроса работающих систем (см. volatility-labs.blogspot.com).

• Belkasoft Live RAM Capturer. Утилита заявляет способность сохранять дамп памяти даже при наличии агрессивных механизмов противодействия отладке и созданию дампов. Она поддерживает все основные 32- и 64-разрядные версии Windows и запускается с USB-накопителя.

• ATC-NY Windows Memory Reader. Инструмент сохраняет память в необработанном формате или формате дампа сбоя и предлагает несколько вариантов хеширования для проверки целостности. При работе из UNIX-подобной среды, например MinGW или Cygwin, вывод легко отправить удалённому слушателю netcat или через зашифрованный туннель SSH.

• Winpmem. Единственное средство получения памяти Windows с открытым исходным кодом. Оно умеет создавать файлы в необработанном формате или формате дампа сбоя, позволяет выбирать разные способы получения, включая крайне экспериментальное переназначение PTE, и предоставляет физическую память через устройство для оперативного анализа локальной системы.

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

Volatility Framework предоставляет также несколько плагинов, перечисленных в табл. 4-1, для исследования метаданных многих распространённых форматов файлов.

Таблица 4-1. Плагины Volatility для метаданных форматов файлов

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

Формат файла дампа сбоя Windows был создан для отладки. Дампы сбоев начинаются со структуры _DMP_HEADER или _DMP_HEADER64, как показано в следующем коде. Член Signature содержит соответственно PAGEDUMP или PAGEDU64.

Заголовок определяет старший и младший номера версии ОС, DTB ядра (DirectoryTableBase), адреса голов списков активных процессов и загруженных модулей ядра, а также сведения о сериях физической памяти. В нём также указаны коды проверки ошибок, по которым отладчик определяет причину сбоя.

Ниже перечислены способы создания дампа сбоя. Обратите внимание: не все они подходят для целей криминалистики.

• Синие экраны. Систему можно настроить так, чтобы при появлении синего экрана смерти (Blue Screen of Death, BSoD) она создавала дамп сбоя (см. KB 969028). Для тестирования можно использовать NotMyFault от Sysinternals (download.sysinternals.com), в состав которого входит намеренно ошибочный драйвер, вызывающий BSoD. Разумеется, этот способ жёстко выключает систему, что может привести к потере других данных.

• CrashOnScrollControl. Некоторые клавиатуры PS/2 и USB поддерживают специальные последовательности клавиш, создающие дамп сбоя (см. KB 244139). На серверных системах без подключённых клавиатур можно использовать немаскируемые прерывания (Non-Maskable Interrupts; см. KB 927069). Однако эти способы обычно требуют предварительной настройки реестра и BIOS.

• Отладчики. Если вы подключены к целевой системе с помощью удалённого отладчика ядра (WinDBG), можно применить команды .crash или .dump. Это удобно при отладке, но почти никогда не применимо в криминалистическом сценарии. При локальной отладке можно также использовать LiveKD (download.sysinternals.com), однако обычно для этого требуется заранее установить специальное программное обеспечение в целевой системе.

Только что описанные способы опираются на один и тот же механизм ядра для создания дампов сбоев. Поэтому им свойственны несколько одинаковых недостатков. Обычно в такие дампы не включаются области памяти устройств и первая физическая страница, которая может содержать копию главной загрузочной записи (Master Boot Record, MBR) с диска и пароли предзагрузочной аутентификации. Кроме того, вредоносная программа может воспрепятствовать их созданию, зарегистрировав обратный вызов проверки ошибок (см. раздел "Вредоносные обратные вызовы" в главе 13) либо отключив доступ к отладчику ядра. Некоторые системы из-за размера могут вообще оказаться неспособными создавать полные дампы сбоев (см. media.blackhat.com).

Некоторые криминалистические средства получения памяти, например MoonSols MWMT, позволяют создавать файл дампа сбоя. В таких случаях инструмент самостоятельно формирует заголовок дампа сбоя, а затем записывает серии физической памяти в выходной файл. Иными словами, он создаёт файл дампа сбоя, совместимый с отладчиком WinDBG (и, следовательно, с Volatility), но не использует тот же механизм ядра, что и остальные методы. Поэтому удаётся избежать многих недостатков, включая отсутствие первой страницы, противодействие посредством обратных вызовов и ограничения по размеру. Volatility и KnTDD также умеют преобразовывать необработанные дампы памяти в дампы сбоев, как будет показано далее в этой главе.

Файл гибернации (hiberfil.sys) содержит сжатую копию памяти, которую система сохраняет на диск при переходе в режим гибернации. В 2008 году Матьё Сюиш (MoonSols) разработал Sandman - первый инструмент криминалистического анализа таких файлов. О его первоначальном исследовании можно прочитать в работе Windows Hibernation File For Fun 'N' Profit (sebug.net).

Файлы гибернации состоят из стандартного заголовка (PO_MEMORY_IMAGE), набора контекстов ядра и регистров, таких как CR3, а также нескольких массивов сжатых блоков данных. Использовался базовый формат сжатия Xpress (msdn.microsoft.com). Однако начиная с Windows 8 и Server 2012 Microsoft стала применять алгоритм Xpress совместно с кодированием Хаффмана и LZ. Ниже приведён пример заголовка файла гибернации:

Член Signature обычно содержит hibr, HIBR, wake или WAKE. Однако в некоторых случаях весь заголовок PO_MEMORY_IMAGE обнуляется (это происходит при возобновлении работы системы), из-за чего большинство инструментов не может проанализировать файл гибернации. В таких случаях Volatility применяет алгоритм полного перебора для поиска необходимых данных. Анализируя файл гибернации с помощью Volatility, помните, что при каждом запуске команды требуется распаковывать определённые сегменты. Чтобы в целом сэкономить время, рекомендуем один раз распаковать весь дамп памяти с помощью команды imagecopy, описанной далее. Распаковка преобразует файл гибернации в необработанный дамп памяти, который можно анализировать без распаковки на лету.

Как объясняется в статье Microsoft KB 920730, чтобы создать файл гибернации, сначала включите гибернацию в ядре (powercfg.exe /hibernate on), а затем выполните команду shutdown /h. В зависимости от версии ОС это можно сделать и через меню Start (Start > Hibernate либо Start > Shutdown > Hibernate). Однако в большинстве криминалистических случаев вам поступит ноутбук, уже переведённый в режим гибернации, либо криминалистический образ диска системы, на котором имеется файл гибернации. Тогда потребуется скопировать файл C:\hiberfil.sys, подключив диск к машине анализа (либо воспользовавшись Live CD/DVD).

Память, полученная с помощью EnCase, хранится в формате Expert Witness Format (EWF). Из-за популярности EnCase в криминалистических расследованиях этот формат встречается очень часто. Поэтому следует знать следующие способы анализа дампов памяти EWF:

• EWFAddressSpace. В Volatility входит адресное пространство, способное работать с файлами EWF, однако для него необходимо установить libewf (code.google.com). На момент написания книги libewf заявляла полную поддержку файлов EWF, применяемых EnCase v6 и более ранними версиями, тогда как поддержка нового формата EWF2-EX01, появившегося в EnCase v7, была лишь экспериментальной.

• Монтирование с помощью EnCase. Файл EWF можно подключить в EnCase, а затем запустить Volatility для предоставленного устройства. Этот способ работает и в сетевой среде, допускающей выборочный сбор (см. статью Sampling RAM Across the EnCase Enterprise по адресу volatility-labs.blogspot.com). Он также позволяет избежать зависимости от libewf и поддерживает файлы EnCase v7.

• Монтирование с помощью FTK Imager. Ещё один вариант - подключить файл EWF в режиме "Physical & Logical", а затем запустить Volatility для части тома с нераспределённым пространством, например E:\unallocated space, если файл подключён как диск E:.

Разработанный HBGary формат HPAK позволяет поместить физическую память целевой системы и её файл или файлы подкачки в один выходной файл. Это проприетарный формат, поэтому создать файл HPAK способен только инструмент FastDump. Для этого в нём необходимо использовать параметр командной строки -hpak. В противном случае дамп памяти создаётся в формате по умолчанию - необработанном, без файла или файлов подкачки. При желании можно указать параметр -compress, чтобы сжать данные с помощью zlib. Полученный файл имеет расширение .hpak.

После того как несколько пользователей Volatility неожиданно получили для анализа файлы HPAK, мы создали адресное пространство для их обработки. Помните: если получение выполняете не вы, приходится работать с тем, что вам предоставили. К счастью, формат файла HPAK сравнительно прост. Он имеет 32-байтовый заголовок, показанный ниже, первые четыре байта которого содержат HPAK - магическую сигнатуру. Назначение остальных полей пока неизвестно, но для анализа памяти они несущественны.

После заголовка расположена одна или несколько структур HPAK_SECTION следующего вида:

Значение Header представляет собой строку наподобие HPAKSECTHPAK_SECTION_PHYSDUMP для раздела с физической памятью. Аналогично, для раздела с файлом подкачки целевой системы оно принимает значение HPAKSECTHPAK_SECTION_PAGEDUMP. Члены Offset и Length указывают точное местоположение соответствующих данных в файле HPAK. Если Compressed не равен нулю, данные раздела сжаты алгоритмом zlib.

Как показано в следующей команде, содержимое файла HPAK можно исследовать с помощью hpakinfo:

Вывод сообщает, что этот HPAK содержит физическую память и один файл подкачки. Раздел физической памяти начинается со смещения 0x4f8 файла memdump.hpak и состоит из 0x20000000 байт (512 Мбайт). Ни один из разделов не сжат. Можно либо запускать плагины Volatility непосредственно для memdump.hpak, либо извлечь раздел физической памяти в отдельный файл с помощью плагина hpakextract. После извлечения у вас останется необработанный дамп памяти, совместимый почти со всеми платформами анализа.

Чтобы получить память виртуальной машины (VM), можно запустить одно из упомянутых выше программных средств внутри гостевой ОС (VM) либо выполнить получение со стороны гипервизора. В этом разделе рассматривается память VM, полученная со стороны гипервизора. Такой способ обычно менее инвазивен, если не приостанавливать и не переводить VM в сохранённое состояние, поскольку вредоносному коду, скрывающемуся в VM, труднее обнаружить ваше присутствие. В конце раздела мы также рассмотрим Actaeon, позволяющий проводить криминалистический анализ памяти самого гипервизора, то есть анализировать гостевую ОС непосредственно в памяти хоста.

Если используется настольный продукт, например VMware Workstation, Player или Fusion, достаточно приостановить VM, перевести её в сохранённое состояние либо создать её снимок. В результате копия памяти VM записывается в каталог файловой системы хоста относительно конфигурационного файла .vmx. При использовании VMware Server или ESX это можно сделать из графической консоли vSphere либо в командной строке с помощью пригодной для сценариев команды vmrun (см. vmware.com). В облачной среде дамп памяти, скорее всего, будет записан в хранилище сети хранения данных (SAN) или сетевой файловой системы (NFS).

В зависимости от продукта и версии VMware, а также от способа создания дампа памяти для анализа может понадобиться получить более одного файла. В одних случаях память VM целиком содержится в одном файле .vmem - это необработанная схема. В других вместо .vmem предоставляется файл .vmsn для снимка или .vmss для сохранённого состояния; это проприетарные форматы, содержащие память и метаданные, - комбинированная схема. К счастью, Нир Израэли достаточно подробно документировал формат, чтобы создать для Volatility адресное пространство (его первоначальная работа: code.google.com).

Чтобы немного усложнить дело, Себастьян Бурн-Ричард недавно заметил, что продукты VMware часто создают .vmem и один из структурированных файлов метаданных - разделённую схему. Для её поддержки Volatility потребовалось написать совершенно новое адресное пространство, поскольку .vmem содержит серии физической памяти, а файл метаданных указывает, как соединить их, чтобы получить точное представление памяти гостевой системы. Иными словами, при получении памяти из систем VMware обязательно сохраняйте все файлы с расширениями .vmem, .vmsn и .vmss, поскольку заранее трудно определить, какой или какие из них содержат необходимые доказательства.

По нулевому смещению файлов метаданных находится структура _VMWARE_HEADER следующего вида:

Чтобы файл считался допустимым, значение Magic должно быть равно 0xbed2bed0, 0xbad1bad1, 0xbed2bed2 или 0xbed3bed3. Член Groups задаёт массив структур _VMWARE_GROUP следующего вида:

У каждой группы имеется Name, позволяющее распределять компоненты метаданных по категориям, и TagsOffset, указывающее, где находится список структур _VMARE_TAG. Тег выглядит так:

Эти структуры тегов служат ключом к поиску данных физической памяти внутри файла метаданных. Если у VM менее 4 Гбайт RAM, одна серия физической памяти хранится в группе с именем memory и теге с именем Memory. Для систем с объёмом RAM более 4 Гбайт имеется несколько серий: они также находятся в группе memory, но включают теги Memory, regionPPN, regionPageNum и regionSize. Адресное пространство Volatility (см. volatility/plugins/addrspaces/vmware.py) разбирает эти теги, чтобы восстановить представление физической памяти.

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

• Команды vboxmanage debugvm. Этот способ создаёт двоичный core dump ELF64 со специальными разделами, представляющими физическую память гостевой системы. Дополнительные сведения: virtualbox.org.

• Использование параметра --dbg при запуске VM, а затем команды .pgmphystofile. Этот способ создаёт необработанный дамп памяти. Дополнительные сведения: virtualbox.org.

• Использование Python API VirtualBox (vboxapi) для создания собственной утилиты сохранения дампа памяти. К упомянутой выше заявке #10222 один из пользователей также приложил сценарий Python vboxdump.py с примером.

Второй и третий способы создают необработанные дампы памяти, которые Volatility поддерживает изначально. Первый же формирует core dump ELF64, требующий специальной поддержки. Филипп Тёвен (см. wiki.yobi.be) провёл первоначальное исследование этого формата и создал поддерживающее его адресное пространство Volatility. Благодаря этому Cuckoo Sandbox смогла реализовать сохранение дампов памяти виртуальных машин VirtualBox в формате core dump ELF64.

Файлы ELF64 имеют несколько специальных сегментов заголовка программы. Один из них - PT_NOTE (elf64_note) с именем VBCORE. Сегмент примечания содержит структуру DBGFCOREDESCRIPTOR, показанную ниже:

Эта структура содержит магическую сигнатуру VirtualBox (0xc01ac0de), сведения о версии и количество ЦП целевой системы. Если продолжить перебор заголовков программ файла, будут обнаружены различные сегменты PT_LOAD (elf64_phdr). Член p_paddr каждого сегмента содержит начальный адрес физической памяти. Член p_offset указывает, где в файле ELF64 находится этот фрагмент физической памяти. Наконец, p_memsz сообщает размер фрагмента памяти в байтах.

QEMU очень похож на VirtualBox: он сохраняет память VM в формате core dump ELF64. Фактически единственное существенное различие состоит в том, что имя PT_NOTE равно CORE, а не VBCORE. Такие дампы можно создавать с помощью virsh - интерфейса командной строки для libvirt (libvirt.org). Имеется также Python API, который Cuckoo Sandbox (cuckoosandbox.org) в настоящее время использует для создания дампов памяти заражённых VM QEMU.

Проект LibVMI (github.com) представляет собой библиотеку интроспекции VM, поддерживающую гипервизоры Xen и KVM. Иными словами, можно в реальном времени анализировать работающие VM, не выполняя никакого кода внутри VM. Это мощная возможность для оперативного антивирусного сканирования и поиска руткитов, а также для общего мониторинга системы. В качестве дополнительного преимущества проект включает Python API (pyvmi) и адресное пространство Volatility (PyVmiAddressSpace) для анализа памяти.

Чтобы получить память VM Hyper-V, сначала необходимо сохранить состояние VM или создать снимок. Затем из каталога конфигурации VM нужно извлечь файлы .bin с фрагментами физической памяти и .vsv с метаданными. К сожалению, в настоящее время Volatility не поддерживает формат памяти Hyper-V, поэтому файлы .bin и .vsv необходимо преобразовать в дамп сбоя Windows с помощью утилиты vm2dmp.exe (archive.msdn.microsoft.com). Полученный дамп сбоя можно анализировать в WinDBG или Volatility. Дополнительные сведения об этом процессе приведены в статье Уайетта Рурсмы Analyzing Hyper-V Saved State Files in Volatility (wyattroersma.com). Одно из важных наблюдений Уайетта состоит в том, что vm2dmp.exe не работает с VM, у которых более 4 Гбайт RAM.

Одна из самых увлекательных разработок в криминалистическом анализе памяти VM - Actaeon (s3.eurecom.fr) Мариано Грациано, Андреа Ланци и Давиде Бальцаротти. Получив дамп физической памяти хост-системы, этот инструмент позволяет анализировать гостевые ОС в средах виртуализации, использующих технологию Intel VT-x. В том числе он способен находить резидентные в памяти гипервизоры, как безвредные, так и вредоносные, и вложенную виртуализацию. Текущая реализация позволяет выполнять интроспекцию 32-разрядных гостевых систем Windows, работающих под управлением KVM, Xen, VMware Workstation, VirtualBox и HyperDbg. Actaeon реализован как патч для Volatility и занял первое место в конкурсе плагинов Volatility 2013 года (volatility-labs.blogspot.com).

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

В следующем сценарии рассматриваются технические аспекты поиска энергозависимых доказательств на диске и их извлечения. Криминалистическое создание образов, то есть дублирование, жёстких дисков выходит за рамки книги, как и действия по надлежащему сохранению цепочки ответственного хранения доказательств. Поэтому мы предполагаем, что вы изучили и соблюдаете законы своей юрисдикции, если они применимы к вашему расследованию. Кроме того, хотя различные коммерческие продукты с графическим интерфейсом, например EnCase и FTK, позволяют извлекать файлы несколькими щелчками, мы сосредоточимся на The Sleuth Kit (sleuthkit.org), поскольку этот набор имеет открытый исходный код и доступен всем.

Если в системе имеется файл гибернации, он находится по пути \hiberfil.sys в корневом каталоге раздела C:. Предположим, что у вас есть необработанный образ диска, в примере это image.dd. Сначала необходимо определить начальный сектор раздела NTFS. Для этого можно следующим образом воспользоваться mmls:

Как видно, смещение начального сектора равно 2048. Это значение передаётся параметром -o другим утилитам The Sleuth Kit (TSK), например fls. Помните, что у разных дисков разные смещения, поэтому 2048 - лишь значение для нашего примера. Следующая команда показывает, как отфильтровать вывод списка файлов корневого каталога раздела NTFS.

Индексный дескриптор, или в данном случае номер MFT, равен 36218. Теперь для извлечения содержимого файла достаточно передать смещение сектора и индексный дескриптор команде icat. Перед этим убедитесь, что на целевом носителе достаточно свободного места для файла гибернации. Следующая команда показывает процесс извлечения:

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

Часто доказательства, например жёсткий диск, поступают без каких-либо сведений о целевой системе. Работала ли она, например, под управлением 32-разрядной Windows 7 или 64-разрядной Windows Server 2012? Эта информация необходима для выбора правильного профиля Volatility. Во многих случаях можно просто запустить плагин kdbgscan, однако помните, что блок данных отладчика не является обязательным и злоумышленники могут им манипулировать (см. главу 3). В таком случае потребуется резервный способ определения профиля системы. Здесь у вас есть доступ к жёсткому диску с кустами реестра, и это можно использовать в своих интересах. Следующие команды показывают, как извлечь кусты SYSTEM и SOFTWARE, а затем проверить, что восстановлены допустимые файлы реестра Microsoft Windows.

После выгрузки нужных файлов кустов их можно исследовать автономным анализатором реестра. Здесь мы используем reglookup, инструмент с открытым исходным кодом с сайта projects.sentinelchicken.org. В частности, в кусте SOFTWARE можно найти значение ProductName, а в кусте SYSTEM - значение PROCESSOR_ARCHITECTURE, как показано ниже:

Вывод показывает, что целевая система работала под управлением Windows 7 Professional на процессоре AMD64. Следовательно, профиль должен быть Win7SP0x64 или Win7SP1x64. Дополнительно различить пакеты обновления можно, запросив значение CSDVersion в реестре.

На занятиях мы часто задаём слушателям вопрос с подвохом: где искать файл подкачки, если потребуется его восстановить? Почти все отвечают: C:\pagefile.sys. Хотя технически этот ответ не ошибочен, он и не полон, поскольку в системе Windows может быть до 16 файлов подкачки. Поэтому перед попыткой их получить всегда следует определить количество файлов подкачки и их местоположение. Это можно сделать, запросив реестр SYSTEM, как показано ниже:

В целевой системе был только один файл подкачки, поэтому в данном случае ответ C:\pagfile.sys оказался правильным. Путь к файлу показан дважды из-за наличия двух значений: PagingFiles - доступные для использования файлы и ExistingPageFiles - используемые в данный момент. Если в системе их несколько, будет показан полный список путей. Восстановить файл или файлы подкачки из образа диска можно так:

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

Кроме того, начиная с Windows 8.1 в разделе CurrentControlSet\Control\CrashControl имеется значение SavePageFileContents, определяющее, должна ли Windows сохранять содержимое файла подкачки при перезагрузках.

Как вы помните из предыдущих разделов главы, некоторые программные инструменты, работающие в действующей системе, способны собирать файл или файлы подкачки во время получения. Независимо от того, применялся ли такой инструмент или файлы были извлечены из образа диска, возможности углублённого анализа содержимого файла подкачки сравнительно ограниченны. Помните, что файл подкачки - лишь неупорядоченный набор кусочков головоломки. Без таблиц страниц, предоставляющих необходимый контекст, невозможно определить, как они складываются в общую картину. Возможность дополнить анализ необработанного дампа памяти данными из файла или файлов подкачки, получив более полное представление физической памяти, впервые была описана Николасом Полом Маклином в работе Acquisition and Analysis of Windows Memory (4tphi.net). Однако практические реализации этой методики по большей части не были проверены либо недоступны.

В документации HBGary Responder указано, что он поддерживает анализ файлов подкачки. WinDBG также заявляет поддержку интеграции файлов подкачки (см. msdn.microsoft.com). В частности, согласно документации, должна существовать возможность создать CAB-файл с дампом памяти и файлом или файлами подкачки и проанализировать его отладчиком. Однако обсуждение в списке рассылки OSR показывает, что это утверждение в значительной степени неверно или просто устарело (osronline.com).

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

На самом деле Майкл Матонис создал инструмент page_brute (см. github.com), который анализирует файлы подкачки, разделяя их на фрагменты размером со страницу и сканируя каждый фрагмент правилами Yara. Набор правил Yara, распространяемый с инструментом по умолчанию, способен находить запросы и ответы HTTP, заголовки сообщений SMTP, команды FTP и тому подобное. Как всегда, стандартные правила можно дополнить или создать собственные наборы, чтобы настроить сканирование.

Предположим, вы исследуете компьютер подозреваемого, обвиняемого в покупке и продаже контролируемых веществ через Интернет. Браузер подозреваемого был настроен так, чтобы не кэшировать содержимое на диск и не сохранять файл истории. Кроме того, в момент изъятия компьютер был выключен, поэтому у вас имеется только криминалистический образ диска. Обнаружив и извлекая файл или файлы подкачки, вы надеетесь найти доказательства причастности подозреваемого к предполагаемому преступлению. Для помощи в поиске вы создаёте следующее правило Yara:

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

Число после сообщения FLAGGED BLOCK - индекс соответствующей страницы в файле подкачки. Каждая страница, совпавшая с сигнатурой, извлекается в рабочий каталог PAGE_BRUTE-2014-03-24-12-49-57-RESULTS с именем, соответствующим индексу. Затем извлечённые блоки можно анализировать по отдельности либо, для быстрого первоначального просмотра данных, просто запустить strings для всего каталога, как показано ниже:

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

В Linux пространство подкачки фактически представляет собой раздел, а не файл; его местоположение можно вывести командой cat /proc/swaps либо найти в /etc/fstab. Однако для доступа к содержимому потребуется образ диска. В Mac OS X пространство подкачки по умолчанию шифруется начиная с версии 10.7. Можно вывести список файлов в каталоге /var/vm или запросить состояние командой sysctl, как показано ниже:

Многие системы настроены на запись дампов сбоев на диск при появлении BSoD. Поэтому стоит проверить, не сохранились ли файлы, созданные при предыдущих сбоях и впоследствии не удалённые. По умолчанию они записываются в %SystemRoot%\MEMORY.DMP, однако путь можно изменить, отредактировав ключ CurrentControlSet\Control\CrashControl куста реестра SYSTEM. Заодно проверьте пути Windows Error Reporting (Dr. Watson) в ключе Software\Microsoft\Windows\Windows Error Reporting как в HKEY_CURRENT_USER, так и в HKEY_LOCAL_MACHINE. Скорее всего, там найдутся лишь дампы памяти пользовательского режима, а не полные, но во время нестабильной работы системы они всё равно могут служить ценным источником энергозависимых данных.

Значительная часть криминалистического анализа памяти связана с поиском и исследованием исполнительных объектов. Из главы 2 вы знаете, что Windows написана на C и активно использует структуры C для организации связанных данных и атрибутов. Некоторые из этих структур называются исполнительными объектами, потому что ими управляет диспетчер объектов Windows - компонент ядра, реализованный модулем NT: он создаёт, защищает, удаляет их и выполняет другие операции.

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

Различать их крайне важно, поскольку вследствие выделения диспетчером объектов все исполнительные объекты имеют сходные характеристики. Например, у всех исполнительных объектов имеются упомянутые заголовки, а у структур, выделенных другими подсистемами, такими как стек TCP/IP (tcpip.sys), таких заголовков нет.

Наиболее значимые для криминалистики типы исполнительных объектов описаны в табл. 5-1 вместе с соответствующими именами структур. С этими типами объектов вы будете знакомиться на протяжении всей книги, поэтому пока считайте это лишь кратким первым введением. Фактически каждый объект из таблицы анализируется как минимум одним плагином Volatility.

Таблица 5-1. Значимые для криминалистики объекты Windows

Одна из общих черт всех типов исполнительных объектов - наличие заголовка объекта (_OBJECT_HEADER) и нуля или нескольких необязательных заголовков. В памяти заголовок объекта находится непосредственно перед структурой исполнительного объекта. Аналогично, все имеющиеся необязательные заголовки расположены перед заголовком объекта в фиксированном порядке. В результате получается предсказуемая компоновка памяти, показанная на рис. 5-1. Поэтому найти структуру, то есть _FILE_OBJECT на рисунке, по адресу её _OBJECT_HEADER или наоборот несложно: они всегда непосредственно соседствуют, а размер _OBJECT_HEADER постоянен для каждой операционной системы.

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

Рисунок 5-1. Исполнительные объекты и их заголовки в 64-разрядной Windows

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

• PointerCount: содержит общее количество указателей на объект, включая ссылки режима ядра.

• HandleCount: содержит количество открытых дескрипторов объекта.

• TypeIndex: это значение сообщает, с каким типом объекта вы имеете дело, например с процессом, потоком или файлом.

• InfoMask: это значение сообщает, какие необязательные заголовки присутствуют, если они вообще имеются.

• SecurityDescriptor: хранит сведения об ограничениях безопасности объекта, например о том, каким пользователям разрешены чтение, запись, удаление и другие операции.

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

Необязательные заголовки объекта содержат различные виды метаданных, помогающих описывать объект. Очевидно, поскольку они необязательны, они имеются не у всех типов объектов; даже разные экземпляры одного типа объекта могут иметь разные сочетания необязательных заголовков. Например, ядро не отслеживает статистику квот, то есть использования ресурсов, для процессов Idle и System, поэтому у этих двух объектов _EPROCESS отсутствуют заголовки _OBJECT_HEADER_QUOTA_INFO. Кроме того, мьютексу имя требуется лишь в том случае, если им должны совместно пользоваться несколько процессов. Следовательно, у именованных мьютексов имеется заголовок _OBJECT_HEADER_NAME_INFO, а у неименованных его нет. Хотя многие необязательные заголовки полезны для криминалистики, следователи чаще всего анализируют заголовок имени.

В табл. 5-2 показаны необязательные заголовки, доступные в 64-разрядных системах Windows 7. Если значение из столбца "Битовая маска" установлено в _OBJECT_HEADER.InfoMask объекта, соответствующий необязательный заголовок присутствует. Если вспомнить компоновку структур на рис. 5-1, необязательные заголовки находятся по отрицательным смещениям от начала _OBJECT_HEADER. Точное расстояние зависит от наличия других заголовков и их размеров, приведённых в столбце "Размер" табл. 5-2.

Таблица 5-2. Необязательные заголовки в 64-разрядной Windows 7

Член TypeIndex структуры _OBJECT_HEADER представляет собой индекс в nt!ObTypeIndexTable - массив объектов типов (_OBJECT_TYPE). Как было показано в табл. 5-1, эти объекты содержат метаданные, описывающие общие свойства всех объектов. Для криминалистического анализа памяти эти данные критически важны, поскольку позволяют определить тип объекта, следующего за _OBJECT_HEADER. Например, записи таблицы дескрипторов процесса (см. главу 6) указывают на заголовки объектов. Поэтому при перечислении записей таблицы дескрипторов тип данных после заголовка произволен: это может быть _FILE_OBJECT, _EPROCESS или любой другой исполнительный объект. Различить варианты можно, изучив значение TypeIndex, найдя соответствующий этому индексу _OBJECT_TYPE и затем проверив член Name. Соответствия между именами типов объектов и именами их структур приведены в табл. 5-1.

Ниже приведён пример структуры типа объекта в 64-разрядной Windows 7:

Ключевые положения таковы:

• Name: строка Unicode с именем типа объекта, например Process, File или Key.

• TotalNumberOfObjects: общее количество существующих в системе объектов данного типа.

• TotalNumberOfHandles: общее количество открытых дескрипторов объектов данного типа.

• TypeInfo: структура _OBJECT_TYPE_INITIALIZER, сообщающая тип памяти, использованный для выделения экземпляров этих объектов, например страничную или нестраничную память.

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

Члены TypeInfo и Key дают две подсказки, которые окажутся бесценными для криминалистического анализа памяти: по существу, они сообщают, где искать - в страничной или нестраничной памяти - и что искать - определённый четырёхбайтовый тег, - чтобы найти все экземпляры конкретного типа объектов, например все процессы или все файлы. Следующий пример показывает, как динамически получить эти сведения из дампа памяти, написав короткий сценарий для плагина volshell:

Как видно из кода, данные по адресу ядра 0xFFFFF80002870300 были интерпретированы как массив указателей на структуры _OBJECT_TYPE. Перебрав результаты, можно увидеть, что объекты Process находятся в нестраничной памяти, а объекты Token - в страничной. Следовательно, можно ожидать, что объекты _EPROCESS всегда будут находиться в RAM, тогда как некоторые объекты _TOKEN могут быть выгружены на диск. Кроме того, у вас появляется потенциальная сигнатура для сканирования при поиске фактических объектов в памяти: Proc для процессов и Toke для токенов. Разумеется, нужна более надёжная сигнатура, чем всего четыре байта, иначе результаты будут затуманены ложными срабатываниями. Это подводит нас к следующему требованию: пониманию выделений в пулах.

Смещение слева - адрес _OBJECT_TYPE в памяти ядра. Эта таблица содержит те же сведения, что и сценарий volshell, но результаты расположены в другом порядке: сценарий volshell обходил список, начиная с nt!ObTypeIndexTable, а objtypescan сканировал память и выводил результаты в порядке обнаружения.

Пул ядра - диапазон памяти, который можно разделять на меньшие блоки для хранения данных любого типа, запрошенных компонентом режима ядра: модулем NT, сторонним драйвером устройства и т. д. Подобно куче, каждый выделенный блок имеет заголовок (_POOL_HEADER) с учётными и отладочными сведениями. По этим дополнительным данным можно связать блоки памяти с владеющим ими драйвером и в некоторой степени сделать выводы о типе структур или объектов, содержащихся в выделенной области. Это критически важно не только для диагностики утечек памяти и повреждений, но и для криминалистического анализа памяти.

Рис. 5-2 представляет собой изменённый вариант рис. 5-1 и показывает различие в компоновке памяти, возникающее при учёте того, что эти выделения имеют заголовок пула по базовому адресу, то есть в начале диапазона.

Рисунок 5-2. Исполнительные объекты внутри пула

В 64-разрядной системе Windows 7 заголовок пула выглядит так:

Ключевые положения таковы:

• BlockSize: общий размер выделенной области, включая заголовок пула, заголовок объекта и все необязательные заголовки.

• PoolType: тип системной памяти, например страничной или нестраничной, описываемой этим заголовком пула.

• PoolTag: четырёхбайтовое значение, обычно состоящее из символов ASCII, которое должно уникально определять путь выполнения кода, приведший к выделению, чтобы проблемные блоки можно было отследить до их источника. В системах до Windows 8 и Server 2012 один символ может быть изменён для установки "защитного бита", подробнее о котором рассказано в примечании возле табл. 5-3.

Прежде чем создать экземпляр исполнительного или любого другого объекта, из одного из пулов операционной системы необходимо выделить блок памяти, достаточно большой для хранения объекта и его заголовков. Для этого часто используется интерфейс прикладного программирования (API) ExAllocatePoolWithTag. Прототип функции выглядит так:

Аргумент PoolType задаёт тип системной памяти, используемой для выделения. Значения перечисления NonPagedPool (0) и PagedPool (1) соответствуют нестраничной и страничной памяти. Как уже было показано, большинство, но не все типы исполнительных объектов выделяются в нестраничной памяти; различие всегда можно определить по члену _OBJECT_TYPE.TypeInfo.PoolType конкретного объекта.

Аргумент NumberOfBytes содержит количество выделяемых байтов. Драйверы, напрямую вызывающие ExAllocatePoolWithTag, могут задать здесь размер данных, которые требуется хранить в блоке памяти. Исполнительные объекты, как вы уже знаете, отличаются тем, что им требуется дополнительное пространство для заголовка объекта и необязательных заголовков. Функция ядра ObCreateObject служит центральной точкой создания всех исполнительных объектов. Она определяет размер запрошенной структуры, например 1232 байта для _EPROCESS в 64-разрядной Windows 7, добавляет размер _OBJECT_HEADER и всех необходимых необязательных заголовков, а затем вызывает ExAllocatePoolWithTag.

Аргумент Tag задаёт четырёхбайтовое значение, обычно состоящее из символов ASCII, которое должно уникально определять путь выполнения кода, приведший к выделению, чтобы проблемные блоки можно было отследить до их источника. Для исполнительных объектов теги выводятся из члена _OBJECT_TYPE.Key, что и объясняет одинаковое значение Tag у всех объектов определённого типа.

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

1. Процесс вызывает CreateFileA для ASCII или CreateFileW для Unicode; обе функции экспортируются kernel32.dll.

2. API создания файла передают управление в ntdll.dll, которая затем вызывает ядро и достигает нативной функции NtCreateFile.

3. NtCreateFile вызывает ObCreateObject, запрашивая новый объект типа File.

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

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

6. Вызывается ExAllocatePoolWithTag с соответствующим размером, типом памяти и тегом.

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

Дополнительные сведения приведены в работе Андреаса Шустера The Impact of Windows Pool Allocation Strategies on Memory Forensics: dfrws.org.

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

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

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

Повторим: когда блоки памяти пула освобождаются, они лишь помечаются как свободные, а не перезаписываются немедленно. То же понятие применимо к криминалистическому анализу дисков. При удалении файла NTFS изменяется только запись главной файловой таблицы (Master File Table, MFT), отражая новый статус. Содержимое файла остаётся нетронутым, пока секторы не будут переназначены новому файлу и в них не произойдёт запись. Благодаря такому поведению исполнительные объекты, как и любые другие выделения памяти, можно находить в RAM намного позже того, как операционная система их отбросила. Это даёт уникальное представление системы, включающее не только список активно используемых исполнительных объектов, но и ресурсы, существовавшие в прошлом.

Сканирование тегов пула, или просто сканирование пула, означает поиск выделений по упомянутым четырёхбайтовым тегам. Например, для поиска объектов процессов можно найти символ ядра, указывающий на начало двусвязного списка активных процессов, а затем перечислить записи, обойдя этот список. Другой вариант - сканирование пула - состоит в поиске Proc, четырёхбайтового тега, связанного с _EPROCESS, во всём файле дампа памяти. Преимущество второго способа в том, что он находит исторические записи, то есть уже не работающие процессы, а также противодействует некоторым методикам сокрытия руткитов, например прямому манипулированию объектами ядра (Direct Kernel Object Manipulation, DKOM), основанным на изменении списков активных объектов.

При сканировании тегов пула четырёхбайтовый тег служит лишь отправной точкой. Если полагаться только на него, возникнет множество ложных срабатываний. Поэтому Volatility строит более надёжную "сигнатуру" того, как выглядит память вокруг искомых выделений, опираясь на сведения, изложенные ранее в главе. Например, размер выделения и тип памяти, страничной или нестраничной, играют важную роль в устранении ложных срабатываний. Если вы ищете 100-байтовый _EPROCESS и находите Proc внутри 30-байтового выделения, это не может быть настоящий процесс, поскольку блок памяти слишком мал.

В табл. 5-3 показаны исходные критерии, по которым Volatility находит перечисленные исполнительные объекты посредством сканирования пула. Минимальный размер в таблице вычисляется сложением размера _EPROCESS для процессов, _OBJECT_HEADER и _POOL_HEADER.

Таблица 5-3. Данные тегов пула, используемые существующими плагинами Volatility для Windows XP - 7

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

Обратите внимание и на столбец "Тег (защищённый)" в табл. 5-3. Одна из наиболее редко документируемых тонкостей тегов пула - защитный бит. При освобождении пула функцией ExFreePoolWithTag необходимо передать тот же тег, который был передан ExAllocatePoolWithTag. Операционная система использует этот приём, чтобы драйверы не освобождали память случайно. Если тег, переданный функции освобождения, не совпадает, система вызывает исключение. Это существенно влияет на криминалистический анализ памяти, поскольку фактически искать необходимо защищённую версию тега пула.

Как уже упоминалось, Microsoft создала теги пулов для отладки и аудита. Поэтому некоторые установки Windows Driver Development Kit (DDK) и Debugging Tools for Windows включают файл pooltag.txt, по которому можно выполнять поиск. Например, имея тег пула, можно определить назначение выделений и владеющий ими драйвер ядра. Поскольку файл содержит описания, можно также начать с ключевых слов наподобие "process object" или "file object" и определить тег пула. Ниже приведён пример содержимого файла pooltag.txt:

Выделенная в источнике строка показывает, что объекты процессов используют тег Proc и выделяются компонентом nt!ps, то есть подсистемой процессов модуля NT. Хотя эти сведения полезны, они служат лишь отправной точкой. Узнав тег объектов процессов, всё ещё необходимо определить примерный размер выделений и тип памяти - страничной или нестраничной.

PoolMon (msdn.microsoft.com) - монитор пула памяти, распространяемый в составе Microsoft Driver Development Kit (DDK). Он в реальном времени сообщает обновления об используемых в системе тегах пула вместе со следующими сведениями:

• тип памяти: Paged или Nonpaged;

• количество выделений;

• количество освобождений;

• общее число байтов, занятых выделениями;

• среднее число байтов на выделение.

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

Как видно, CM31 занимает первое место по количеству байтов. С момента запуска системы для тега CM31 было сделано 169 392 вызова ExAllocatePoolWithTag, и 153 744 из этих выделений были освобождены. Разница составляет 15 648 блоков, выделенных в настоящий момент и вместе занимающих 74 838 016 байт, то есть примерно 75 Мбайт памяти. В среднем это 4782 байта на выделение.

Тег CM25 ненамного отстаёт от CM31, используя около 10 Мбайт памяти. CM в этих именах тегов означает Configuration Manager - компонент ядра, обслуживающий реестр Windows. Следовательно, можно заключить, что не менее 85 Мбайт RAM зарезервировано для хранения ключей и данных реестра. Однако не следует рассчитывать извлечь из дампа памяти все 85 Мбайт: оба тега находятся в страничной памяти, поэтому часть данных могла быть выгружена на диск.

Ещё один интересный момент касается тега File, то есть выделений, хранящих структуры _FILE_OBJECT. Как показывает PoolMon, с момента последней перезагрузки их было создано более 126 000 000, что логично, поскольку _FILE_OBJECT выделяется при каждом открытии или создании файла. Но объекты файлов довольно малы, поэтому 18 000 выделенных сейчас объектов занимают в общей сложности лишь около 3,5 Мбайт, в среднем 183 байта на выделение.

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

Вывод сокращён для краткости, но среди показанных результатов шесть блоков выделены в настоящий момент, а два помечены как свободные. Один из свободных блоков имеет тот же размер, что и выделенные, - 430, а второй намного меньше - 10. Поэтому свободный блок по адресу 0xfffffa800138f7a0, вероятно, содержит завершённый _EPROCESS, тогда как часть блока по адресу 0xfffffa800153ebd0 уже была использована заново.

Поскольку PoolMon предназначен для показа изменений использования тегов пула в реальном времени, его необходимо запускать в действующей системе. Но что делать, если имеется только дамп памяти? К счастью, память фактически содержит статистику, считываемую PoolMon. Она доступна из того же блока данных отладчика ядра (_KDDEBUGGER_DATA64), где хранятся списки активных процессов и загруженных модулей. В частности, член PoolTrackTable указывает на массив структур _POOL_TRACKER_TABLE - по одной для каждого уникального используемого тега пула. Вот как эти структуры выглядят в 64-разрядной системе Windows 7:

Как видно, у каждой таблицы отслеживания имеется Key - четырёхбайтовый тег. Остальные члены сообщают количество выделений, освобождений и общее число занятых байтов как для нестраничной, так и для страничной памяти. Хотя сведения не обновляются в реальном времени, что естественно, поскольку система уже не работает, можно по крайней мере определить её состояние на момент получения дампа памяти. Ниже приведён пример запуска плагина pooltracker с фильтрацией нескольких тегов, используемых исполнительными объектами. Имена столбцов начинаются с Np для нестраничной памяти или Pg для страничной:

Можно определить, что все четыре тега находятся в нестраничной памяти, поскольку три столбца NpAllocs, NpFrees и NpBytes имеют ненулевые значения. Чтобы определить приблизительный размер одного выделения, разделите общее число байтов на текущее количество выделений. Например, для тега Thre, то есть объектов Thread, средний размер равен 606688 / (614895 - 614419) = 1274 байта. Следовательно, чтобы найти все выделения, содержащие потоки, следует искать в нестраничной памяти теги Thre в блоках размером не менее 1274 байт.

Как уже упоминалось, все плагины Volatility, перечисленные в табл. 5-3, реализуют подход сканирования пула для поиска объектов в памяти. Платформа предоставляет базовый класс PoolScanner, который можно расширить, настроив поведение сканера, например искомый тег, размер выделений и тип памяти, а также класс AbstractScanCommand, предоставляющий все параметры командной строки, необходимые плагину сканирования пула.

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

В первой строке PoolScanProcess расширяет PoolScanner, поэтому наследует функциональность, общую для всех сканеров пула. Для поиска объектов процессов необходимо внести лишь следующие настройки:

• Имя структуры. В строке 7 задаётся имя структуры _EPROCESS. Оно сообщает сканеру пула, какой тип структуры содержится в выделениях.

• Тип объекта. В строке 8 задаётся тип исполнительного объекта Process, который используется как дополнительная форма проверки. Обнаружив возможное выделение, сканер сравнивает указанное значение с членом Name структуры _OBJECT_HEADER. Для сканеров пулов, выделения которых не содержат исполнительные объекты, например сетевые соединения и сокеты, тип объекта не задаётся.

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

• Размер выделения. В строке 10 формируется минимальный размер выделения, способного хранить объекты процессов, на основе размера _EPROCESS. Это значение также не задаётся жёстко, поскольку размеры различаются между профилями, особенно в 32- и 64-разрядных системах. Ограничение размера применяется в строке 13.

• Тип памяти. В строке 14 объявляются допустимые типы памяти. В данном случае сканер ищет выделения в нестраничной и свободной памяти. Все результаты в страничной памяти он пропускает.

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

Как видно из первой строки, имя класса PSScan, расширяющего AbstractScanCommand, становится именем плагина. В строке 4 плагин связывается с классом PoolScanProcess. Учтите, что переменная scanners может принимать несколько классов, если требуется найти разные объекты за один проход по дампу памяти, что даёт огромную экономию времени. Остальной код в строках 7-14 создаёт заголовок таблицы в текстовом выводе, а строки 16-24 добавляют в таблицу по одной строке на каждый найденный сканером результат. В данном случае каждый результат представляет собой объект _EPROCESS.

При расширении базового класса AbstractScanCommand новый плагин получает различные параметры командной строки, позволяющие пользователям настраивать поведение сканера. Они видны в нижней части вывода --help, как показано ниже:

Ниже приведены описания параметров:

• -V/--virtual. При сканировании выделений пула можно использовать виртуальное адресное пространство ядра или физическое адресное пространство. По умолчанию Volatility использует физическое пространство, поскольку оно охватывает как можно больше памяти, включая блоки, которых сейчас нет в таблице страниц ядра. Это позволяет восстанавливать объекты из "остаточного пространства" RAM. Чтобы перейти в режим сканирования только активных страниц, для которых у ядра сейчас имеется отображение, используйте -V/--virtual.

• -W/--show-unallocated. Этот параметр определяет, показывает ли плагин объекты, явно помеченные операционной системой как невыделенные. Дополнительные сведения приведены в публикации Андреаса Шустера: computer.forensikblog.de.

• -S/--start и -L/--length. Если требуется сканировать не всю память, а только определённый диапазон, этими параметрами можно указать начальный адрес и длину. Адрес интерпретируется как расположение в физической или виртуальной памяти в зависимости от того, установлен ли флаг -V/--virtual.

Базовый класс PoolScanner, а следовательно, и любой расширяющий его сканер, формирует результаты по логике, показанной на рис. 5-3.

Рисунок 5-3. Схема алгоритма сканирования пула

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

Ниже показан пример запуска плагина psscan со всеми параметрами по умолчанию:

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

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

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

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

• Нетегированная память пула. ExAllocatePoolWithTag - рекомендуемый Microsoft способ выделения памяти драйверами и компонентами режима ядра, но не единственный. Драйвер может использовать и ExAllocatePool, которая находится в процессе объявления устаревшей, но всё ещё доступна во многих версиях Windows. Этот API выделяет память без тега, не оставляя простого способа отслеживать или сканировать такие выделения.

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

• Крупные выделения. Методика сканирования тегов пула не работает для выделений размером более 4096 байт (см. следующий раздел "Пул больших страниц"). К счастью, все исполнительные объекты меньше этого размера.

Ниже перечислены оговорки к сканированию пула, возникающие именно вследствие анти-криминалистических атак.

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

• Теги-приманки. Как указывают Уолтерс и Петрони (blackhat.com), драйвер может создавать поддельные объекты-приманки, выглядящие "как живые", чтобы ввести следователей в заблуждение и тем самым повысить соотношение сигнала к шуму.

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

Большинству, если не всем, этим анти-криминалистическим методикам можно противодействовать, подтверждая наблюдаемые доказательства другими источниками данных. Например, в главе 6 мы рассмотрим не менее шести способов поиска процессов, и лишь один из них связан со сканированием пула. Чтобы опровергнуть поддельный объект TCP-соединения, следует проверить захваченные сетевые пакеты, журналы межсетевого экрана и другие источники и выяснить, происходила ли активность в действительности.

Как уже упоминалось, ядро Windows пытается группировать выделения сходного размера. Однако если запрошенный размер превышает одну страницу, то есть 4096 байт, блок памяти выделяется из специального пула, зарезервированного для крупных выделений, - пула больших страниц. В этом случае _POOL_HEADER, содержащий четырёхбайтовый тег и расположенный по базовому адресу меньших выделений, вообще не используется. Поэтому сканирование тегов пула завершается неудачей: искать нечего. На рис. 5-4 показано различие компоновки памяти между двумя соседними выделениями ядра размером менее 4096 байт и двумя выделениями размером более 4096 байт.

Рисунок 5-4. Крупные выделения теряют заголовок пула

Как видно, структуры _POOL_HEADER для крупных выделений не хранятся. В качестве доказательства концепции мы написали драйвер ядра, перехватывающий API ObCreateObject и увеличивающий размер выделений, используемых для хранения объектов _EPROCESS. Как мы и предполагали, плагин Volatility psscan не смог найти новые процессы, поскольку тег Proc отсутствовал. Но не всё потеряно: просто искать нужно не там, где обычно. Например, рис. 5-4 показывает, что таблицы отслеживания больших страниц могут напрямую указывать на объекты в пулах больших страниц.

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

К сожалению, символ ядра nt!PoolBigPageTable, указывающий на массив структур _POOL_TRACKER_BIG_PAGES, по одной для каждого крупного выделения, не экспортируется и не копируется в блок данных отладчика ядра. Однако мы обнаружили, что этот символ всегда находится в предсказуемом месте относительно nt!PoolTrackTable, который копируется в блок данных отладчика. Следовательно, если найти таблицы отслеживания пула, таблицы отслеживания больших страниц также можно найти без труда.

Следующий вывод показывает структуру таблицы отслеживания больших страниц в 64-разрядной Windows 7:

Член Va, сокращение от virtual address, указывает на базовый адрес выделения. Здесь также видны Key, то есть тег пула, PoolType, страничный или нестраничный тип, и NumberOfBytes, размер выделения. Помните: хотя эта структура хранит тег пула, он находится совсем не там, где само выделение, на которое указывает Va. Для малых выделений тег пула содержится внутри выделения, как было показано на рис. 5-4.

Для получения сведений о крупных выделениях пула ядра в дампе памяти можно использовать плагин bigpools. Следующая команда показывает пример вывода:

Столбец Allocation сообщает адрес памяти ядра, с которого начинается выделение. Чтобы увидеть содержимое области, можно выгрузить данные по этому адресу в volshell. Некоторые источники указывают, что выделения с адресом, оканчивающимся на 1, например 0xfffff8a00f9a8001, находятся в нестраничной памяти. Однако согласно нашему исследованию 1 означает, что блок помечен как свободный. Поэтому можно попытаться вывести данные по таким адресам, но, вероятно, они не будут соответствовать ожиданиям на основании тега пула. Например, сравним несколько блоков CM31:

Первый адрес (0xfffff8a003747000) содержит у основания hbin и несколько экземпляров vk. Как уже упоминалось, CM в CM31 означает Configuration Manager - компонент реестра в ядре. hbin и vk являются сигнатурами блоков HBIN реестра и отдельных значений соответственно (см. главу 10). Второй (0xfffff8a00f9a8001) и третий (0xfffff8a00861d001) адреса помечены как свободные, но между ними имеется существенное различие. Один недоступен, возможно потому, что выгружен на диск: в конце концов, он находится в страничной памяти. Другой, по-видимому, уже был заново выделен и перезаписан, поскольку сигнатура hbin исчезла.

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

По описаниям видно, что данные в пулах больших страниц содержат очень интересные артефакты: от таблиц преобразования до записей таблиц страниц (PTE) и журналов доступа диспетчера памяти (Mm), сведений Address Space Layout Randomization (ASLR), таблиц дескрипторов процессов, то есть таблиц объектов, и назначений интернет-портов. Для интерпретации данных в этих выделениях необходимо понимать структуры и форматы, используемые владеющим драйвером, однако знание описаний и точного расположения блоков в памяти радикально ускоряет исследование.

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

Некоторые типы исполнительных объектов, например процессы, потоки и мьютексы, допускают синхронизацию. Это означает, что другие потоки могут синхронизироваться с этими объектами или ожидать их запуска, завершения либо другого действия. Для поддержки этой возможности ядро хранит сведения о текущем состоянии объекта во вложенной структуре _DISPATCHER_HEADER, расположенной в самом начале, то есть по нулевому смещению, структуры исполнительного объекта. Что ещё важнее, заголовок содержит несколько значений, постоянных для дампов памяти определённой версии Windows, поэтому для их поиска легко построить сигнатуру конкретного профиля.

Следующий вывод получен в 32-разрядной системе Windows XP Service Pack 2:

Андреас Шустер обнаружил, что поля Absolute и Inserted всегда равны нулю в системах Windows 2000, XP и 2003. Поля Type и Size имели жёстко заданные значения, определяющие соответственно тип и размер объекта. Например, в 32-разрядных машинах Windows XP значение Type для процессов равно 3, а Size равно 0x1b, что даёт четырёхбайтовую сигнатуру \x03\x00\x1b\x00. Подобно тегу пула, можно пройти по дампу памяти в поисках экземпляров этой сигнатуры и найти все объекты _EPROCESS. Так работал один из самых ранних инструментов криминалистического анализа памяти PTFinder: computer.forensikblog.de.

Один из недостатков сканирования заголовков диспетчера состоит в том, что оно помогает находить лишь объекты, допускающие синхронизацию. Например, объекты файлов синхронизации не допускают, поэтому у них нет встроенного _DISPATCHER_HEADER. Следовательно, этим способом нельзя найти экземпляры _FILE_OBJECT. Кроме того, начиная с Windows 2003 структура _DISPATCHER_HEADER была расширена до 10 членов вместо 6, а версия для Windows 7 содержит почти 30. При таком количестве членов нет уверенности, что они останутся достаточно постоянными для построения сигнатуры.

И заголовки пулов, и заголовки диспетчера несущественны для операционной системы, а значит, могут быть вредоносно изменены для противодействия сканированию по сигнатурам без нарушения стабильности системы. Однако существует другой подход к поиску объектов в дампах памяти, устойчивый к таким изменениям. Брендан Долан-Гэвитт и его коллеги описали методику в работе Robust Signatures for Kernel Data Structures (cc.gatech.edu). Они подвергали операционную систему фаззингу, изменяя отдельные члены _EPROCESS и фиксируя, какие изменения приводили к сбою системы. Такие члены помечались как существенные. Затем сигнатура строилась только на существенных членах.

Пример плагина Volatility psscan3 (cc.gatech.edu) был разработан и распространён вместе с работой. Ниже кратко перечислено, что Долан-Гэвитт и его коллеги считали надёжной сигнатурой объектов _EPROCESS.

• Выравнивание DTB. DirectoryTableBase должна быть выровнена по 32-битной границе.

• Флаги предоставленного доступа. В члене GrantedAccess должны быть установлены флаги 0x1F07FB.

• Допустимость указателей. Члены VadRoot, ObjectTable, ThreadListHead и ReadyListHead должны содержать допустимые адреса режима ядра.

• Список рабочего набора. Член VmWorkingSetList должен не только указывать в режим ядра, но и находиться выше 0xC0000000 для 32-разрядных систем.

• Счётчики блокировок. Счётчики WorkingSetLock и AddressCreationLock должны быть равны 1.

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

Ваши цели таковы:

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

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

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

• Обнаружение Direct Kernel Object Manipulation (DKOM). Выявлять попытки скрыть процессы изменением одного или нескольких списков процессов в памяти ядра. В частности, вы изучите семь различных способов поиска процессов в дампах памяти, что даёт огромное преимущество в противодействии руткитам.

Windows отслеживает процессы, назначая каждому уникальную структуру _EPROCESS, находящуюся в нестраничном пуле памяти ядра. Вот как она выглядит в 64-разрядной системе Windows 7:

Ключевые положения таковы:

• Pcb: блок управления процессом ядра (_KPROCESS). Эта структура находится в основании _EPROCESS и содержит несколько критически важных полей, включая DirectoryTableBase для преобразования адресов и время, которое процесс провёл в режиме ядра и пользовательском режиме.

• CreateTime: временная метка UTC, указывающая момент первого запуска процесса.

• ExitTime: временная метка UTC, указывающая момент завершения процесса. Для всё ещё работающих процессов это значение равно нулю.

• UniqueProcessId: целое число, уникально идентифицирующее процесс, также известное как PID.

• ActiveProcessLinks: двусвязный список, связывающий активные процессы на машине. Большинство API в работающей системе опирается на обход этого списка.

• SessionProcessLinks: ещё один двусвязный список, связывающий процессы одного сеанса.

• InheritedFromUniqueProcessId: целое число, задающее PID родительского процесса. После запуска процесса этот член не изменяется, даже если его родитель завершается.

• Session: этот член указывает на структуру _MM_SESSION_SPACE (см. главу 14), хранящую сведения о сеансе входа пользователя и объектах графического интерфейса (GUI).

• ImageFileName: часть имени исполняемого файла процесса. Поле хранит первые 16 символов ASCII, поэтому более длинные имена отображаются усечёнными. Чтобы получить полный путь к исполняемому файлу или увидеть имя Unicode, можно обратиться к соответствующему узлу VAD либо членам PEB (см. главу 7).

• ThreadListHead: двусвязный список, связывающий все потоки процесса; каждый элемент списка представляет собой _ETHREAD.

• ActiveThreads: целое число, указывающее количество активных потоков, работающих в контексте процесса. Процесс с нулём активных потоков, скорее всего, уже завершился.

• Peb: указатель на Process Environment Block (PEB). Хотя этот член (_EPROCESS.Peb) находится в режиме ядра, он указывает на адрес в пользовательском режиме. PEB содержит указатели на списки DLL процесса, текущий рабочий каталог, аргументы командной строки, переменные среды, кучи и стандартные дескрипторы.

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

Структура _EPROCESS содержит структуру _LIST_ENTRY с именем ActiveProcessLinks. У _LIST_ENTRY есть два члена: Flink, прямая ссылка, указывающая на _LIST_ENTRY следующей структуры _EPROCESS, и Blink, обратная ссылка, указывающая на _LIST_ENTRY предыдущей структуры _EPROCESS. Вместе эти элементы образуют цепочку объектов процессов, также называемую двусвязным списком (см. главу 2). На рис. 6-2 показано, как структуры _LIST_ENTRY связывают процессы.

Рисунок 6-2. Процессы связаны двусвязным списком, на который указывает PsActiveProcessHead

В работающей системе такие инструменты, как Process Explorer и Task Manager, опираются на обход двусвязного списка структур _EPROCESS. Для этой цели часто используется API NtQuerySystemInformation, однако к тем же данным обращаются и многие высокоуровневые API операционной системы.

Как кратко описано в разделе "Проблемы выбора профиля" главы 3, для вывода списка процессов Volatility сначала находит блок данных отладчика ядра (_KDDEBUGGER_DATA64). Затем он обращается к члену PsActiveProcessHead, указывающему на голову двусвязного списка структур _EPROCESS. В главе 5 мы также обсуждали подход сканирования пула.

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

Volatility предоставляет несколько команд для извлечения сведений о процессах:

• pslist находит и обходит двусвязный список процессов и выводит сводку данных. Обычно этот метод не способен показать завершённые или скрытые процессы.

• pstree берёт вывод pslist и форматирует его в виде дерева, чтобы можно было легко увидеть отношения родительских и дочерних процессов.

• psscan сканирует объекты _EPROCESS, а не полагается на связный список. Этот плагин также способен находить завершённые и исключённые из списка, то есть скрытые, процессы.

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

Ниже приведён пример команды pslist:

Первый столбец вывода, Offset(V), показывает виртуальный адрес структуры _EPROCESS в памяти ядра. Далее справа видны имя процесса или по крайней мере первые 16 символов, его PID, PID родителя, количество потоков, количество дескрипторов, идентификатор сеанса и время создания. По этим данным можно установить несколько интересных фактов:

• Работают три браузера - два экземпляра IEXPLORE.EXE и один firefox.exe, - почтовый клиент thunderbird.exe и Adobe Reader (AcroRd32.exe). Следовательно, эта машина, скорее всего, является клиентом или рабочей станцией, а не сервером. Кроме того, если подозревается клиентский вектор атаки, например скрытая загрузка или фишинговый эксплойт, разумно исследовать эти процессы на предмет связанных с инцидентом данных, поскольку велика вероятность причастности одного или нескольких из них.

• Все процессы, включая критические системные, работают в сеансе 0. Это указывает на старую машину с Windows XP или 2003, то есть до изоляции сеанса 0, и на то, что сейчас вошёл только один пользователь.

• У двух процессов AcroRd32.exe ноль потоков и недопустимый указатель таблицы дескрипторов, что показано штрихами. Если бы отображался столбец времени завершения, который мы убрали, чтобы строки не переносились на странице, было бы видно, что эти два процесса фактически завершились. Они "застряли" в списке активных процессов, потому что другой процесс имеет открытый дескриптор на них (см. The Mis-leading Active in PsActiveProcessHead: mnin.blogspot.com).

• Процесс с PID 2280 (a[1].php) имеет недопустимое для исполняемых файлов расширение и выдаёт себя за файл PHP. Кроме того, судя по времени создания, он временно связан с несколькими другими процессами, запущенными в ту же минуту (14:19:XX), включая командную оболочку cmd.exe.

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

При просмотре процессов в виде дерева гораздо легче определить возможные события атаки. Видно, что firefox.exe с PID 180 был запущен explorer.exe с PID 1300. Это нормально: когда приложение запускается из меню Start или двойным щелчком по значку на рабочем столе, его родителем является Windows Explorer. Браузеры также довольно часто создают экземпляры Adobe Reader (AcroRd32.exe) для отображения PDF-документов, открытых через Интернет. Ситуация становится интересной, когда AcroRd32.exe вызывает командную оболочку (cmd.exe), которая затем запускает a[1].php. На этом этапе можно предположить, что веб-страница, посещённая в Firefox, заставила браузер открыть вредоносный PDF. Эксплуатация уязвимости в AcroRd32.exe позволила злоумышленнику воспользоваться командной оболочкой для дальнейшей установки вредоносного ПО в системе.

Ещё один способ визуализировать отношения между родительскими и дочерними процессами - использовать команду psscan с визуализатором графов dot (--output=dot). Эта возможность основана на инструменте PTFinder Андреаса Шустера (dfrws.org), который также создавал графы для визуального анализа. Поскольку такое представление процессов основано на сканировании пула в физическом адресном пространстве, оно включает в граф и завершённые, и скрытые процессы. Граф можно создать так:

Затем откройте выходной файл в Graphviz (graphviz.org), как показано на рис. 6-3.

По графу можно подтвердить несколько ранее обсуждавшихся утверждений. Например, System запускает smss.exe, который запускает csrss.exe и winlogon.exe в системах Windows XP и 2003. Затем видно, как winlogon.exe создаёт services.exe и lsass.exe. Процесс SCM, в свою очередь, создаёт spoolsv.exe и различные экземпляры svchost.exe. Но это лишь часть картины. Остальная часть графа показана на рис. 6-4.

Как видно, процесс с PID 1188 запустил explorer.exe, но его _EPROCESS больше не находится в памяти, поэтому дополнительные сведения, например имя родительского процесса, недоступны. Это типично для систем XP и 2003, поскольку userinit.exe запускает Explorer и вскоре завершается. Если проследить остальные стрелки, схема подтверждает версии, сформированные при изучении вывода pstree.

Рисунок 6-3. Граф, созданный psscan и показывающий отношения критических системных процессов

Рисунок 6-4. Схема процессов, участвовавших в эксплуатации вредоносного PDF, доставленного через Интернет

С помощью Direct Kernel Object Manipulation (DKOM) возможно множество атак, но одна из наиболее распространённых - сокрытие процесса путём исключения его записи из двусвязного списка. Для этого указатели Flink и Blink окружающих объектов перезаписываются так, чтобы они обходили структуру _EPROCESS скрываемого процесса. Инструменты, выполняемые в работающей системе, и команда Volatility pslist уязвимы к этой атаке, поскольку опираются на связный список. Однако плагин psscan использует подход сканирования пула, описанный в главе 5. Благодаря этому объекты _EPROCESS можно находить в памяти, даже если они исключены из списка.

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

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

• отобразить доступное для записи представление объекта \Device\PhysicalMemory; однако начиная с Windows 2003 SP1 и Vista доступ к этому объекту из программ пользовательского режима ограничен;

• использовать специальную нативную функцию API ZwSystemDebugControl.

Чтобы показать, как psscan используется для поиска скрытых процессов, сосредоточимся на образце вредоносной программы, известном антивирусным поставщикам как Prolaco (см. avira.com). Эта вредоносная программа выполняет DKOM полностью из пользовательского режима, не загружая драйверы ядра. Для этого она применяет API ZwSystemDebugControl почти точно так, как описал Алекс Ионеску на сайте OpenRCE (openrce.org). На рис. 6-5 показан декомпилированный код Prolaco, полученный с помощью IDA Pro и Hex-Rays.

По изображению можно сделать следующие выводы о выполнении DKOM вредоносной программой:

• Она включает привилегию отладки (SeDebugPrivilege), предоставляющую процессу доступ, необходимый для использования ZwSystemDebugControl.

• Она вызывает NtQuerySystemInformation с классом SystemModuleInformation, чтобы найти базовый адрес модуля ядра NT.

• Она находит PsInitialSystemProcess - экспортируемую модулем NT глобальную переменную, указывающую на объект _EPROCESS первого процесса.

• Она обходит связный список объектов _EPROCESS, пока не найдёт процесс с PID, совпадающим с PidOfProcessToHide. Фиксированное число 0x88, используемое внутри цикла while, представляет собой смещение ActiveProcessLinks внутри структуры _EPROCESS в 32-разрядных системах Windows XP. Обратите также внимание, что PidOfProcessToHide передаётся функции как параметр. Вредоносная программа получает это значение с помощью GetCurrentProcessId, а значит, пытается скрыть саму себя.

• Она вызывает WriteKernelMemory, которая представляет собой лишь оболочку вокруг ZwSystemDebugControl, записывающую по четыре байта за раз по указанному адресу в памяти ядра. Функция вызывается один раз для перезаписи указателя Flink и один раз для указателя Blink. Содержимое этой функции показано на рис. 6-6.

Рисунок 6-5. Образец Prolaco, загруженный в IDA с Hex-Rays; показана основная функция DKOM

Рисунок 6-6. Вызов ZwSystemDebugControl, использованный для перезаписи указателей в памяти ядра

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

Как уже говорилось, основывать выводы только на одном доказательстве - плохая идея. Поскольку списком процессов можно манипулировать, следует знать доступные резервные методы, или альтернативные списки процессов. Вот некоторые из них:

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

• Сканирование потоков. Поскольку у каждого процесса должен быть как минимум один активный поток, можно сканировать объекты _ETHREAD, а затем сопоставлять их с владеющим процессом. Для сопоставления используется член _ETHREAD.ThreadsProcess в Windows XP и 2003 либо _ETHREAD.Tcb.Process в Windows Vista и более поздних версиях. Поэтому даже если руткит изменит теги пула процесса, чтобы скрыться от psscan, ему также придётся изменить теги пула всех потоков процесса.

• Таблица дескрипторов CSRSS. Как упоминалось в описании критических системных процессов, csrss.exe участвует в создании каждого процесса и потока, за исключением самого себя и процессов, запущенных до него. Поэтому можно обойти таблицу дескрипторов этого процесса, как описано далее в главе, и таким способом выявить все объекты _EPROCESS.

• Таблица PspCid. Это специальная таблица дескрипторов в памяти ядра, хранящая ссылку на все активные объекты процессов и потоков. Член PspCidTable структуры данных отладчика ядра указывает на эту таблицу. Два инструмента обнаружения руткитов, Blacklight и IceSword, использовали таблицу PspCid для поиска скрытых процессов. Однако автор FUTo (см. openrce.org) доказал, что скрыться всё равно можно, удалив процессы из таблицы.

• Процессы сеанса. Член SessionProcessLinks структуры _EPROCESS связывает все процессы, принадлежащие определённому сеансу входа пользователя. Исключить процесс из этого списка не сложнее, чем из списка ActiveProcessLinks. Но поскольку API действующей системы от него не зависят, злоумышленники редко видят смысл атаковать его.

• Потоки рабочего стола. Одна из структур, рассматриваемых в главе 14, - Desktop (tagDESKTOP). Эти структуры хранят список всех потоков, связанных с каждым рабочим столом, а поток легко сопоставить с владеющим процессом.

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

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

Плагин psxview выводит по одной строке для каждого найденного процесса и семь столбцов со значениями True или False в зависимости от того, был ли процесс найден соответствующим методом. Если указать параметр --apply-rules, в столбцах может также появиться Okay: это означает, что хотя процесс не был найден, он соответствует одному из допустимых исключений из следующего списка:

• Процессы, запускаемые до csrss.exe, включая System, smss.exe и сам csrss.exe, отсутствуют в таблице дескрипторов CSRSS.

• Процессы, запускаемые до smss.exe, включая System и smss.exe, отсутствуют в списках процессов сеанса и потоков рабочего стола.

• Завершённые процессы не будут найдены ни одним методом, кроме сканирования объектов процессов и сканирования потоков, если _EPROCESS или _ETHREAD всё ещё остаётся резидентным в памяти.

Пример вывода psxview с параметром --apply-rules показан на рис. 6-7. Последние два процесса, msiexec.exe и rundll32.exe, обнаружены только сканером объектов процессов. Однако, как видно в крайнем правом столбце, оба имеют ненулевое время завершения, а значит, завершились.

Рисунок 6-7. Вывод psxview после применения правил учёта исключений

Как показано на рисунке, после учёта правил выделяется только процесс 1_doc_RCData_61.exe: он найден всеми методами, кроме связного списка активных процессов. Это явный признак того, что процесс пытается скрыться от API действующей системы, исключив себя из списка.

Токен процесса описывает его контекст безопасности. Этот контекст включает идентификаторы безопасности (SID) пользователей или групп, от имени которых работает процесс, и различные привилегии, то есть конкретные задачи, которые ему разрешено выполнять. Когда ядру требуется решить, может ли процесс обратиться к объекту или вызвать определённый API, оно проверяет данные токена процесса. Поэтому эта структура определяет многие связанные с безопасностью средства контроля, затрагивающие процессы. В этом разделе описано, как использовать токены для углубления расследований.

Ваши цели таковы:

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

• Обнаружение бокового перемещения. При успешном применении таких хакерских методик, как pass-the-hash (microsoft.com), в токене процесса остаются явные артефакты. В частности, видно, как контекст безопасности процесса переключается на контекст Domain Admin или Enterprise Admin.

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

• Обнаружение повышения привилегий. Некоторые атаки показали, что такие инструменты действующей системы, как Process Explorer, можно обмануть, заставив сообщать о меньшем количестве привилегий процесса, чем у него имеется на самом деле. Криминалистический анализ памяти позволяет точнее установить истину.

Структура _TOKEN велика, поэтому мы не будем показывать все её члены. Кроме того, способ хранения сведений о привилегиях существенно изменился между Windows 2003 и Vista. Сначала следующий код показывает более ранние версии структур из 64-разрядной системы 2003:

Ниже приведены эквивалентные структуры для 64-разрядной Windows 7:

Ключевые положения таковы:

• UserAndGroupCount: это целое число хранит размер массива UserAndGroups.

• UserAndGroups: массив структур _SID_AND_ATTRIBUTES, связанных с токеном. Каждый элемент массива описывает отдельного пользователя или группу, в которую входит процесс. Член Sid структуры _SID_AND_ATTRIBUTES указывает на структуру _SID, члены IdentifierAuthority и SubAuthority которой можно объединить, чтобы получить строки SID вида S-1-5-[snip].

• PrivilegeCount (только Windows XP и 2003): это целое число хранит размер массива Privileges.

• Privileges (Windows XP и 2003): массив структур _LUID_AND_ATTRIBUTES, каждая из которых описывает отдельную привилегию и её атрибуты, то есть присутствует ли она, включена ли и включена ли по умолчанию.

• Privileges (Windows Vista и более поздние): экземпляр _SEP_TOKEN_PRIVILEGES с тремя параллельными 64-разрядными значениями Present, Enabled и EnabledByDefault. Позиции битов соответствуют определённым привилегиям, а состояние бита, включён или выключен, описывает состояние привилегии.

На работающей машине процесс может обратиться к собственному токену через API OpenProcessToken. Для перечисления SID или привилегий он затем может вызвать GetTokenInformation с нужными параметрами. Имея административный доступ, он также может запрашивать или задавать токены процессов других пользователей, включая критические системные. Разумеется, готовые инструменты, например Sysinternals Process Explorer, уже предоставляют такую функциональность. На рис. 6-8 показаны сведения токена explorer.exe. Данные SID расположены вверху, а данные привилегий - на нижнем уровне.

Рисунок 6-8. Вкладка Security Process Explorer показывает сведения SID и привилегий из токена процесса

Этот экземпляр explorer.exe принадлежит пользователю Jimmy со строкой SID S-1-5-21-[snip]-1000. Анализ остальных SID в токене процесса показывает, что он также входит в группы Everyone, LOCAL и NT AUTHORITY\Authenticated Users. В токене присутствуют пять привилегий, но сейчас включена только одна. На следующих страницах эти понятия рассматриваются подробнее.

Только что описанные API действующей системы удобны для перечисления SID в работающих системах. Windows также предоставляет API ConvertSidToStringSid, преобразующий числовые данные структуры _SID в удобочитаемый формат S-1-5-[snip], и LookupAccountSid, возвращающий имя учётной записи для заданного SID. Однако поскольку мы работаем с дампами памяти, именно Volatility, в частности плагин getsids, отвечает за поиск токена каждого процесса, извлечение числовых компонентов структуры _SID и преобразование их в строки. После этого строки сопоставляются с именами пользователей и групп на локальном компьютере или в домене.

Сопоставление можно выполнить несколькими способами. Во-первых, известные SID (см. support.microsoft.com) жёстко заданы в Windows, поэтому их можно жёстко задать и в плагине Volatility. К ним относятся такие SID, как S-1-5 (NT Authority) и S-1-5-32-544 (Administrators). Имеются также SID служб с префиксом S-1-5-80. Остальная часть SID в этом случае состоит из хеша SHA1 соответствующего имени службы в Unicode и верхнем регистре; алгоритм подробнее описан здесь: volatility-labs.blogspot.com.

Наконец, существуют SID пользователей, например S-1-5-21-4010035002-774237572-2085959976-1000. Они разбиваются на следующие компоненты:

• S: префикс, указывающий, что строка является SID;

• 1: уровень редакции, то есть версия спецификации SID, из _SID.Revision;

• 5: значение центра идентификации из _SID.IdentifierAuthority.Value;

• 21-4010035002-774237572-2085959976: идентификатор локального компьютера или домена из значений _SID.SubAuthority;

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

Строку SID можно сопоставить с именем пользователя, запросив реестр. Следующая команда показывает пример:

Добавив строку SID к ключу реестра ProfileList, можно увидеть значение ProfileImagePath. Имя пользователя определяется в пути профиля. В данном случае пользователя звали nkESis3ns88S: это была случайно сформированная учётная запись-бэкдор, созданная злоумышленником для сохранения доступа к системе.

Если требуется связать процесс с учётной записью пользователя или исследовать возможные попытки бокового перемещения, используйте плагин getsids. Следующий вывод взят из криминалистического задания GrrCON Джека Крука (см. michsec.org).

Эта команда показывает SID, связанные с explorer.exe текущего вошедшего пользователя. Сразу заметно, что рядом с одним SID (S-1-5-21-[snip]-1115) не отображается имя учётной записи. В системах, не проходящих аутентификацию в домене, рядом с SID видно имя локального пользователя. Однако в данном случае Volatility не имеет доступа к реестру удалённой машины, то есть контроллера домена или сервера Active Directory, и потому не может выполнить разрешение.

С помощью getsids можно ответить на вопрос: какой уровень доступа получил злоумышленник? Не останавливайтесь, увидев, что explorer.exe входит в группу Administrators. Злоумышленник на этой машине фактически вошёл в группы Domain Admins и Enterprise Admins, что позволило ему перемещаться вбок по всей корпоративной сети. В этом сценарии злоумышленник совместил троян удалённого доступа (RAT) Poison Ivy (PI) с атакой Pass the Hash (PtH). Полный анализ атаки приведён по адресу volatility-labs.blogspot.com.

Привилегии - ещё один критически важный компонент безопасности и контроля доступа. Привилегия представляет собой разрешение выполнить определённую задачу, например отладить процесс, выключить компьютер, изменить часовой пояс или загрузить драйвер ядра. Прежде чем процесс сможет включить привилегию, она должна присутствовать в его токене. Администраторы определяют присутствующие привилегии, настраивая их в Local Security Policy (LSP), как показано на рис. 6-9, или программно вызывая LsaAddAccountRights. Открыть LSP можно, выбрав Start > Run и введя SecPol.msc.

Рисунок 6-9. Администраторы могут настраивать привилегии с помощью редактора Local Security Policy

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

• Включение по умолчанию. LSP может задать включение привилегий по умолчанию при запуске процесса.

• Наследование. Если не указано иное, дочерние процессы наследуют контекст безопасности создателя, то есть родителя.

• Явное включение. Процесс может явно включить привилегию с помощью API AdjustTokenPrivileges.

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

• SeBackupPrivilege: предоставляет доступ на чтение любого файла файловой системы независимо от заданного списка контроля доступа (ACL). Злоумышленники могут использовать эту привилегию для копирования заблокированных файлов.

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

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

• SeLoadDriverPrivilege: предоставляет возможность загружать или выгружать драйверы ядра.

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

• SeShutdownPrivilege: позволяет вызывающей стороне перезагрузить или выключить систему. Некоторые заражения, например изменяющие главную загрузочную запись (MBR), не активируются до следующей загрузки системы. Поэтому часто можно увидеть, как вредоносная программа пытается вручную ускорить процедуру, вызвав перезагрузку.

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

Ниже приведён вывод плагина Volatility privs. В нём показано имя привилегии и её атрибуты: присутствует, включена и/или включена по умолчанию.

В выводе присутствуют несколько привилегий. Включены лишь шесть из них, причём три включены по умолчанию. Следовательно, можно заключить, что explorer.exe явно включил привилегии отключения от док-станции, отладки и загрузки драйверов. Со временем вы заметите, что explorer.exe всегда включает привилегию отключения от док-станции, поэтому она не вызывает беспокойства. Но зачем Windows Explorer отлаживать другие процессы и загружать драйверы ядра? Ответ прост: незачем. Этот процесс содержит внедрённый образец Poison Ivy (PI), и именно PI явно включил привилегии.

Как уже упоминалось, Windows API AdjustTokenPrivileges не позволяет и не должен позволять включать привилегию, отсутствующую в токене. Поэтому логично, что такие API, как GetTokenInformation, и основанные на них инструменты сначала проверяют присутствующие привилегии, а затем возвращают включённое подмножество. Но есть одна тонкость: талантливый исследователь Сесар Серрудо обнаружил, что, проверяя способность процесса выполнить задачу, ядро учитывает только включённые привилегии. Поэтому в своей работе Easy Local Windows Kernel Exploitation (см. blackhat.com) Сесар предложил способ обойти API Windows и включить процессу все привилегии, даже отсутствующие в его токене.

Атака Сесара основана на подходе DKOM. Он находит структуру _SEP_TOKEN_PRIVILEGES целевого процесса и устанавливает 64-разрядный член Enabled в 0xFFFFFFFFFFFFFFFF. Тем самым включаются все возможные привилегии. Член Present он не обновляет, поэтому тот отражает только привилегии, присутствовавшие до атаки. Эти действия можно имитировать, изменяя память VM посредством Volatility в режиме записи. После завершения возобновите работу VM, и изменения вступят в силу. Это проще, чем писать драйвер ядра, особенно если он нужен лишь для тестирования.

Теперь, находясь в контексте целевого процесса, получите указатель на его структуру _TOKEN. Затем можно вывести 64-разрядные числа как двоичные строки:

Следующие команды устанавливают все биты члена Enabled и снова выводят значения, подтверждая обновление. Затем можно выйти из оболочки.

На рис. 6-10 показано, как структура данных ядра выглядит после манипуляции.

Рисунок 6-10. Все биты члена Enabled установлены прямым изменением структуры в памяти ядра

Согласно предыдущему выводу volshell и рис. 6-10, в члене Present установлено лишь пять битов, а значит, инструменты, работающие в действующей системе, сообщат не более чем о пяти привилегиях. На рис. 6-11 показано, как это выглядит в Process Explorer.

Рисунок 6-11. Process Explorer обманут и сообщает, что включены только пять привилегий

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

Однако если проанализировать дамп памяти VM с помощью плагина privs, который использует не ту же логику, что Windows API, будет видно, что включены все привилегии, хотя многие из них даже не присутствуют, чего происходить не должно. Следовательно, explorer.exe способен выполнить любую желаемую задачу, тогда как инструменты действующей системы продолжают сообщать, что таких возможностей нет.

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

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

Прежде чем процесс сможет обратиться к объекту, он открывает его дескриптор вызовом такого API, как CreateFile, RegOpenKeyEx или CreateMutex. Эти API возвращают специальный тип данных Windows HANDLE, который представляет собой просто индекс в таблице дескрипторов конкретного процесса. Например, при вызове CreateFile указатель на соответствующий _FILE_OBJECT в памяти ядра помещается в первый свободный слот таблицы дескрипторов вызывающего процесса, а соответствующий индекс, например 0x40, возвращается. Кроме того, счётчик дескрипторов объекта увеличивается. Затем вызывающий процесс передаёт значение HANDLE функциям, выполняющим операции с объектом: чтение, запись, ожидание или удаление. Поэтому такие API, как ReadFile и WriteFile, работают следующим образом:

1. Найти базовый адрес таблицы дескрипторов вызывающего процесса.

2. Перейти к индексу 0x40.

3. Получить указатель _FILE_OBJECT.

4. Выполнить запрошенную операцию.

Когда процесс заканчивает работу с объектом, он должен закрыть дескриптор вызовом соответствующей функции, например CloseHandle или RegCloseHandle. Эти API уменьшают счётчик дескрипторов объекта и удаляют указатель на объект из таблицы дескрипторов процесса. После этого индекс таблицы дескрипторов можно использовать заново для хранения объекта другого типа. Однако фактический объект, то есть _FILE_OBJECT, не будет освобождён или перезаписан, пока счётчик дескрипторов не достигнет нуля. Это не позволяет одному процессу удалить объект, который сейчас используется другим процессом.

До сих пор в этом разделе сущностями, взаимодействующими с объектами через дескрипторы, мы называли процессы. Однако модули ядра или потоки режима ядра могут сходным образом вызывать эквивалентные API ядра, например NtCreateFile, NtReadFile и NtCreateMutex. В таком случае дескрипторы выделяются из таблицы дескрипторов процесса System с PID 4. Поэтому при выгрузке дескрипторов процесса System фактически видны все открытые сейчас ресурсы, запрошенные модулями ядра.

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

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

Ваши цели таковы:

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

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

• Открытые расследования. Даже без конкретного исходного списка индикаторов анализ содержимого таблицы дескрипторов даёт множество сведений о поведении и намерениях неизвестного процесса.

• Обнаружение закрепления в реестре. Научиться анализировать открытые дескрипторы реестра, чтобы определить, в каких ключах процесс хранит конфигурацию или данные закрепления.

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

Член _EPROCESS.ObjectTable каждого процесса указывает на таблицу дескрипторов (_HANDLE_TABLE). У этой структуры имеется TableCode, выполняющий две критически важные функции: он задаёт количество уровней таблицы и указывает на базовый адрес первого уровня. Все процессы начинают с одноуровневой таблицы, показанной на рис. 6-12. Размер таблицы равен одной странице, то есть 4096 байт, и такая схема поддерживает до 512 дескрипторов в 32-разрядной системе или 256 в 64-разрядной. Используемые индексы таблицы содержат структуры _HANDLE_TABLE_ENTRY, а неиспользуемые обнулены.

Записи таблицы дескрипторов содержат член Object, указывающий на _OBJECT_HEADER соответствующего объекта. Переходя по этим полям, можно найти и имя объекта, и его тело, например _FILE_OBJECT или _EPROCESS.

Некоторым процессам требуется больше открытых дескрипторов, чем допускает одноуровневая таблица. Поэтому Windows может по требованию расширить схему до трёх уровней. Например, в двухуровневой таблице первый уровень по-прежнему представляет собой 4096-байтовый блок памяти, но разделён на 1024 слота в 32-разрядной системе или 512 слотов в 64-разрядной. Каждый слот хранит указатель на массив структур _HANDLE_TABLE_ENTRY. Следовательно, на 32-разрядной платформе двухуровневая таблица дескрипторов поддерживает до 1024 * 512 = 524 288 дескрипторов.

Рисунок 6-12. Схема одноуровневой таблицы дескрипторов

Аналогично, трёхуровневая таблица в 32-разрядной системе теоретически поддерживает 1024 * 1024 * 512 = 536 870 912 дескрипторов. Однако, как описано в статье Pushing the Limits of Windows: Handles (blogs.technet.com), наблюдаемые ограничения на деле намного ниже. Во-первых, ядро обеспечивает жёстко заданный предел около 16 миллионов. Кроме того, любой процесс, которому одновременно требуется более нескольких тысяч открытых дескрипторов, вероятно, страдает утечкой таблицы дескрипторов, то есть забывает закрывать их. Поэтому жёстко заданный максимум служит ранним индикатором плохо написанных приложений.

Следующий вывод показывает структуру таблицы дескрипторов и записи таблицы дескрипторов в 64-разрядных системах Windows 7:

Ключевые положения для _HANDLE_TABLE таковы:

• TableCode: это значение сообщает количество уровней таблицы и указывает на адрес таблицы верхнего уровня. Двойное назначение достигается битовой маской семь (7). Например, для получения количества таблиц можно вычислить TableCode & 7, а для получения адреса - TableCode & ~7.

• QuotaProcess: указатель на процесс, которому принадлежит таблица дескрипторов. Он полезен, если таблицы дескрипторов находятся посредством сканирования пула, описанного в главе 5, а не перечислением процессов и переходом по их указателю ObjectTable.

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

• HandleCount: общее количество записей таблицы дескрипторов, используемых процессом в настоящий момент. Это поле было удалено начиная с Windows 8 и Server 2012.

Ключевые положения для _HANDLE_TABLE_ENTRY таковы:

• Object: этот член указывает на _OBJECT_HEADER соответствующего объекта. _EX_FAST_REF - специальный тип данных, объединяющий сведения счётчика ссылок в младших значащих битах указателя.

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

Плагин Volatility handles формирует вывод, обходя структуры данных таблицы дескрипторов. При использовании без параметров этот плагин выдаёт наиболее подробный результат: все дескрипторы всех типов объектов во всех процессах. Поэтому следует знать несколько параметров фильтрации:

• Фильтр по идентификатору процесса. Параметру -p/--pid можно передать один или несколько разделённых запятыми идентификаторов процессов.

• Фильтр по смещению процесса. Параметру -o/--offset можно передать физическое смещение структуры _EPROCESS.

• Фильтр по типу объекта. Если интересует только определённый тип объектов, например файлы или ключи реестра, соответствующие имена можно задать параметром -t/--object-type. Полный список типов объектов приведён в главе 5; его также можно увидеть, введя !object \ObjectTypes в WinDBG.

• Фильтр по имени. Имена имеются не у всех объектов. Безымянные объекты очевидно бесполезны при поиске индикаторов по имени, поэтому шум можно уменьшить параметром --silent, подавляющим дескрипторы безымянных объектов.

Следующий вывод показывает первые несколько дескрипторов PID 632 (winlogon.exe). Дамп памяти взят из старой 32-разрядной системы XP, заражённой Zeus (code.google.com). Однако обнаружить заражение трудно, поскольку у процесса около 550 открытых дескрипторов различных типов объектов, вывод которых сокращён для краткости, и не все из них можно сразу распознать.

Как показано в следующем примере, поиск можно ограничить файлами и мьютексами, открытыми PID 632, и игнорировать безымянные объекты. Хотя и после этого будет видно около 150 элементов в данном дампе памяти, хорошо известные артефакты Zeus распознать намного проще. Например, видны файлы user.ds и local.ds, содержащие конфигурацию и похищенные данные. Файл sdra64.exe в каталоге system32 - первоначальный установщик Zeus.

Можно также заметить несколько открытых дескрипторов \Device\Tcp и \Device\Ip. Они явно отличаются от дескрипторов файлов с префиксом \Device\HarddiskVolume1. В частности, Tcp и Ip - не файлы на жёстком диске машины. Это описано в главе 11, но по существу здесь видны артефакты сетевых сокетов, созданных процессом. Хотя сокеты не являются файлами, они поддерживают сходные операции: открытие, чтение, запись и удаление. Поэтому одна подсистема дескрипторов способна обслуживать и файлы, и сетевые сокеты.

Аналогично, именованные каналы также представлены как объекты файлов. Поэтому, если вредоносная программа создаёт именованный канал для межпроцессного взаимодействия или перенаправления вывода командной оболочки бэкдора в файл, можно определить участвующие процессы при условии, что известно имя созданного канала. В данном случае его легко распознать, поскольку имя используемого Zeus канала совпадает со стандартным мьютексом, который программа создаёт для обозначения своего присутствия в системе (_AVIRA_).

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

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

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

Многие противники используют такие команды, как net view и net use, чтобы исследовать окружающую сеть и подключать удалённые диски. Получение доступа на чтение к файловому серверу Server Message Block (SMB) компании или доступа на запись к различным рабочим станциям и серверам предприятия может привести к успешному боковому перемещению. Однако в таких случаях машина, выполняющая разведку, имеет открытые сетевые соединения с удалёнными системами и индикаторы этой активности в таблицах дескрипторов процессов.

Следующий пример показывает, как злоумышленник перемещается по сети, подключая два удалённых диска. Каталог Users системы с именем WIN-464MMR8O7GF подключается как P, а ресурс C$ системы LH-7J277PJ9J85I - как Q. Если ресурс ADMIN$ не защищён, злоумышленник может подключить и его тем же способом. После подключения дисков злоумышленник меняет текущий рабочий каталог командной оболочки на папку документов определённого пользователя.

Секрет поиска доказательств удалённых подключённых дисков в памяти состоит в поиске дескрипторов файлов с префиксами \Device\Mup и \Device\LanmanRedirector. MUP, Multiple Universal Naming Convention (UNC) Provider, - компонент режима ядра, направляющий запросы доступа к удалённым файлам по именам UNC соответствующему сетевому перенаправителю. В данном случае LanmanRedirector обслуживает протокол SMB.

Ниже показан пример вывода плагина handles на машине первого перехода, к которой злоумышленник получил доступ изначально. Система работала под управлением 64-разрядной Vista SP2.

Здесь имеются несколько обычных дескрипторов \Device\Mup, что нормально. Интерес представляют несколько выделенных в источнике дескрипторов, поскольку они фактически показывают букву локального диска, удалённое имя NetBIOS и имя ресурса или путь файловой системы. Также показаны два разных PID: 752 и 1544. В данном случае 752 - экземпляр svchost.exe, выполняющий службу LanmanWorkstation; он создаёт и поддерживает клиентские сетевые соединения с удалёнными серверами по протоколу SMB. PID 1544 - оболочка cmd.exe, имеющая дескриптор C$\Users\Jimmy\Documents вследствие перехода злоумышленника в этот каталог.

Другой способ обнаружить удалённые подключённые ресурсы, который можно совместить с методом дескрипторов, - исследовать символические ссылки плагином symlinkscan. Эти объекты ядра могут связывать букву диска, например Q или P, с перенаправленным путём. Например, вывод выглядит так:

Одно из преимуществ объединения методик состоит в том, что symlinkscan сообщает также точное время подключения удалённого ресурса. Включив его в временную шкалу или, что ещё лучше, извлекши историю команд злоумышленника из cmd.exe (см. главу 17), можно быстро ответить на множество вопросов о действиях, выполненных в системе или сети жертвы.

На рис. 7-1 показана высокоуровневая схема памяти процесса. У каждого процесса имеется собственное закрытое представление памяти в этом диапазоне. Поскольку верхняя граница диапазона различается между операционными системами, наивысшее значение обозначено просто как MmHighestUserAddress. Это символ модуля NT, который можно запросить в отладчике или плагине Volatility volshell. В общем случае он равен 0x7FFEFFFF в 32-разрядных системах без загрузочного параметра /3GB, 0xBFFEFFFF в 32-разрядных системах с /3GB и 0x7FFFFFEFFFF в 64-разрядных системах. Разумеется, не каждый процесс, да и вообще ни один процесс, заполняет всё это адресное пространство, однако даже небольшая использованная доля всё равно представляет собой значительный объём данных.

Рисунок 7-1. Высокоуровневая схема типичного содержимого памяти процесса

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

• Динамически подключаемые библиотеки (DLL). Эта область представляет разделяемые библиотеки (DLL), загруженные в адресное пространство намеренно самим процессом или принудительно посредством внедрения библиотеки.

• Переменные среды. Этот диапазон памяти хранит переменные среды процесса, например пути к исполняемым файлам, временные каталоги, домашние папки и прочее.

• Process Environment Block (PEB). Чрезвычайно полезная структура, сообщающая, где находятся некоторые другие элементы списка, включая DLL, кучи и переменные среды. Она также содержит аргументы командной строки процесса, текущий рабочий каталог и стандартные дескрипторы.

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

• Стеки потоков. Для каждого потока выделен отдельный диапазон памяти процесса под стек времени выполнения. Здесь находятся аргументы функций, адреса возврата, позволяющие восстановить историю вызовов, и локальные переменные.

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

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

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

Рисунок 7-2. Схема связей вызовов Windows API, используемых для выделения памяти процесса

Эта схема API помогает представить, как все функции в конечном счёте приводят к NtAllocateVirtualMemory. Слушатели наших занятий часто спрашивают о различии между функцией C++ new и такими API, как VirtualAlloc. Как показано на схеме, обе в результате вызывают NtAllocateVirtualMemory, однако new сначала проходит через HeapAlloc, а значит, запрошенная память выделяется из одной из существующих куч процесса. Это полезно с теоретической точки зрения для знакомства с внутренним устройством памяти и с криминалистической точки зрения. Например, если вредоносная программа использует new и требуется впоследствии найти её содержимое, можно сосредоточиться на сегментах кучи, а не на всей памяти процесса.

В общем случае API на схеме различаются так, как описано в следующих разделах.

Лишь некоторые API позволяют программисту полностью управлять разрешениями выделяемой памяти. Например, VirtualAlloc позволяет указать, должна ли память быть недоступной, читаемой, записываемой, исполняемой, защищённой либо сочетать эти свойства. С другой стороны, кучи всегда доступны для чтения и записи, и отключить это нельзя. Однако можно управлять тем, будут ли данные в куче исполняемыми, передав параметр HEAP_CREATE_ENABLE_EXECUTE функции HeapCreate. Увы, это опасная возможность, поскольку она облегчает распыление кучи - один из наступательных методов, которому призвано противодействовать предотвращение выполнения данных (Data Execution Prevention, DEP).

VirtualAllocEx - единственная функция Windows API на схеме, которая позволяет одному процессу выделять память для другого процесса. Ex в названии означает Extra, поскольку функция принимает один дополнительный параметр, отсутствующий у VirtualAlloc, - открытый дескриптор целевого процесса. Эта функция часто используется как предварительный этап внедрения кода, потому что вредоносной программе требуется создать пространство в процессе-жертве.

Эти две функции виртуального выделения памяти также единственные, которые позволяют вызывающей стороне зарезервировать память (то есть отложить её) до фиксации. Это позволяет приложениям «сохранить» для последующего использования большую виртуально непрерывную область памяти, не занимая тем временем лежащие в её основе физические страницы. Дополнительные сведения см. в статье Reserving and Committing Memory: msdn.microsoft.com.

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

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

На рис. 7-3 показан охват данных, о которых сообщают эти плагины. Обратите внимание на большие белые промежутки, представляющие свободные или зарезервированные диапазоны. Видны также небольшие дыры в зафиксированных областях, указывающие на страницы, которые из-за выгрузки не являются резидентными в памяти.

Рисунок 7-3. Схема, показывающая, что плагин memdump получает все зафиксированные страницы, доступные процессу

Ниже приведён пример вывода memmap:

Обратите внимание на следующие особенности вывода этого плагина:

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

• Виртуальный адрес 0x7ffe0000 - это область KUSER_SHARED_DATA, блок памяти, созданный ядром и совместно используемый всеми процессами. Значение 0x7ffe0000 жёстко задано в Windows, поэтому от системы к системе оно не меняется. Если применить memmap к другим процессам, у всех будет видно идентичное отображение. Это один из способов перечисления разделяемых страниц (ещё один пример см. в разделе «Обнаружение разделяемых страниц» главы 17).

• После области KUSER_SHARED_DATA имеется большой промежуток. До адреса 0xff4c0000 никакие другие страницы недоступны. Эти виртуальные адреса либо не зафиксированы, либо выгружены.

• Хотя размер страницы по умолчанию в системе равен 4 Кбайт (0x1000 байт в шестнадцатеричном представлении), можно увидеть несколько страниц размером 0x200000, то есть 2 Мбайт. Это страницы Page Size Entry (PSE).

Ещё один ключевой элемент вывода memmap - столбец DumpFileOffset справа. Это значение задаёт смещение соответствующей страницы в файле, создаваемом плагином memdump. Поскольку адресные пространства процессов разрежены - между доступными страницами существуют дыры или промежутки, - выходной файл тоже является разреженным. Например, данные по виртуальному адресу 0xff4c1000 отображаются на физическое смещение 0x151b77000 (5,2 Гбайт), однако выходной файл этого процесса будет далеко не таким большим. Поэтому столбец DumpFileOffset сообщает, где в выходном файле найти содержимое адреса 0xff4c1000 (0x2a3000). Ниже приведён пример использования плагина memdump:

Как видно, полученный файл (864.dmp) имеет размер 434 Мбайт. Если с помощью volshell просмотреть содержимое по виртуальному адресу 0xff4c1000, его удастся сопоставить с данными по смещению 0x2a3000 файла 864.dmp. Выполним быструю проверку согласованности:

Теперь вы должны уметь определять, какие страницы доступны процессу и куда они отображаются в физической памяти. Вы знаете, как выгрузить доступную память в один файл на диске, который можно обрабатывать внешними средствами, например антивирусными сканерами. Не хватает лишь способности связывать адреса в виртуальной или физической памяти с именами отображённых файлов, DLL или исполняемых файлов, занимающих это пространство. Например, если сканер сообщает, что обнаружил известную вредоносную сигнатуру по смещению 0x2a3030 файла 864.dmp, при попытке дальнейшей классификации данных могут возникнуть трудности. Здесь и пригодятся VAD, которые мы рассмотрим далее.

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

Как показано на рис. 7-4, VAD представляет собой самобалансирующееся двоичное дерево (см. работу Брендана Долана-Гэвитта «The VAD Tree: A Process-Eye View of Physical Memory» по адресу dfrws.org). Каждый узел дерева представляет один диапазон виртуальной памяти процесса. Узел, описывающий диапазон памяти ниже родительского, находится слева, а узел, описывающий более высокий диапазон, - справа. Такая схема делает поиск, добавление и удаление более эффективными, чем в одно- или двусвязном списке.

Рисунок 7-4. Граф, созданный плагином vadtree, кодирует цветом диапазоны памяти процесса в зависимости от их содержимого

Эта схема создана плагином Volatility vadtree с параметром --render=dot, который подробнее рассматривается на следующих нескольких страницах. Помимо изображения связей между узлами VAD, плагин кодирует их цветом в зависимости от содержимого. Например, кучи процесса обозначаются красным, стеки потоков - зелёным, отображённые файлы - жёлтым, а DLL - серым; благодаря этому можно легко увидеть, данные какого типа отображены в память процесса.

Для каждого процесса _EPROCESS.VadRoot указывает на корень дерева VAD. Хотя имя этого члена остаётся неизменным во всех версиях Windows от XP до 8.1, тип члена часто менялся, как и имена узлов VAD. Различия приведены в табл. 7-1. Например, в Windows XP и 2003 Server VadRoot указывал на _MMVAD_SHORT, _MMVAD или _MMVAD_LONG. Ядро решает, какую именно структуру создать, на основании использованного для выделения памяти API и переданных ему параметров. В совокупности этих сведений достаточно, чтобы вывести предполагаемое назначение диапазона памяти - является ли он хранилищем отображённого файла, DLL или всего лишь частным выделением памяти. У каждого узла есть LeftChild и RightChild, которые направляют по различным путям дерева.

Как видно, начиная с Vista VadRoot был переработан в _MM_AVL_TABLE, а в Windows 8.1 снова изменился на _RTL_AVL_TREE. По пути узлы также перерабатывались трижды. Однако, несмотря на кажущиеся радикальными изменения, VAD всегда оставался деревом, а алгоритмы перечисления узлов оставались весьма похожими. Фактически, как подсказывает табл. 7-1, разные имена узлов в сущности являются лишь псевдонимами исходных структур _MMVAD[_SHORT,_LONG] из XP. При анализе деревьев VAD с помощью Volatility эти изменения обрабатываются прозрачно.

Таблица 7-1. Различные структуры VAD в разных версиях ОС

Ниже приведены соответствующие структуры из 64-разрядной системы Windows 7. Видно, что у _MM_AVL_TABLE есть член BalancedRoot, представляющий собой _MMADDRESS_NODE. У каждого узла имеется набор указателей на дочерние узлы, а также StartingVpn и EndingVpn. Из этих номеров виртуальных страниц (virtual page numbers, VPN) можно вывести адреса первой и последней страниц в виртуальной памяти целевого процесса. Мы сказали именно вывести, поскольку VPN - это номера страниц, а не адреса. Чтобы получить адрес, необходимо умножить номер страницы на размер страницы.

В табл. 7-1 _MMADDRESS_NODE назван псевдонимом, потому что на самом деле это одна из структур _MMVAD*. Обратите внимание в следующих листингах, что короткий узел (_MMVAD_SHORT) начинается с тех же самых членов, что и _MMADDRESS_NODE. Аналогично, обычный узел (_MMVAD) и длинный узел (_MMVAD_LONG) надстраиваются над меньшими структурами, но включают дополнительные члены в конце. В частности, они добавляют Subsection, который ОС использует для отслеживания сведений о файлах или DLL, отображённых в область:

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

После предыдущего обсуждения может возникнуть вопрос, как Volatility определяет, какая из трёх структур _MMVAD* скрывается под псевдонимом _MMADDRESS_NODE. Ответ заключён в члене Tag структур _MMVAD*. Обратите внимание, что на 64-разрядных платформах смещение этого члена равно -0xc (то есть он находится на 12 байт позади начала структуры). В типичных языках программирования, например C и C++, члены с отрицательными смещениями не встречаются. В действительности это удобный приём, допустимый при определении структур в Volatility. По существу, мы обращаемся к члену PoolTag структуры _POOL_HEADER, которая располагается в памяти непосредственно перед узлом. Как вы помните из главы 5, Windows назначает пулам теги, указывающие, данные какого типа они содержат. Соответствующие записи перечислены в табл. 7-2.

Таблица 7-2. Соответствие связанных с VAD тегов пула типам содержащихся структур

Области памяти, содержащие внедрённый шелл-код, не имеют резервного файла. Поэтому следует искать узлы с тегом VadS или VadF. Если экземпляр структуры узла находится в переменной vad (вскоре мы покажем, как перечислять узлы), значение можно легко вывести или проверить, обратившись в коде Python к vad.Tag.

Для исследования VAD Volatility предоставляет следующие плагины:

• vadinfo: показывает наиболее подробный вывод, включая начальный и конечный адреса, уровень защиты, флаги и полные пути к отображённым файлам или DLL.

• vadtree: в текстовом режиме этот плагин выводит узлы в виде дерева, позволяя увидеть связи родителей и потомков в консоли. Он также поддерживает создание графов с цветовой кодировкой, показанных на рис. 7-4.

• vaddump: извлекает диапазон памяти процесса, описываемый каждым узлом VAD, в отдельный файл на диске. В отличие от memmap (рассмотренного ранее), вывод этого плагина дополняется нулями, если какие-либо страницы диапазона выгружены на диск, чтобы сохранить пространственную целостность (смещения).

Ниже приведён пример вывода vadinfo для 64-разрядного образца Windows 7. Естественно, каждый процесс содержит сотни областей, поэтому для демонстрации мы выбрали лишь несколько.

Первая запись указывает, что узел VAD можно найти по адресу 0xfffffa80012184a0 в памяти ядра, а его тег - VadS, что означает тип структуры _MMVAD_SHORT. Этот узел описывает диапазон 0x50000 - 0x51fff в памяти процесса. Учитывая размер диапазона (две страницы), а также то, что MemCommit установлен и CommitCharge равен 2, вы знаете, что обе страницы были зафиксированы первым вызовом API виртуального выделения. Судя по защите, эта память доступна для чтения и записи, но не для выполнения.

Следующая запись похожа на первую тем, что это тоже короткий узел. Она описывает память в диапазоне 0x7f0e0000 - 0x7ffdffff, то есть около 15 Мбайт. Однако флаги CommitCharge и MemCommit отсутствуют, что фактически означает, что оба равны нулю. Следовательно, этот диапазон памяти всего лишь зарезервирован: ОС не связала его ни с какими физическими страницами.

Следующие два узла описывают диапазоны 0x4200000 - 0x4207fff и 0x77070000 - 0x77218fff в памяти процесса. Тег обоих узлов - Vad, то есть они используют одну из более крупных структур _MMVAD, позволяющих отображать файлы в область и затем совместно использовать их с другими процессами. Именно это здесь и видно: в этих местах находятся index.dat и ntdll.dll. Несмотря на сходство, исполняемым является лишь одно из отображений (для ntdll.dll). Это можно определить по защите PAGE_EXECUTE_WRITECOPY, типу VadImageMap и установленному биту Image во флагах управляющей области:

Плагин vadinfo прекрасно подходит для запроса подробных сведений о памяти процесса. Предположим, вы нашли интересующую область: либо узнали отображённый файл из своего списка индикаторов, либо обнаружили указатель или другой артефакт, направляющий вас к адресу внутри описываемого узлом диапазона. Следующий пример показывает, как с помощью volshell сопоставить сведения узла VAD об области (она должна содержать index.dat) с фактически находящимися там данными. Как видно, по адресу 0x4200000 в этом процессе действительно присутствует заголовок кэша URL-адресов истории IE:

Эту конкретную область можно выгрузить на диск, передав плагину vaddump параметр --base, как показано ниже:

По умолчанию, если не указывать --base, плагин выгружает все области в отдельные файлы, а затем именует их по местоположению в памяти процесса, где они были найдены. На рис. 7-5 показано, что извлекает этот плагин. Чтобы увидеть различия, схему можно сравнить с memmap на рис. 7-3. В частности, vaddump создаёт по одному дополненному нулями файлу для каждой области памяти процесса вместо одного уплотнённого файла, содержащего все адресуемые страницы памяти процесса и ядра.

Рисунок 7-5. Схема извлечения плагином vaddump каждой области в отдельный дополненный нулями файл

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

Многие плагины Volatility, извлекающие данные из памяти процесса, начинают с обхода дерева VAD. Например, svcscan находит записи служб Windows (глава 12), а cmdscan - истории команд (глава 17). Рано или поздно вам понадобится искать в памяти процесса другие артефакты, используя существующий плагин или создавая собственный. Следующие примеры демонстрируют некоторые API, способные упростить эту задачу, когда придёт время.

В первом примере показано, как перебрать VAD, прочитать заданный объём данных из каждого диапазона, найти в данных сигнатуру и вывести результаты. Обратите внимание: при вызове плагина volshell мы передаём -p 1080, поэтому начинаем в контексте процесса с PID 1080. Это лишь сокращённый способ вместо смены контекста командой cc(pid = 1080) уже внутри оболочки. Затем значение proc(), представляющее объект _EPROCESS для PID 1080, присваивается другой переменной с именем process - просто для удобства чтения. Адресное пространство процесса можно получить функцией get_process_address_space(), а затем использовать его для чтения памяти процесса:

Большую часть работы выполняет следующий цикл. Он использует API VadRoot.traverse() для создания объекта VAD для каждого узла дерева. Узлы определяют начальный и конечный номера страниц соответственно членами StartingVpn и EndingVpn. Однако для получения фактического адреса в памяти процесса их необходимо умножить на размер страницы. Всё это в фоновом режиме делают вспомогательные методы, которые Volatility присоединяет к объектам VAD. Например, Start() возвращает правильно вычисленный начальный адрес. Видно, что это значение передаётся функции read() адресного пространства:

Если чтение завершается успешно, в данных ищется сигнатура «MZ» (возможный исполняемый файл). Затем начальный адрес содержащего её диапазона выводится в консоль. Существуют другие плагины (например, dlllist, ldrmodules и malfind), автоматизирующие поиск исполняемых файлов по всей памяти процесса, а этот пример знакомит вас с реализацией простого поиска, способного дать полезные результаты. Обычно для найденных данных применяется постобработчик, который дополнительно проверяет их, извлекает на диск и так далее.

Недостаток предыдущего алгоритма в том, что он искал лишь в первых 1024 байтах каждого диапазона и сообщал только о нахождении одного шаблона. Существующая функция search_process_memory() принимает несколько входных значений, сканирует все доступные данные диапазона и сообщает адрес каждого совпадения. В следующем примере мы используем эти возможности для поиска паролей Gmail в памяти браузера Google Chrome. Если с помощью веб-прокси перехватить исходящие данные POST во время входа, можно заметить, что параметры POST включают &Email и &Passwd. Поэтому эти две строки становятся нашими критериями.

Как показано в следующем коде, мы запускаем volshell так же, как прежде, но для PID 3660 (chrome.exe). Переменная criteria - список, который заполняется версиями двух строк в Unicode (utf_16_le). Затем мы перебираем результаты, создаваемые search_process_memory(), и по каждому адресу создаём объект String:

Имя пользователя и пароль учётной записи находятся в памяти процесса в виде открытого текста даже при использовании SSL. Некоторые строки выглядят усечёнными, но лишь потому, что при создании объекта String мы задали максимальную длину 64. Как нетрудно представить, типы криминалистических данных, которые можно найти в памяти процесса, практически безграничны, как и возможности действий после обнаружения таких данных (в отношении постобработки, автоматизированного анализа и т. д.).

Yara - инструмент Виктора М. Альвареса (plusvic.github.io) для быстрого и гибкого сопоставления шаблонов в произвольных наборах данных. Иными словами, он работает с файлами, дампами памяти, захватами пакетов и так далее. Хотя физический файл дампа памяти можно легко просканировать целиком, помните, что смежные виртуальные адреса могут быть фрагментированы в физической памяти. Поэтому сигнатуры могут не совпасть с шаблонами, которые действительно существуют в памяти, если те пересекают границы страниц. Плагин Volatility yarascan позволяет сканировать виртуальную память, поэтому фрагментация на физическом уровне не создаёт проблемы. Кроме того, найденные совпадения можно связать с процессом или модулем ядра, владевшим памятью, что даёт контекст и мощную систему отсчёта.

Основные возможности плагина yarascan таковы:

• Сканирование одного, нескольких или всех процессов по заданной в командной строке сигнатуре (параметры --pid и --yara-rules).

• Сканирование скрытого процесса, заданного физическим смещением его _EPROCESS (--offset).

• Сканирование всего диапазона памяти ядра (--kernel) с выводом имени модуля ядра, если он существует.

• Любой из предыдущих вариантов, но с поиском сигнатур из предоставленного файла правил Yara (--yara-file). Аргумент этого параметра также может быть индексным файлом, включающим различные другие файлы.

• Необязательное извлечение на диск диапазонов памяти с положительными совпадениями (--dump-dir). Это экономит несколько шагов: вместо анализа результатов с последующим извлечением данных для дальнейшего исследования всё можно автоматизировать.

Ниже приведён полный вывод параметров командной строки этого плагина:

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

• IP-адреса (в строковой или десятичной форме), доменные имена или URL.

• Регулярные выражения для номеров социального страхования, номеров кредитных карт, телефонных номеров, дат рождения, хешей паролей и т. д.

• Сигнатуры упаковщиков. В рецепте 3-4 книги Malware Analyst’s Cookbook был приведён скрипт Python (peid_to_yara.py), преобразующий сигнатуры PEiD в правила Yara.

• Антивирусные сигнатуры. В рецепте 3-3 книги Malware Analyst’s Cookbook был приведён скрипт Python (clamav_to_yara.py), преобразующий сигнатуры ClamAV в правила Yara.

• Группа Google Yara Signature Exchange: deependresearch.org.

• Сигнатуры AlienVault Labs: github.com.

Например, чтобы просканировать все процессы на наличие определённого доменного имени, выполните следующую команду:

Чтобы просканировать два конкретных процесса на наличие Unicode-версии того же доменного имени, используйте эту команду (параметр --wide указывает, что строка поиска представлена в Unicode):

Чтобы просканировать отсоединённый или скрытый процесс с использованием всех сигнатур из заданного файла правил (а также любых файлов, подключённых директивой Yara include), выполните следующую команду, обязательно заменив OFFSET физическим смещением целевого _EPROCESS:

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

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

Теперь, когда вы увидели несколько примеров применения, посмотрим на вывод. Несколькими страницами ранее для поиска паролей Gmail в памяти браузера использовалась search_process_memory(). В этом примере применяется тот же дамп памяти, но с точки зрения Yara:

Ожидаемые результаты найдены в памяти PID 3660. По умолчанию yarascan показывает лишь предварительный фрагмент содержимого, вызвавшего срабатывание сигнатуры, однако объём показываемых или извлекаемых данных можно задавать параметром --size. Поскольку критерии поиска были заданы в командной строке, для всех совпадений указывается срабатывание универсального правила r1. Однако при наличии тысяч правил в файле правил выводилось бы имя правила, которое действительно совпало с данными.

До сих пор вы увидели три чрезвычайно мощные стороны анализа памяти: возможность классифицировать области памяти по их метаданным, разрабатывать сложные шаблоны и сканировать по ним, а также выполнять постобработку результатов пользовательским кодом Python. Следующий пример показывает, чего можно достичь, объединив эти возможности. В частности, вы узнаете, как найти 256-байтовый ключ шифрования RC4 Zeus в памяти процесса, обнаружить соответствующий зашифрованный блок конфигурации, а затем расшифровать конфигурацию с помощью ключа. Первоначальная версия этого анализа («Abstract Memory Analysis: Zeus Encryption Keys») доступна по адресу mnin.blogspot.com.

Прежде чем начать, следует немного знать об истории Zeus. Ближе к концу 2008 года (примерно с версии 1.2.0) Zeus стал использовать встроенные в каждый двоичный файл уникальные 256-байтовые ключи RC4 для расшифровки конфигураций. Это не позволяло аналитикам применять ключ одного образца для расшифровки конфигурации другого. Более того, если следователи находили конфигурацию, то без соответствующего двоичного файла расшифровать её не могли, даже зная, что алгоритм - RC4. Тот же принцип применялся к файлам похищенных Zeus данных, защищённым отдельным ключом RC4 (поэтому для восстановления всех данных требуются два ключа на каждый двоичный файл).

Первым шагом к автоматизации необходимых действий в плагине Volatility стал обратный анализ двоичного файла Zeus. На определение мест хранения ключей и данных конфигурации в двоичном файле ушло некоторое время, но после этого мы смогли сосредоточиться на их поиске в дампе памяти. На рис. 7-6 показан дизассемблированный код критически важных функций. Мы ищем последовательности инструкций, ссылающиеся на глобальные переменные двоичного файла, которые затем могут привести к ключу RC4, зашифрованным данным конфигурации и другим сведениям. Многие необходимые нам функции и переменные помечены.

Рисунок 7-6. Дизассемблированный код функций Zeus, ссылающихся на критически важные переменные для поиска и декодирования конфигурации

На рисунке видно, что функция с именем decode_config_data вызывает custom_memcpy, которая представляет собой лишь встроенную версию стандартного API memcpy. Второй параметр (источник копируемых данных) в данном случае передаётся инструкцией push offset config_data. Следовательно, переменная config_data содержит смещение относительно базы анализируемого исполняемого файла, по которому можно найти зашифрованные данные конфигурации. Аналогично видна функция с меткой rc4_decrypt. Как и ожидалось, один из параметров этой функции - местоположение ключа. Это смещение предоставляет инструкция push offset real_rc4_key.

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

Байты, хранящие смещение до ключа RC4, выделены полужирным. Найдя сигнатуру, ключ можно легко извлечь. Помните, что подстановочные знаки важны, поскольку из-за различий компиляторов двоичные файлы Zeus могут отличаться. Поэтому следует также искать кадры на основе EBP, например такие:

Функцию с именем decode_config_data можно выразить так:

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

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

В следующем выводе показаны результаты работы плагина zeusscan2, созданного на основе этого исследования. Ради краткости 256-байтовые ключи RC4 усечены до нескольких байтов. Среди прочих данных можно увидеть URL конфигурации Zeus, уникальный идентификатор, назначенный заражённой машине, и случайно сгенерированные ключи реестра и имена файлов, используемые для закрепления.

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

• Андреас Шустер (computer.forensikblog.de) построил свои сканеры конфигурации Poison Ivy на основе исходного плагина zeusscan2.

• Сантьяго Висенте позднее добавил поддержку поиска и расшифровки конфигураций Citadel (blog.buguroo.com) из памяти процесса.

• Брайан Баскин написал об извлечении конфигураций JavaRAT с помощью Volatility (ghettoforensics.com).

• Группа Cassidian CyberSecurity выпустила плагин для обнаружения и анализа образцов PlugX (bitbucket.cassidiancybersecurity.com).

• Мы также видели, как выпускники наших учебных курсов, в частности Иэн Ал, создавали похожие плагины для разработки сигнатур Yara, позволяющих находить DarkComet в памяти (tekdefense.com).

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

Ваши цели таковы:

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

• Анализ куч. Узнать, какие типы данных приложения хранят в своих кучах, и увидеть практический пример поиска текста, введённого в Notepad.

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

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

• Перечисление DLL. Узнать, как операционная система отслеживает DLL, загруженные процессом, а также какие API используются в живых системах для их перечисления. Одновременно вы увидите, как обнаруживать скрытые и отсоединённые библиотеки.

• Извлечение PE-файлов из памяти. Узнать, как выгружать PE-файлы из памяти и подготавливать их к статическому анализу в дизассемблере. Вы познакомитесь с изменениями PE-файлов при загрузке в память и с тем, как эти изменения могут влиять на расследования.

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

С точки зрения криминалистики при выгрузке памяти процесса посредством memdump или vaddump неизбежно получается содержимое кучи, по крайней мере тех её страниц, которые не выгружены на диск. То же относится к сканированию памяти с помощью Yara и API search_process_memory, рассмотренного в главе 7. Проблема в том, что вы не обязательно будете знать, какие смещения в файле дампа или результатах поиска сигнатур соответствуют областям кучи. Более того, иногда требуется анализировать только память кучи. Предположим, например, что вы ищете данные, полученные приложением по сети, или текст, введённый пользователем в текстовый процессор. Такие данные с большой вероятностью находятся в одной из куч процесса, поэтому незачем тратить время на сканирование областей памяти, содержащих DLL, стеки или отображённые файлы.

Этот пример показывает, как можно радикально сузить пространство поиска криминалистических доказательств в куче. Исследование началось с вопроса участника списка рассылки пользователей Volatility: как найти текст, введённый пользователем в Notepad? Один из способов, конечно, состоит в обратном анализе notepad.exe и определении места хранения указателя на данные, которые приложение получает с клавиатуры. Однако мы выбрали несколько более простой подход чёрного ящика. Сначала для подготовки среды мы запустили два экземпляра Notepad: в одном открыли довольно большой файл журнала, а другой «подозреваемый» использовал для разработки плана преступления, которое вы расследуете. Пример рабочего стола подозреваемого показан на рис. 8-1.

Рисунок 8-1. Текст, видимый в открытых окнах Notepad, хранится в куче процесса Notepad

Предположим, вы получили дамп памяти системы подозреваемого. Теперь для процессов Notepad можно запустить такие плагины, как vadinfo и vadtree, но (на этой конкретной машине) вы увидите более 50 узлов VAD, охватывающих свыше 25 Мбайт данных в каждом процессе. Как точно найти совершенно произвольный текст в наборе из 25 миллионов байтов? Начать можно с фильтрации только тех VAD, которые содержат кучи процесса.

Как показывает следующий вывод плагина heaps, процесс с PID 3988 имеет 6 куч. В совокупности это сужает поиск до 6 VAD и примерно 1,3 Мбайт данных. На этом этапе в дело вступил подход чёрного ящика. Мы начали искать всё, что могло бы помочь отделить фрагменты кучи с искомым текстом от всех остальных. Как показано ниже, два фрагмента выделялись тем, что для них отображался флаг extra. Иными словами, для этих двух фрагментов в члене _HEAP_ENTRY.Flags был установлен флаг HEAP_ENTRY_EXTRA_PRESENT. Оба фрагмента находились в основной куче (первой в массиве ProcessHeaps), начинающейся по адресу 0xa0000:

Независимо от фактического значения флага extra (нам так и не удалось найти хорошего описания), это отличие привлекло наше внимание к фрагментам по адресам 0xa8028 и 0xac7b0. Следующая команда volshell показывает, что один из этих фрагментов действительно содержит Unicode-версию текста подозреваемого. Обратите внимание, что сам текст начинается по адресу 0xac7b8, поскольку в начале находится _HEAP_ENTRY, размер которой на 32-разрядной платформе составляет 8 байт.

На этом этапе мы создали плагин notepad, автоматически выгружающий текст из процессов notepad.exe. Его вывод выглядит так:

Несмотря на то что плагин целиком основан на обоснованной догадке, а не на эмпирическом тестировании или обратном анализе, он стабильно и точно работает в 32-разрядных версиях XP и 2003 Server. Даже если бы нам не повезло с индикаторами флага extra, пространство поиска всё равно можно было бы сократить до 1,3 Мбайт из всей памяти процесса, рассматривая только области, содержащие кучи.

На переменные среды процесса указывает _PEB.ProcessParameters.Environment. Переменные организованы как несколько строк с завершением NULL, аналогично значению REG_MULTI_SZ в реестре. Если злоумышленник изменит эти переменные, он может заставить целевое приложение неожиданно выполнить вредоносный процесс. Кроме того, некоторые вредоносные программы отмечают своё присутствие созданием переменных среды вместо мьютексов (см. раздел «Маркировка присутствия Coreflood»). Поэтому необходимо уметь проверять подозрительные записи. В табл. 8-1 различные типы переменных распределены по категориям в соответствии с областью действия и постоянством.

Таблица 8-1. Источники и области действия переменных среды

Системные и пользовательские переменные сохраняются в реестре. Поэтому их можно перечислить, разбирая файлы кустов реестра, полученные с диска. Энергозависимые переменные тоже хранятся в реестре, но в энергозависимом ключе, поэтому доступ к ним необходимо получать путём захвата RAM и использования поддержки кэшированного реестра Volatility (см. главу 10). Динамические переменные устанавливаются отдельно для каждого процесса, когда поток внутри процесса вызывает SetEnvironmentVariable. Подобно энергозависимым переменным, эти записи существуют только в памяти: они никогда не записываются в кусты реестра на диске или какой-либо другой файл журнала.

При создании процесс обычно наследует блок среды от родительского процесса. Родительский процесс может переопределить такое поведение по умолчанию, указав параметр lpEnvironment при вызове CreateProcess. Обычно в переменных среды можно найти следующие типы данных:

• Пути к исполняемым программам (PATH).

• Расширения, назначенные исполняемым программам (PATHEXT).

• Пути к временным каталогам.

• Пути к папкам пользователя Documents, Internet History и Application Data.

• Имена пользователей, компьютеров и доменов.

• Местоположение cmd.exe (ComSpec).

Два наиболее распространённых типа атак на переменные среды связаны с изменением переменных PATH и PATHEXT. Изменение этих значений оказывает эффект, подобный перехвату порядка поиска. Рассмотрим, например, следующий сценарий:

В этом случае, если переменная PATH обновлена в explorer.exe, а вошедший пользователь переходит в Start > Run и вводит calc, система ищет приложение с именем calc в каталоге C:\users\HR101\.tmp прежде, чем искать в каталогах windows и system32. Поэтому пользователь неожиданно выполнит вредоносный код. Аналогично, переменная PATHEXT содержит список расширений, по которым ведётся поиск, если пользователь не указал расширение. Например, если ввести calc, как упоминалось выше, система сначала будет искать calc.com, затем calc.exe, потом calc.bat и так далее. После следующих изменений злоумышленник может поместить файл с именем calc.zzz в один из просматриваемых каталогов, и он будет выполнен первым:

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

Многие образцы вредоносных программ отмечают своё присутствие в системе, создавая глобально доступные мьютексы. Это помогает предотвратить случайное повторное заражение. Мьютексы также служат сильным криминалистическим индикатором. Coreflood использовал переменные среды с очень похожей целью: отметить своё присутствие внутри процесса. Поскольку основной компонент Coreflood - DLL, авторам требовался способ гарантировать, что один и тот же процесс не будет внедрён вредоносной программой более одного раза. Поэтому они запрограммировали функцию входа DLL создавать псевдослучайную строку на основе PID родительского процесса и серийного номера тома диска. Затем, если строка ещё не существовала, она добавлялась в переменные среды процесса вызовом SetEnvironmentVariable. В противном случае DLL немедленно выгружалась. Граф функции входа DLL, созданный IDA Pro, показан на рис. 8-2.

Рисунок 8-2. Граф функций, вызываемых точкой входа Coreflood

На наших учебных занятиях мы любим задавать студентам интересную загадку: исходя из только что изученного, сколько из следующих процессов заражено DLL Coreflood? Обратите внимание, что для перечисления переменных в дампе памяти мы используем плагин Volatility envars.

Если вы ответили «два», то правы. На первый взгляд кажется, что заражены все четыре процесса, поскольку каждый содержит подозрительные имена переменных. Однако ранее мы упоминали, что дочерние процессы обычно наследуют переменные родителя. Мы также сказали, что имя переменной зависит от PID процесса. Если бы были заражены все четыре процесса, вы увидели бы четыре уникальных имени переменных, но видны лишь два (VFTPXXPYVTAMF и QBYXKDAGXM). Последние три процесса (IEXPLORE.EXE, notepad.exe и firefox.exe) были порождены PID 1144, что объясняет наличие у них копии переменной VFTPXXPYVTAMF. Можно заметить, что у IEXPLORE.EXE фактически две переменные: одна унаследована от родителя, а вторую Coreflood вычислил для его собственного PID.

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

• Расхождения списков. Как вы вскоре узнаете, противники пытаются скрыть свои DLL, отсоединяя структуры метаданных от одного или нескольких списков либо перезаписывая поля имени или пути в структурах метаданных. Такие попытки можно обнаружить перекрёстной проверкой.

• Неожиданные имена и пути. Обращайте внимание на DLL с подозрительными именами (например, sodapop.dll), а также на знакомо выглядящие имена в нестандартных местоположениях (например, C:\Windows\system32\sys\kernel32.dll). Нам также встречались вредоносные программы, загружавшие DLL из секторов за пределами раздела NTFS. Например, один вариант TDL ссылался на модуль, путь которого начинался с \\.\globalroot\Device\svchost.exe.

• Контекст. DLL ws2_32.dll, crypt32.dll, hnetcfg.dll и pstorec.dll используются соответственно для сетевого взаимодействия, криптографии, обслуживания межсетевого экрана и доступа к защищённому хранилищу. Сами по себе они не подозрительны, но необходимо учитывать назначение приложения, в которое они загружены.

DLL могут загружаться следующими способами:

• Динамическое связывание. В ходе процедур инициализации процесса любая DLL в IAT исполняемого файла (.exe) автоматически загружается в адресное пространство процесса.

• Зависимости. У DLL тоже есть таблицы импорта, поэтому при их загрузке в адресное пространство процесса загружаются все дополнительные DLL, от которых они зависят. Дополнительные сведения см. в Dependency Walker (dependencywalker.com).

• Динамическое связывание во время выполнения (RTDL). Поток может явно вызвать LoadLibrary (или нативную LdrLoadDll), передав имя загружаемой DLL. Конечный результат тот же, что и при динамическом связывании (DLL загружается в процесс), но в IAT процесса от DLL не остаётся следа.

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

Основные инструменты исследования системы умеют перечислять DLL. Например, такую возможность поддерживают Process Hacker и Process Explorer. Sysinternals также предоставляет утилиту командной строки listdlls (technet.microsoft.com). С точки зрения программирования можно использовать функции Windows API CreateToolhelp32Snapshot вместе с Module32First и Module32Next. Кроме того, начиная с Windows XP доступна функция EnumProcessModules.

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

Как показано на рис. 8-3, поскольку все три списка находятся в памяти процесса, любой выполняющийся в процессе поток может отсоединить структуру метаданных (_LDR_DATA_TABLE_ENTRY), чтобы скрыть её от работающей системы (а потенциально и от криминалистического анализа памяти). Например, после загрузки модуль xyz.dll может перезаписать собственные указатели Flink и Blink, чтобы его запись пропускалась при перечислении.

Рисунок 8-3. Схема, показывающая, как PEB указывает на три двусвязных списка DLL

Показанный на рис. 8-3 подход с отсоединением влияет и на плагин Volatility dlllist. Мы спроектировали dlllist таким намеренно. Он перечисляет DLL, обходя список порядка загрузки, как и API работающей системы, поскольку иногда полезно увидеть ситуацию с точки зрения инструментов, работающих в живой системе. Ниже приведён пример вывода dlllist. На наших учебных занятиях мы обычно спрашиваем студентов, могут ли они заметить что-нибудь подозрительное. А вы можете?

Исполняемый файл процесса (notepad.exe) загружается в адресное пространство процесса первым, поэтому он первый и в списке порядка загрузки. Следом загружаются системные библиотеки ntdll.dll и kernel32.dll. Затем система загружает все DLL из IAT Notepad и все модули-зависимости, необходимые этим DLL. Обратите, однако, внимание, что счётчик загрузок первой группы модулей равен 0xffff. Поскольку это поле является коротким целым числом, 0xffff фактически означает -1. Счётчик загрузок -1 означает, что DLL загружена потому, что была указана в IAT. Все остальные ближе к концу, со счётчиками загрузок 0x3, 0x27, 0x4 и 0x1, были загружены явными вызовами LoadLibrary.

Хотя для вызова LoadLibrary существует множество законных причин, её использование также соответствует методам, которыми шелл-код подготавливает адресное пространство целевого процесса. Можно заметить, что ни одна из явно загруженных DLL сама по себе не подозрительна: все они правильно названы и находятся по верному пути system32. Однако если учесть их назначение (связано с сетью) и контекст процесса-хоста (notepad.exe), ситуация начинает выглядеть весьма ненормально. Скорее всего, этот процесс заражён кодом, которому требуется доступ к сетевым DLL, и он загружает их вызовом LoadLibrary.

Показанный на рис. 8-3 метод сокрытия относительно эффективен, несмотря на свою примитивность и простоту. В реальных условиях вам встретятся и более надёжные способы скрывать DLL. Например, если имеются три списка, а вредоносная программа скрывается лишь из одного, можно легко выполнить перекрёстную проверку с двумя другими и увидеть, чего не хватает. Поэтому ещё в 2007 году (см. openrce.org) представители наступательного сообщества начали отсоединять DLL от всех трёх списков. Всё, что требовалось злоумышленникам, - включить ещё две-три строки кода, вырезающие структуру метаданных также из списков порядка расположения в памяти и порядка инициализации.

Обнаружить DLL, отсоединённые от всех трёх списков, помогают два метода:

• Сканирование PE-файлов. Можно использовать методы из главы 7 для полного перебора памяти процесса в поиске всех экземпляров PE-файлов (по их известным сигнатурам заголовка MZ). Однако помните, что заголовки PE также находятся в памяти процесса, поэтому тот же фрагмент кода, который отсоединяет структуру метаданных DLL, легко может перезаписать и их.

• Перекрёстная проверка VAD. Этот метод реализован плагином Volatility ldrmodules. Как вы помните из главы 7, узлы VAD содержат полные пути на диске к файлам, отображённым в области, в том числе к файлам DLL. Уникальная особенность VAD состоит в том, что они находятся в памяти ядра, а попытки изменить дерево (например, отсоединить узел VAD) или перезаписать их указатели на файлы быстро приводят к нестабильности системы (синим экранам).

Плагин ldrmodules сначала перечисляет все узлы VAD, содержащие отображённые исполняемые образы. В частности, он ищет крупные узлы с защитой PAGE_EXECUTE_WRITECOPY, типом VadImageMap и установленным управляющим флагом Image. Затем он сравнивает начальные адреса из узлов VAD со значением DllBase структур _LDR_DATA_TABLE_ENTRY, найденных в памяти процесса. Записи, обнаруженные через VAD, но не представленные в списках DLL, потенциально скрыты. Ниже приведён пример вывода из заражённого 64-разрядного образца Windows 7:

lpkz2.dll отсутствует во всех трёх списках DLL в памяти процесса, но VAD в памяти ядра содержит запись о ней. Также виден её базовый адрес 0x000007feff570000, который затем можно передать плагину dlldump (представлен далее в этой главе), чтобы извлечь DLL из памяти.

Обратите внимание, что для записи svchost.exe в столбце InInit (список порядка инициализации) указано False. Это исключение из правила о возможности обнаруживать отсоединённые DLL перекрёстной проверкой источников данных. Исполняемый файл процесса (.exe) никогда не встречается в списке порядка инициализации, поскольку он инициализируется иначе, чем все остальные модули. В частности, это не DLL, поэтому у него нет вызываемой функции DllMain.

Одна из наиболее полезных возможностей Volatility - выгрузка и восстановление PE-файлов (исполняемых файлов, DLL и драйверов ядра). Из-за изменений, происходящих во время выполнения программы, получить точную копию исходного двоичного файла или даже файл, запускающийся на другой машине, маловероятно. Однако выгруженная копия должна быть достаточно близка к оригиналу, чтобы можно было дизассемблировать вредоносную программу и определить её возможности, восстановить алгоритмы и так далее. Нас часто спрашивают, можно ли выгрузить исполняемый файл и сравнить его хеш MD5 или SHA1 с файлом на диске. Хотя сравнение нечётких хешей (например, процентного сходства) возможно, криптографические хеши никогда не совпадут по следующим причинам:

• Исправление IAT. Загрузчик изменяет IAT PE-файла так, чтобы она содержала адреса функций API в памяти процесса. Адреса зависят от конкретной машины и экземпляра процесса, из которого извлечён PE-файл.

• Недоступные разделы. Не все разделы PE загружаются в память. Например, в некоторых случаях раздел ресурсов (.rsrc) может не загружаться до тех пор, пока не понадобится. Очевидно, что данные, изначально ни разу не прочитанные в память, недоступны при выгрузке.

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

• Самомодифицирующийся код. Многие PE-файлы, особенно вредоносные, изменяют собственный код во время выполнения. Например, упакованные приложения распаковывают и/или расшифровывают инструкции в памяти.

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

Ещё одна причина, по которой PE-файлы, выгруженные из памяти, часто отличаются от исходного файла на диске, - slack space. Наименьший размер страницы в типичной системе Windows x86 или x64 составляет 4096 байт. У большинства PE-файлов есть разделы, размеры которых не кратны точно наименьшему размеру страницы. На рис. 8-4 показано, как это влияет на восстановление двоичных файлов из памяти. Раздел .text, размер которого не кратен точно 4096, должен целиком находиться в памяти с пометкой RX (чтение, выполнение), а раздел .data должен целиком находиться в памяти с пометкой RW (чтение, запись). Поскольку защита применяется на уровне страниц (иными словами, если страница помечена как исполняемая, исполняемы все байты страницы), после загрузки в память эти два раздела должны быть разделены. Иначе начало раздела .data получит RX вместо RW.

Рисунок 8-4. Схема, показывающая, как PE-файлы расширяются в памяти, оставляя slack space между разделами

Пунктирные линии на рис. 8-4 обозначают границы страниц, а закрашенные области представляют slack space, возникающее из-за того, что размеры разделов не кратны размеру страницы. В некоторых случаях slack space содержит лишь неинициализированные данные и не имеет значения для расследования. Однако оно может содержать и критически важные доказательства, особенно при работе с упакованными файлами, чьи разделы сдвигаются и изменяются во время распаковки.

Volatility предоставляет несколько API, помогающих разбирать заголовки PE в памяти. Существуют плагины, оборачивающие большую часть этих возможностей, поэтому выполнять описанные вручную действия не требуется. Однако тем, кому интересно, как плагины выгрузки PE работают изнутри, и особенно тем, кто планирует создавать собственные инструменты с похожими возможностями, будет полезно следующее руководство. Например, некоторое время назад мы написали специальный плагин для поиска и автоматического извлечения двоичных файлов ZeroAccess (mnin.blogspot.com) с использованием API выгрузки PE.

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

Сигнатура MZ выглядит неповреждённой. Следующий шаг проверки формата заголовка PE - пройти по члену e_lfanew и найти заголовок NT. Вместо ручного выполнения можно создать _IMAGE_DOS_HEADER по базовому адресу, а затем использовать функцию get_nt_header. Ниже приведён пример:

Теперь, когда заголовок NT получен, следующий код показывает, как вывести имя, относительный виртуальный адрес и виртуальный размер каждого раздела. Чтобы вычислить абсолютный адрес раздела, достаточно прибавить базовый адрес заголовка DOS к относительному смещению. Например, для этого процесса раздел .text находится по адресу 0xff080000 + 0x1000 = 0xff081000:

Теперь вы должны хорошо представлять, как содержимое PE-файла вырезается из памяти. Тем не менее, завершая пример, приведём код, которым можно выгрузить копию каждого раздела на диск. Функции get_image можно необязательно передать параметр для сохранения slack space, однако подробнее об этом будет рассказано в следующем разделе. Обратите внимание: закончив запись данных в файл (dumped.exe), мы выходим из volshell и проверяем тип выходного файла:

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

• procdump: выгружает исполняемый файл процесса. Процесс можно указать по PID (--pid) или физическому смещению его _EPROCESS (--offset). Последний параметр позволяет выгружать процессы, скрытые из списка активных процессов.

• dlldump: выгружает DLL. Процесс-хост можно указать по PID (--pid) или физическому смещению его _EPROCESS (--offset). Если DLL находятся в списке порядка загрузки, их можно указать регулярным выражением (--regex/--ignore-case) по имени. В противном случае на них можно сослаться по базовому адресу в памяти процесса (--base). Последний параметр позволяет выгружать скрытые или внедрённые PE-файлы.

• moddump: выгружает модуль ядра. Подобно dlldump, если нужные модули находятся в списке загруженных модулей (см. главу 13), их можно указать регулярными выражениями. В противном случае для выгрузки PE-файла из любого места памяти ядра используется параметр --base.

Все плагины требуют выходной каталог (--dump-dir) для записи извлечённых файлов. Они также принимают необязательный параметр --memory, посредством которого в выходной файл запрашивается включение slack space между разделами. Поэтому при использовании --memory выгруженный файл больше похож на PE в том виде, в каком он существовал в памяти. Несколько примеров использования этих плагинов приведены далее. Первый показывает, как извлечь все исполняемые файлы из списка активных процессов:

Извлечь процесс System не удалось, но это нормально: у этого процесса нет соответствующего исполняемого файла. Обратите внимание, что имя выходного файла основано на PID процесса (executable.PID.exe). Следующий пример показывает, как извлечь отсутствующий в списке активных процессов процесс по физическому смещению его _EPROCESS (которое можно получить с помощью psscan или psxview):

Следующая команда извлекает из PID 1408 любую DLL, имя или путь которой совпадает с нечувствительной к регистру строкой crypt. Имена выходных файлов формируются по PID и физическому смещению процесса-хоста, а также базовому виртуальному адресу DLL (module.PID.OFFSET.ADDRESS.dll):

Параметр регулярного выражения работает только с DLL из списков PEB. Нельзя выгрузить скрытые или внедрённые DLL по имени, поскольку имени часто нет: есть лишь базовый адрес, по которому расположен заголовок DOS. В таких случаях можно указать --base следующим образом:

Следует учитывать, что эти плагины уязвимы для атак, изменяющих значения заголовка PE. Например, если сигнатура MZ или PE не найдена, они не могут правильно определить местоположение разделов. Кроме того, они опираются на заявленные виртуальные адреса и размеры разделов, которые вредоносный код легко может перезаписать. Если раздел заявляет размер намного больше или меньше фактического, выходной файл будет содержать либо посторонние данные, либо не все данные. Эти плагины могут отказать и просто по воле случая. Если страница или страницы, содержащие заголовок PE либо сведения о разделах, выгружены на диск, процедуры проверки заголовка завершаются неудачей.

При проблемах с выгрузкой PE-файлов из памяти процесса, будь то исполняемый файл процесса или DLL, всегда можно вернуться к простой выгрузке содержащей их области VAD. Как вы помните из главы 7, плагин vaddump создаёт дополненный файл для сохранения пространственной целостности и ничего не знает (и не заботится) о формате PE-файла. Это позволяет получить данные, даже если они намеренно повреждены. Однако перед загрузкой во внешние инструменты, например IDA Pro или средства просмотра PE, может потребоваться ручное исправление. Другая возможность - использовать плагин dumpfiles (см. главу 16), который извлекает кэшированные копии PE-файлов с диска. В этом случае вы не получите slack space, изменённые глобальные переменные или распакованные версии упакованных файлов.

Слои обфускации, внесённые упаковкой или сжатием двоичных файлов, часто удаляются при их загрузке в память. Почти во всех случаях перед выполнением основной полезной нагрузки самомодифицирующаяся программа распаковывается на месте либо перемещается по другому адресу, а затем распаковывается. На рис. 8-5 показан жизненный цикл двоичного файла, который упаковывают, а затем загружают в память. До упаковки точка входа PE-файла находится внутри его раздела .text (вероятно, это функция main или DllMain), а все строки и код представлены открытым текстом. На этом этапе можно провести статический анализ двоичного файла. Однако после упаковки строки и код сжаты и необязательно зашифрованы либо закодированы. Кроме того, в двоичный файл добавлен новый раздел, содержащий код распаковки, и точка входа теперь ведёт в этот новый раздел. Статический анализ файла на этом этапе почти наверняка потерпит неудачу.

Рисунок 8-5. Жизненный цикл программы при упаковке и загрузке в память

Когда двоичный файл загружается в память, функция точки входа (код распаковки) распаковывает исходные строки и данные, чтобы программа могла к ним обращаться. Затем вызывается настоящая процедура main или DllMain, запускающая нормальное поведение программы. В любой момент между этим событием и выгрузкой DLL либо завершением процесса у вас должна быть возможность выгрузить распакованный код из памяти. Найти его редко бывает проблемой, поскольку базовые адреса предоставляют dlllist, ldrmodules и malfind (описан в следующем разделе). В сочетании с procdump, dlldump и moddump они образуют довольно гибкий набор средств для получения данных, необходимых для статического анализа.

В этом разделе приведён практический пример использования анализа памяти для распаковки образца вредоносной программы. На рис. 8-6 показаны функции, которые упакованный образец импортирует из kernel32.dll (представление CFF Explorer с сайта ntcore.com). Обычно по импортам программы можно получить общее представление о её функциях, но в данном случае видно немногое, что указывает на обфускацию упаковщиком не только инструкций программы, но и IAT. Однако благодаря наличию GetProcAddress и LoadLibraryW программа может во время выполнения загружать любые необходимые API и обращаться к ним.

Рисунок 8-6. Таблица адресов импорта упакованной вредоносной программы содержит лишь несколько функций

Если извлечь строки из двоичного файла, окажется, что их немного, кроме сообщения DOS и нескольких отчасти знакомых элементов в начале. Например, zirtualAlloc и zegOpenKeyExW очень похожи на VirtualAlloc и RegOpenKeyExW (имена функций Windows API). Это действительно подозрительно и, вероятно, указывает на попытку обойти сигнатуры на основе строк:

Теперь совершенно очевидно, что образец упакован. Его можно выполнить в контролируемой среде (например, в VM с отключённой сетью), чтобы программа распаковалась в памяти. Пока она работает, захватите её состояние, сделав снимок VM или выгрузив память. Затем с помощью procdump извлеките распакованный код, как показано ниже:

Теперь, имея образец, извлечённый из памяти, снова запустите для него strings и посмотрите на разницу:

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

Позволив вредоносной программе самостоятельно распаковаться в памяти вместо обратного анализа образцов в отладчике, можно сэкономить огромное количество времени, но у подхода есть и недостатки. Например, как уже упоминалось, некоторые образцы никогда не распаковываются полностью. Могут встретиться и образцы, которые остаются активными недостаточно долго для захвата памяти. В таких случаях мы рекомендуем запустить вредоносную программу в отладчике и установить точку останова на ExitProcess: она «замораживается», пока вы получаете необходимое. Конечно, встречаются и образцы, распознающие отладчик, поэтому обязательно прочитайте рецепт 9-11 («Preventing Processes from Terminating») в книге Malware Analyst’s Cookbook. В нём показано, как при попытке процесса завершиться приостановить его путём установки перехватчиков в ядре.

Распаковка DLL в 64-разрядной Windows технически не отличается от распаковки исполняемых файлов на 32-разрядных платформах. Когда мы готовили этот раздел главы, нам попался образец RovNix (xylibox.com), реализованный как DLL и нацеленный на 64-разрядные системы. Как показано на рис. 8-7, образец был упакован. Если вы не знакомы с IDA Pro, горизонтальная полоса под главным меню (так называемая цветовая полоса) показывает сегменты файла, содержащие инструкции, в противоположность неопределённым данным. Большая часть этого файла была неопределённой. Кроме того, функция точки входа вызывает VirtualAlloc, вероятно, чтобы выделить область памяти в качестве «черновика», где может происходить распаковка. Также видно 62 экспортированные функции с именами, похожими на API баз данных. При просмотре их кода (здесь не показан) видно, что они состоят только из пустых операций (NOP).

Рисунок 8-7. DLL, загруженная в IDA Pro, демонстрирует различные признаки сжатия или шифрования

В главе 13 («Working with DLLs») книги Malware Analyst’s Cookbook приведены полезные советы, которыми можно воспользоваться здесь. Цель состоит в том, чтобы загрузить DLL, позволить ей распаковаться, а затем удерживать её достаточно долго для захвата памяти. В качестве процесса-хоста мы используем rundll32.exe (который на 64-разрядных платформах на самом деле является 64-разрядным исполняемым файлом, несмотря на название): он берёт на себя отображение вредоносной DLL в память и вызов функции её точки входа (DllMain). Используется следующая команда:

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

Вывод сообщает, что DLL загружена в процесс по базовому адресу 0x180000000. Теперь DLL можно выгрузить следующим образом:

Когда на этот раз выгруженный файл загружается в IDA Pro, видны значительные различия. Обратите внимание, как распакованная копия на рис. 8-8 отличается от упакованной копии, ранее показанной на рис. 8-7.

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

Рисунок 8-8. Распакованная DLL в IDA Pro теперь находится в достаточно хорошем состоянии для статического анализа

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

Мы рассмотрим следующие классы внедрения кода:

• Удалённое внедрение DLL. Вредоносный процесс заставляет целевой процесс загрузить указанную DLL с диска путём вызова LoadLibrary или нативной LdrLoadDll. По определению DLL должна существовать на диске до внедрения.

• Удалённое внедрение кода. Вредоносный процесс записывает код в пространство памяти целевого процесса и заставляет его выполняться. Код может быть блоком шелл-кода (то есть не PE-файлом) или PE-файлом, таблица импорта которого заранее настроена для целевого процесса.

• Рефлексивное внедрение DLL. Вредоносный процесс записывает DLL (как последовательность байтов) в пространство памяти целевого процесса. DLL выполняет собственную инициализацию без помощи загрузчика Windows. До внедрения DLL не обязана существовать на диске.

• Внедрение с опустошением процесса. Вредоносный процесс запускает новый экземпляр законного процесса (например, lsass.exe) в приостановленном режиме. Перед возобновлением процесса его исполняемый раздел или разделы освобождаются и заново выделяются с вредоносным кодом.

Как вы узнаете, способ обнаружения внедрения кода зависит от того, как код был внедрён, поэтому мы и различаем эти методы. Хотя Volatility позволяет обнаруживать все типы, всё равно требуется аналитическая работа, чтобы понять, когда использовать разные плагины и как правильно интерпретировать их вывод.

В следующих описаниях процесс A - вредоносный, а процесс B - целевой.

После выявления областей внедрённого кода их можно извлечь на диск для статического анализа. В большинстве случаев достаточно исправить ImageBase в выгруженном заголовке PE так, чтобы он соответствовал местоположению в памяти, после чего файл можно загрузить в IDA Pro. Если импортированные функции при этом не видны, используйте плагин impscan, чтобы создать контекстные сведения из дампа памяти и импортировать данные в IDA в виде меток. То же относится к любому процессу, DLL или драйверу ядра, выгруженному из памяти, а не только к внедрённым областям. В рецепте 16-8 («Scanning for Imported Functions with Impscan») книги Malware Analyst’s Cookbook эта возможность описана подробнее.

Хотя большая часть кода, выгруженного из памяти, самодостаточна (например, одна область содержит исполняемый код и переменные для чтения и записи), это верно не всегда, особенно для Poison Ivy с включённой функцией melt. Она заставляет RAT растворяться в пространстве памяти процесса, разбрасывая повсюду небольшие фрагменты своего кода. На рис. 8-10 показано, как это влияет на возможность восстановить исходный двоичный файл для статического анализа.

Рисунок 8-10. Функция «melt» Poison Ivy распространяет фрагменты внедрённого кода по всей памяти процесса

Poison Ivy распределён более чем по 20 различным областям VAD. В статье «Reverse Engineering Poison Ivy’s Injected Code Fragments» (volatility-labs.blogspot.com) мы показываем, как создать специальный плагин Volatility, который по возможности восстанавливает исходный двоичный файл из фрагментов и возвращает им контекст.

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

Ваши цели таковы:

• Поиск журналов событий в памяти. Начиная с Vista Microsoft внесла несколько критически важных изменений в средство ведения журналов событий. Для работы с журналами событий в разных версиях Windows необходимо понимать и учитывать различия.

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

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

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

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

В Windows 2000, XP и 2003 журналы событий имеют один и тот же двоичный формат записей. Журналы по умолчанию - Application, System и Security, а стандартное место их хранения на диске - %systemroot%\system32\config. Эти журналы событий также отображаются в адресное пространство процесса services.exe.

Определить, какой именно сегмент памяти содержит данные файла, можно, найдя процесс services.exe и выполнив поиск имени файла журнала событий (расширение .Evt), как показано в следующем выводе.

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

Плагин evtlogs (только Windows XP и 2003) автоматически находит и разбирает записи журналов событий. Он также предназначен для обработки повреждённых журналов с отсутствующими или перезаписанными данными. Плагин сначала находит процесс services.exe, а затем ищет журналы событий в его памяти. После этого он разбивает каждый журнал по его сигнатуре (LfLe) и разбирает каждую запись с помощью структур, определённых в начале главы. У evtlogs также есть параметр для выгрузки необработанного журнала, если его требуется обработать внешними по отношению к Volatility инструментами. Ниже приведён пример вывода при запуске плагина для общедоступного образца памяти (sempersecurus.blogspot.com), полученного после открытия документа Word со встроенным эксплойтом Flash:

Поскольку в этом примере используется параметр --save-evt, плагин создал для каждого файла журнала файл .evt (необработанный двоичный журнал событий) и файл .txt (разобранные записи в текстовом формате). Вывод разобранного текстового файла имеет следующий формат:

Зная это, можно исследовать вывод журнала osession.evt.

Обратите внимание на запись уровня Warning с идентификатором 7003, означающую, что приложение Microsoft Office неожиданно завершилось. Эти сведения имеют отношение к расследованию, поскольку вектором заражения был встроенный эксплойт Flash. В главе 18 вы узнаете, как строить временные шкалы и видеть, как это событие в сочетании с другими событиями создаёт ясную картину атаки.

По умолчанию журнал событий Security в Windows XP отключён. Поэтому следует проверить параметры аудита в реестре (HKLM\SECURITY\Policy\PolAdtEv), чтобы установить, события каких типов следует ожидать. Следующая команда показывает, как выполнить проверку с помощью плагина auditpol (S означает «успешные операции регистрируются», а F - «неудачные операции регистрируются»):

Журналы событий Windows Vista, 2008 и 7 (будем называть их Evtx по расширению) хранятся в совершенно ином формате файлов, чем описанные в предыдущем разделе. В частности, эти журналы представлены в двоичном формате XML. На типичной машине на диске по пути %systemroot%\system32\winevt\Logs можно найти более 60 таких журналов. Столь большое число журналов увеличивает возможности поиска интересующих записей на скомпрометированной машине. Кроме того, строки описаний содержатся внутри этих журналов событий (в отличие от журналов XP/2003), что упрощает их исследование без доступа к диску целевой машины.

Новые журналы событий отображаются в память не так, как старые. Поэтому методика работы с ними совершенно иная: журналы необходимо извлекать из памяти плагином dumpfiles (см. главу 16), а затем разбирать внешним по отношению к Volatility инструментом. Можно выбрать целевой подход (найти и выгрузить выбранный журнал событий) либо выгрузить все журналы событий, используя возможности сопоставления с шаблоном (регулярным выражением) плагина dumpfiles. Ваш подход зависит от того, что вы ищете и какой объём контекста получен до расследования. Например, если требуется доказать, что кто-то вошёл на машину, можно исследовать только журнал событий Security. Но если основная проблема машины неизвестна, можно выгрузить все журналы событий.

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

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

Для некоторых извлечённых файлов вместо MS Windows Event Vista Event Log может быть указано data, потому что на момент получения памяти заголовок журнала или сам журнал был выгружен из памяти. В любом случае эти файлы следует исследовать, чтобы установить, удастся ли найти частичные записи. Ниже показано, как исследовать один из таких журналов утилитой evtxdump.pl из Evtxparser:

Как видно, вывод содержит все сведения о созданных событиях. В частности, видны следующие поля:

• Provider Name: сообщает, из какого журнала извлечены сведения.

• EventID: содержит идентификатор события, который можно найти в интернете, чтобы установить произошедшее событие.

• TimeCreated: временная метка создания события.

• EventRecordID: идентификатор записи, помогающий установить порядок созданных записей.

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

Кроме того, противники могут очищать журналы событий на машине посредством функции ClearEventLog. Эта функция принимает в качестве параметров дескриптор журнала событий и местоположение резервной копии. Если местоположение резервной копии не задано (то есть равно NULL), журнал просто очищается с диска и из памяти. Определение функции, полученное из MSDN (msdn.microsoft.com), показано в следующем коде:

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

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

Если образа диска нет, физическое адресное пространство дампа памяти можно просканировать на наличие записей по сигнатурам LfLe (Evt) или ElfChnk (Evtx), и, возможно, вам повезёт восстановить исторические записи. Уилли Баллентин написал инструменты для обоих случаев, которые используются вне Volatility и соответствующим образом называются LfLe (github.com) и EVTXtract (github.com).

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

Злоумышленники часто любят устанавливать бэкдоры на скомпрометированных машинах. Это позволяет им легко подключаться к машине в удобное время. Следующий вывод плагина evtlogs из журнала событий Security подозреваемой машины показывает неудачные попытки приложений создать прослушивающие порты (событие с ID 861):

В этом случае события подозрительны, потому что исполняемого файла wauclt.exe на машине Windows по умолчанию фактически нет. Его имя выбрано так, чтобы походить на законный процесс wuauclt.exe, относящийся к обновлениям Windows (обратите внимание на отсутствующую u). Кроме того, если рассматриваемым приложением является что-то вроде notepad.exe (который вообще не должен открывать порты), журналы могут указывать на внедрение кода. Полную строку сообщения можно составить, найдя шаблон сообщения в интернете (eventid.net):

Как вы узнали, события входа и выхода собираются в журнале событий Security. В следующем примере со скомпрометированного сервера Windows 2003 видны два события с ID 529 (неудачная попытка входа) и событие с ID 680. Значение события 680 зависит от операционной системы машины, но на машинах Windows 2003 оно отслеживает успешные и неудачные входы NTLM.

Если найти шаблон сообщения для события с ID 529 (ранее в главе приведено несколько ссылок), можно получить дополнительный контекст этого события. Полная строка сообщения, показываемая в средстве просмотра журналов событий, выглядела бы так:

Видно, что кто-то пытался войти как administrator по сети (Logon Type: 3), а удалённый IP-адрес находился в Китае (222.186.XX.XX). Поскольку машина жертвы находится в США, а у компании-владельца нет сотрудников в Китае, можно уверенно сказать, что это недопустимая попытка входа. Если таким же образом исследовать другую запись события с ID 680, можно получить дополнительный контекст причины неудачи входа:

Коды ошибок этого события хорошо документированы (ultimatewindowssecurity.com). Видно, что 0xC000006A означает, что злоумышленник использовал допустимое имя пользователя системы, но неверный пароль. Событие такого типа показывает один из трёх вариантов:

• Учётная запись является стандартной для машины.

• Злоумышленник ранее провёл некоторую разведку системы.

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

В этом примере administrator - стандартная учётная запись. Однако если бы имя учётной записи было другим, например gstanley, а неудачных попыток нашлось бы лишь несколько (то есть это не атака полным перебором), вы бы точно знали, что злоумышленник или злоумышленники подготовились.

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

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

Доказательства попыток полного перебора можно найти и в системном журнале событий. Например, следующий вывод показывает атаку на систему, в которой работает служба FTP Microsoft.

Снова видны шесть попыток входа в секунду с использованием скрытого имени пользователя. Ниже приведён пример восстановленного сообщения:

Как упоминалось ранее, злоумышленники часто пытаются очистить журналы событий, чтобы скрыть следы на машине. В одном из наших случаев злоумышленник вошёл на машину с помощью похищенных учётных данных и запустил задание на другой машине, используя другой набор похищенных учётных данных. Нашей целью было найти обе скомпрометированные учётные записи, чтобы деактивировать их. Злоумышленник оказался достаточно умён, чтобы стереть журнал событий Security, а также несколько других журналов, которые могли бы помочь. Кроме того, у нас не было жёсткого диска для поиска отсутствующих записей в нераспределённом пространстве. К счастью, злоумышленник не понял, что существовал ещё один журнал событий (Microsoft-Windows-TaskScheduler.evtx), содержащий необходимые нам сведения. Этот журнал оказался резидентным в памяти и содержал запись, которая прямо указала на учётную запись, которую требовалось отключить:

В следующем выводе показаны отдельные структуры из 32-разрядной Windows 7. Структура _CMHIVE представляет файл куста реестра на диске, а _HHIVE (заголовок куста) помогает описывать содержимое и текущее состояние куста.

Основные моменты таковы:

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

• HiveList: двусвязный список других структур _CMHIVE.

• FileFullPath: путь устройства ядра (например, \Device\HarddiskVolume1\WINDOWS\system32\config\software) к кусту реестра. В Windows 7 этот член не используется, хотя по-прежнему присутствует в структуре (см. gleeda.blogspot.com).

• FileUserName: путь к кусту реестра на диске, перед которым указывается SystemRoot или \??\C:\ (за исключением реестра BCD, который использует путь устройства ядра, и реестра HARDWARE, который использует путь «Registry», описанный для члена HiveRootPath). В Windows Vista/2008 и 7 некоторые кусты не используют этот член.

• HiveRootPath: этот член, появившийся в Windows Vista, содержит путь «Registry» (например, \REGISTRY\MACHINE\SOFTWARE).

• Signature: сигнатура файла реестра. Допустимые файлы реестра имеют сигнатуру 0xbee0bee0.

• BaseBlock: используется для поиска корневого раздела (первого раздела) реестра.

• Storage: отображение виртуальных адресных пространств для разделов внутри реестра.

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

• Непосредственно из пользовательского режима: приложения могут вызывать функцию socket из API Winsock2 (ws2_32.dll).

• Косвенно из пользовательского режима: приложения могут вызывать функции из библиотек, таких как WinINet (wininet.dll), которые предоставляют обертки над функциями Winsock2.

• Непосредственно из режима ядра: драйверы ядра могут создавать сокеты с помощью Transport Driver Interface (TDI) - основного интерфейса к транспортному стеку, используемого компонентами более высокого уровня, такими как Winsock2.

Когда приложение вызывает socket, оно передает следующие сведения:

• семейство адресов (AF_INET для IPv4, AF_INET6 для IPv6);

• тип (SOCK_STREAM, SOCK_DGRAM, SOCK_RAW);

• протокол (IPPROTO_TCP, IPPROTO_UDP, IPPROTO_IP, IPPROTO_ICMP).

После вызова приложением socket сокет еще не готов к использованию. Серверы должны предоставить локальный адрес и порт при вызове bind и listen. Аналогично, клиенты должны предоставить удаленный адрес и порт при вызове connect (bind для клиентов необязателен). Сокет не может работать, пока ему не известны IP-адрес и порт. Поэтому логично, что _ADDRESS_OBJECT (имя структуры, представляющей объекты сокетов) выделяется после вызова bind или connect, а не после вызова socket.

На рисунке 11-1 показана последовательность вызовов API, необходимых для создания простого TCP-сервера, а также связь между этими API и артефактами в памяти. На рисунке 11-2 показана та же связь для TCP-клиента. Полный исходный код см. в справочнике Windows sockets на MSDN (msdn.microsoft.com).

На рисунках показано следующее:

1. И сервер, и клиент начинают с вызова socket, из-за которого вызывающий процесс открывает дескриптор \Device\Afd\Endpoint. Этот дескриптор позволяет процессу пользовательского режима взаимодействовать с Afd.sys в режиме ядра - это Auxiliary Function Driver для Winsock2. Данный дескриптор не является необязательным: он должен оставаться открытым на протяжении всего времени существования сокета, иначе сокет станет недействительным.

2. Сервер вызывает bind (для клиента это необязательно), что приводит к появлению следующих артефактов. Обратите внимание: сервер также вызывает listen, но этот вызов не создает новых артефактов.

◦ Вызывающий процесс открывает дескриптор \Device\Tcp, \Device\Udp или \Device\Ip в зависимости от протокола, указанного при вызове socket.

◦ В ядре выделяется память для структуры _ADDRESS_OBJECT, а ее члены заполняются в соответствии с параметрами, переданными функциям socket и bind.

3. Клиент вызывает connect, что приводит к появлению тех же артефактов, которые обсуждались выше, а также к выделению _TCPT_OBJECT (то есть объекта соединения). Для каждого соединения, установленного с клиентом (когда accept возвращает управление), серверный процесс также связывается с _TCPT_OBJECT и новым набором дескрипторов. Эти артефакты существуют до тех пор, пока приложения не вызовут closesocket; после этого дескрипторы закрываются, а объекты освобождаются.

Рисунок 11-1. Связь между API сокетов и создаваемыми ими артефактами в памяти (сторона сервера)

Рисунок 11-2. Связь между API сокетов и создаваемыми ими артефактами в памяти (сторона клиента)

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

Структуры _ADDRESS_OBJECT и _TCPT_OBJECT не документированы Microsoft, но в прошлом многие специалисты исследовали их с помощью обратного проектирования. Ниже приведены варианты, используемые в платформе Volatility для 64-разрядных систем Windows XP и Server 2003.

Основные моменты таковы:

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

• LocalIpAddress: локальный IP-адрес в упакованном (целочисленном) формате. Если сокет прослушивает все IP-адреса, это значение может быть равно 0.0.0.0.

• LocalPort: локальный порт (с порядком байтов от старшего к младшему).

• Protocol: номер протокола IP (см. iana.org). Для _TCPT_OBJECT этот член не нужен, поскольку данные структуры по определению предназначены только для TCP.

• Pid: идентификатор процесса (PID), который открыл сокет или создал соединение.

• CreateTime: временная метка UTC (только для сокетов), указывающая время создания сокета.

• RemotePort: удаленный порт (только для соединений) в формате с порядком байтов от старшего к младшему.

• RemoteIpAddress: удаленный IP-адрес (только для соединений) в упакованном (целочисленном) формате.

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

Этот метод, используемый группой Comment Crew (также известной как APT1), состоит в простом изменении значения ImagePath или ServiceDll в реестре для легитимной службы так, чтобы оно указывало на вредоносный файл. Например, образец WEBC2-ADSPACE (contagiodump.blogspot.com) захватывал службу ERSvc (Error Reporting Service), изменяя путь к ее DLL с %SystemRoot%\system32\ersvc.dll на %SystemRoot%\system\ersvc.dll.

Вот как выглядит вывод Volatility в зараженной системе:

Иногда Microsoft меняет имя DLL легитимной службы в разных версиях операционной системы. Например, в Windows XP двоичным файлом службы Dynamic Configuration Host Protocol (DCHP) является dhcpsvc.dll, а в Windows 7 - dhcpcore.dll. Поэтому отслеживание изменений представляет собой трудоемкую задачу. Вместо этого можно использовать следующий скрипт для построения белого списка известных безопасных путей к двоичным файлам служб путем экспорта сведений из чистой системы.

Для работы кода требуются Python Extensions for Windows (sourceforge.net), а данные выводятся в формате INI. Однако вывод можно изменить на выбранный вами формат, чтобы облегчить автоматическое формирование предупреждений в результатах плагинов Volatility.

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

1. Запросить в реестре путь к двоичному файлу целевой службы.

2. Переместить или удалить исходный файл.

3. Создать новый файл по тому же пути, по которому находился исходный.

4. Перезапустить службу (либо просто дождаться перезагрузки).

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

В следующем списке описано, как работает этот код:

• Строка 9: копирует XXXXX (скрыто) в переменную szInfectSignature. Позднее она используется как маркер заражения, чтобы вредоносная программа не заменяла один и тот же файл более одного раза.

• Строки 11-23: открывают раздел реестра Svchost и запрашивают значение netsvcs. Возвращается REG_MULTI_SZ (список строк) с именами всех служб группы, которым требуется доступ к сети. Вредоносная программа перебирает список и выбирает одну из служб для захвата. Используя группу netsvcs, а не просто выбирая службу случайным образом, вредоносная программа гарантирует доступность сетевых функций (с точки зрения зависимостей).

• Строки 24-54: для каждой службы из группы netsvcs вредоносная программа запрашивает путь ServiceDll в подразделе Parameters. Затем она раскрывает все переменные среды (например, %SystemRoot%), чтобы получить полный путь, и сохраняет результат в FileName.

• Строки 55-66: вредоносная программа формирует два пути к временным файлам, подготавливая остальную часть заражения. Затем она копирует исходный двоичный файл службы в OrigFileCopy (с расширением .txt) и помещает новую DLL в первоначальное расположение NewDllFile (с расширением .tmp).

• Строки 67-97: вредоносная программа открывает дескриптор исходного двоичного файла службы (FileName) и считывает последние 1024 байта файла в буфер, который затем сканирует на наличие szInfectSignature. Если сигнатура найдена, цикл переходит к следующей службе в группе netsvcs, потому что текущая служба уже заменена.

• Строки 98-113: извлекают двоичный ресурс из раздела ресурсов вредоносной программы (тело подменной DLL) и открывают дескриптор NewDllFile, подготавливая запись на диск.

• Строки 114-132: вредоносная программа изменяет метаданные файловой системы (в частности, временные метки), чтобы создать видимость, будто новая DLL в действительности была создана 18.02.2005 в 20:02:00. Затем она записывает данные ресурса в файл.

• Строки 133-145: добавляют сигнатуру заражения в конец новой DLL, чтобы в будущем та же вредоносная программа не заменила ее снова.

• Строки 146-167: вредоносная программа перемещает новую DLL (NewDllFile) из временного каталога в расположение исходного двоичного файла (FileName). Она устанавливает скрытый атрибут NTFS, поэтому, чтобы увидеть файл в списках каталогов, пользователям потребуется изменить стандартные настройки Проводника. Наконец, она удаляет оба временных файла.

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

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

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

• modscan: этот плагин выполняет сканирование по тегу пула во всем физическом адресном пространстве, включая освобожденную память, в поисках MmLd (тега пула метаданных модуля). Он позволяет находить как исключенные из списка, так и загруженные ранее модули.

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

• moddump: этот плагин извлекает один или несколько модулей ядра, заданных по имени или базовому адресу. Он может извлекать только загруженные в настоящий момент модули с допустимыми заголовками PE.

Следующий вывод показывает пример использования плагина modules. Важно понимать различие между столбцами Offset(V) и Base. Первый (крайний левый столбец) содержит виртуальный адрес структуры метаданных KLDR_DATA_TABLE_ENTRY. Второй представляет собой базовый адрес (также в виртуальной памяти) начала заголовка PE модуля. Поэтому в данной конкретной системе сигнатуру MZ модуля NT, ntoskrnl.exe, следовало бы искать по адресу 0xfffff80002852000.

Модуль NT загружается самым первым, а за ним следует hal.dll (уровень аппаратных абстракций). Это логично, поскольку оба являются основными компонентами ОС, которым необходимо запускаться на раннем этапе. Далее начинают встречаться драйверы, связанные с конкретными службами, которые автоматически запускаются при загрузке, например драйверы обмена данными с отладчиком ядра (kdcom.dll) и Bluetooth (BthEnum.sys). В самом конце списка показан загруженный последним модуль PROCEXP152.SYS, связанный с SysInternals Process Explorer, который пользователь запустил интерактивно.

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

Вывод плагина modscan похож на только что показанный. Однако имеются несколько ключевых отличий:

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

• Модули отображаются в порядке обнаружения, а не в порядке загрузки.

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

Список выгруженных модулей также может пригодиться при криминалистическом анализе и расследовании вредоносных программ, особенно когда руткиты пытаются быстро выгрузиться (то есть действуют по принципу «войти и выйти»). Как показано в следующем примере с вариантом Rustock.C, модуль xxx.sys нельзя найти ни в списке активных модулей, ни путем сканирования по тегу пула. Однако в совершенно иной структуре данных ядро помнит, что вредоносный модуль когда-то был загружен.

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

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

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

Обратите внимание, что выходной файл получает имя driver.ADDR.sys, где ADDR является базовым адресом модуля в памяти ядра. Поскольку в каждый момент времени данный адрес может занимать только один модуль, такое соглашение об именовании гарантирует уникальность имен выходных файлов (в отличие от именования по имени модуля, которое может приводить к конфликтам).

В следующем примере модули извлекаются с помощью регулярного выражения без учета регистра. Критерию tcp соответствуют два модуля: tcpip.sys и tcpipreg.sys.

Хотя поиск по регулярному выражению удобен, следует помнить, что иногда имени, по которому можно выполнить поиск, не будет (например, если структуры метаданных перезаписаны или заголовок PE найден в анонимном выделенном блоке пула ядра). В таких случаях можно указать базовый адрес (где видна сигнатура MZ), и moddump выполнит извлечение. В следующем примере предполагается, что PE-файл находится по адресу 0xfffff88003800000:

Если извлеченный модуль планируется загрузить в IDA Pro для статического анализа, помните одно: адрес ImageBase в заголовке PE необходимо изменить так, чтобы он совпадал с реальным адресом загрузки в памяти ядра. Иными словами, для последнего показанного примера следует использовать 0xfffff88003800000. Вот как это можно сделать с помощью модуля Python pefile с сайта code.google.com:

Это простое исправление предоставляет IDA Pro дополнительный контекст, необходимый для правильного отображения относительных вызовов функций, переходов и ссылок на строки. В зависимости от состояния таблицы адресов импорта двоичного файла может также потребоваться плагин Volatility impscan, чтобы сформировать метки, которые можно применить к базе данных IDA. Пример использования impscan будет показан далее в этой главе (см. также «Рецепт 16-8: сканирование импортированных функций с помощью ImpScan» в книге Malware Analyst’s Cookbook).

Когда модули ядра создают новые потоки с помощью PsCreateSystemThread, владельцем потока становится процесс System (PID 4 в XP и более новых версиях). Иными словами, процесс System является стандартным местом для потоков, запускающихся в режиме ядра. Этот факт можно исследовать с помощью Process Explorer и увидеть, что начальные адреса потоков, принадлежащих процессу System, представляют собой смещения внутри таких модулей ядра, как ACPI.sys и HTTP.sys (см. рисунок 13-3).

Рисунок 13-3. Потоки, запускающиеся в режиме ядра, принадлежат процессу System.

При разборе дампа памяти эти системные потоки можно отличать от остальных по следующим признакам:

• Значение _ETHREAD.SystemThread равно 1.

• В члене _ETHREAD.CrossThreadFlags установлен флаг PS_CROSS_THREAD_FLAGS_SYSTEM.

• Процессом-владельцем является PID 4.

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

На рисунке 13-4 показаны потоки, принадлежащие процессу System на машине, зараженной Tigger. Видно присутствие четырех новых потоков, которых не было на рисунке 13-3. Process Explorer показывает только начальный адрес потока вместо обычного формата, например driverName.sys+0xabcd, поскольку начальный адрес не попадает в диапазон памяти ни одного загруженного модуля.

Рисунок 13-4. Process Explorer показывает четыре новых потока без известного модуля ядра.

Плагин threads помогает выявлять попытки скрыться описанным способом. Он перечисляет загруженные модули путем обхода двусвязного списка и записывает их базовые адреса и размеры. Затем он сканирует системные потоки и проверяет, находится ли значение _ETHREAD.StartAddress в диапазоне одного из модулей. Если плагин не может сопоставить поток с владеющим им драйвером, он предполагает, что поток отсоединен или скрыт. По этой причине такие потоки также стали известны как потоки-сироты. Следующий вывод показывает, как потоки-сироты выглядят в дампах памяти. Отображается тег OrphanThread, а справа от начального адреса (0xf2edd150) указано UNKNOWN.

Если вы подозреваете наличие руткита ядра в исследуемой системе, но не можете найти подтверждающие свидетельства с помощью плагинов modules или modscan, рекомендуем проверить потоки-сироты. Однако следует помнить, что начальный адрес потока будет указывать на функцию внутри вредоносного PE-файла, а не на базовый адрес PE-файла. Поэтому для поиска сигнатуры MZ могут потребоваться некоторые вычисления. Ближе к концу главы будет показан скрипт volshell, способный сканировать назад от заданного адреса в поисках первого допустимого заголовка PE.

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

Добавим немного исходной информации. Приложения в Windows взаимодействуют с драйверами, отправляя пакеты запросов ввода-вывода (I/O Request Packets, IRP). IRP представляет собой структуру данных, включающую целое число для обозначения требуемой операции (создание, чтение, запись и так далее) и буферы для всех данных, которые драйвер должен прочитать или записать. Каждый объект драйвера имеет таблицу из 28 указателей на функции, которые он может зарегистрировать для обработки различных операций. Обычно драйвер настраивает эту таблицу, известную как таблица основных функций или таблица функций IRP, в своей процедуре точки входа сразу после загрузки. Следующий вывод показывает, что таблица из 28 указателей с именем MajorFunction является частью каждого объекта драйвера:

Ключевые моменты таковы:

• DeviceObject: указатель на первое устройство, созданное драйвером. Если драйвер создает более одного устройства, они объединяются в связанный список. Например, драйвер TCP/IP создает устройства с именами RawIp, Udp, Tcp и Ip.

• DriverStart: копия базового адреса модуля ядра.

• DriverSize: размер в байтах модуля ядра, описываемого объектом драйвера.

• DriverExtension: указывает на структуру с членом ServiceKeyName, который сообщает путь внутри реестра, где хранится конфигурация этого драйвера.

• DriverName: имя объекта драйвера, например \Driver\Tcpip или \Driver\HTTP.

• DriverInit: указатель на процедуру инициализации драйвера.

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

• MajorFunction: массив из 28 указателей на основные функции. Перезаписывая индекс этого массива, руткиты могут перехватывать определенные операции.

Команда Volatility driverscan находит объекты драйверов путем сканирования по тегу пула. Вот пример ее вывода:

В крайнем левом столбце отображается физическое смещение структуры _DRIVER_OBJECT. Затем в столбце Start показан начальный адрес драйвера в памяти ядра. Чтобы понять, чем это может быть полезно, учтите, что адрес для \Driver\mouclass должен совпадать с базовым адресом mouclass.sys, показанным плагином modules или modscan. Поэтому, если вредоносная программа скрывает или стирает KLDR_DATA_TABLE_ENTRY, все равно остается _DRIVER_OBJECT с не меньшим (а возможно, и большим) объемом сведений о загруженных в системе модулях.

Руткиты могут перехватывать записи в таблице функций IRP драйвера. Например, перезаписав функцию IRP_MJ_WRITE в таблице IRP драйвера, руткит может проверять буфер данных, которые должны быть записаны по сети, на диск или даже на принтер. Другим распространенным примером является перехват IRP_MJ_DEVICE_CONTROL для tcpip.sys. Когда в действующей системе используется netstat.exe или SysInternals TcpView.exe, активные соединения и сокеты определяются через этот канал связи. Следовательно, перехватив его, руткиты могут легко скрывать сетевую активность.

Чтобы обнаружить перехваты функций IRP, достаточно найти в памяти структуры _DRIVER_OBJECT, прочитать 28 значений массива MajorFunction и определить, куда они указывают. Хотя, как вскоре будет показано, плагин driverirp полностью автоматизирует эту работу, он не сообщает однозначно, какие записи перехвачены: от вас все равно требуются анализ и интерпретация. Причина в том, что существуют легитимные случаи, когда драйвер перенаправляет свой обработчик другому драйверу, создавая видимость перехвата.

Ниже приведен пример вывода плагина driverirp для драйвера Tcpip в чистой 64-разрядной системе:

Драйвер Tcpip начинается по адресу 0xfffff880016bb000 и занимает 0x20400 байт. Большинство его обработчиков указывает либо на функцию внутри tcpip.sys (операции, обрабатываемые самостоятельно), либо на другой модуль (перенаправленные операции). Если драйвер не собирается обрабатывать определенные операции, он не оставляет указатели нулевыми, а направляет IRP на nt!IopInvalidDeviceRequest: это всего лишь фиктивная функция в модуле NT, действующая как проваливание (подобно ветви default в операторе switch языка C).

Ниже приведен пример 32-разрядной машины XP, где процедура IRP_MJ_DEVICE_CONTROL драйвера Tcpip действительно была перехвачена:

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

TDL3 является примером руткита, который обходит обычный метод обнаружения перехватов IRP. В следующем выводе все обработчики IRP для vmscsi.sys ведут к функции, которая на первый взгляд указывает, что запрос не перенаправляется и не перехватывается. В частности, все они указывают на 0xf9db9cbd, находящийся в диапазоне памяти драйвера vmscsi.sys.

Рассмотрим схему на рисунке 13-5, которая показывает, как руткит TDL3 все равно может получить контроль над всеми операциями, предназначенными для драйвера vmscsi.sys.

Рисунок 13-5. TDL3 обходит обнаружение перехватов IRP, используя заглушку-перенаправитель внутри драйвера-жертвы.

Схема показывает, что обычные руткиты перезаписывают записи таблицы IRP и направляют их за пределы памяти владеющего ими драйвера. TDL3, напротив, записывает небольшой блок кода в память владеющего драйвера (в данном случае vmscsi.sys) и использует его как отправную точку для перехода к коду руткита. В этом сценарии функции IRP по-прежнему указывают внутрь vmscsi.sys, поэтому определить компрометацию драйвера очень трудно. Если передать driverirp флаг --verbose либо дизассемблировать функцию-обработчик с помощью плагина volshell, можно увидеть, что она содержит лишь следующее:

Первая инструкция разыменовывает указатель по адресу 0xffdf0308. Затем посредством инструкции JMP процессор перенаправляется по адресу, расположенному со смещением 0xFC от указателя в EAX. Эти переходы легко проследить в volshell, как показано ниже:

Теперь известно, что настоящий код руткита занимает область около 0x81926e31. Каким бы образом руткит ни скрывался, помните: он всегда должен сохранять работоспособность. Функциональность этого руткита включала перехват IRP, и, проследовав по перехватам, вы попали прямо к телу вредоносного модуля.

В типичной системе работают сотни драйверов, поэтому проанализировать все 28 указателей на основные функции каждого драйвера невозможно, особенно если применяются скрытные методы перехвата. Мы рекомендуем сосредоточиться на наиболее ценных целях. Например, злоумышленников будут интересовать IRP_MJ_READ и IRP_MJ_WRITE драйверов файловой системы. Кроме того, их будет интересовать IRP_MJ_DEVICE_CONTROL сетевых драйверов, таких как \Driver\Tcpip, \Driver\NDIS и \Driver\HTTP.

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

На рисунке 13-6 приведена упрощенная схема того, как руткит может использовать многоуровневую архитектуру драйверов. Суть в том, что вредоносный драйвер занимает такое место в стеке, чтобы «проверять» запрошенную операцию независимо от источника запроса. В данном случае он присоединился к стеку драйвера ATA (atapi.sys) и фильтровал попытки записи в определенные секторы жесткого диска. Поэтому неважно, пытается ли удалить защищенный файл приложение пользовательского режима или антивирусный драйвер режима ядра: драйвер руткита все равно получает возможность заблокировать или отбросить запрос.

Рисунок 13-6. Вредоносный фильтрующий драйвер может проверять, регистрировать и/или предотвращать попытки чтения с диска или записи на него.

Чтобы осуществлять описанное поведение, драйвер сначала создает именованное или неименованное устройство определенного типа (то есть устройство файловой системы, сетевое устройство), вызывая IoCreateDevice. Возвращаемое этой функцией значение становится объектом исходного устройства. Затем драйвер получает указатель на объект целевого устройства с помощью IoGetDeviceObjectPointer. Он передает оба объекта устройств функции IoAttachDeviceToDeviceStack, которая завершает настройку. Объект исходного устройства теперь может получать IRP, предназначенные целевому устройству. В качестве альтернативы аналогичным образом можно использовать IoAttachDevice. Следующий код показывает объект устройства для 64-разрядной Windows 7:

Ключевые моменты таковы:

• DriverObject: указатель обратно на собственный драйвер устройства.

• NextDevice: односвязный список других устройств, созданных тем же драйвером.

• AttachedDevice: односвязный список устройств (обычно созданных другими драйверами), присоединенных к этому стеку.

• CurrentIrp: текущий IRP, обрабатываемый данным устройством.

• DeviceExtension: непрозрачный (неопределенный) член, способный хранить любые пользовательские структуры данных и данные конфигурации, необходимые устройству. Например, драйвер Truecrypt хранит главные ключи шифрования в расширении своего устройства.

• DeviceType: задает тип устройства, например FILE_DEVICE_KEYBOARD, FILE_DEVICE_NETWORK или FILE_DEVICE_DISK.

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

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

KLOG создал драйвер с именем \Driver\klog, затем создал неименованное устройство, обозначенное (?), типа FILE_DEVICE_KEYBOARD и присоединил его к устройству KeyboardClass0, принадлежащему \Driver\Kbdclass. Аналогичный эффект можно увидеть, если установить утилиту Ctrl2cap от SysInternals (technet.microsoft.com), поскольку она использует тот же многоуровневый подход с драйверами, чтобы преобразовывать символы caps-lock в управляющие символы.

Следующий пример показывает изменения, внесенные в систему драйвером ядра Stuxnet (\Driver\MRxNet):

Неименованное устройство, созданное \Driver\MRxNet, является крайним внешним устройством, присоединенным к драйверам файловых систем vmhgfs (VMware Host to Guest File System), MRxSmb (SMB), Cdfs и Ntfs. Теперь Stuxnet может фильтровать или скрывать файлы и каталоги с конкретными именами в этих файловых системах.

Таблица дескрипторов системных служб (System Service Descriptor Table, SSDT) содержит указатели на функции режима ядра. Как показано на рисунке 13-7, когда приложения пользовательского режима запрашивают системные службы, например запись в файл или создание процесса, небольшая заглушка в ntdll.dll (или другой библиотеке пользовательского режима) помогает вызывающему потоку управляемым образом перейти в режим ядра. Переход выполняется путем выдачи инструкции INT 0x2E в Windows 2000 либо с помощью SYSENTER в XP и более новых версиях. Оба метода вначале приводят в функцию с именем KiSystemService, которая ищет в SSDT адрес запрошенной функции ядра. Поиск основан на индексе, поскольку таблицы вызовов представляют собой массивы указателей.

Рисунок 13-7. Высокоуровневая схема роли SSDT в диспетчеризации системных вызовов.

Порядок и общее количество функций в SSDT различаются в разных версиях операционной системы. Например, в 64-разрядной Windows 7 NtUnloadDriver находится по индексу 0x184, а в 64-разрядной Windows 8 - по индексу 0x1A1. Следует также учитывать, что в каждой системе имеется более одной таблицы вызовов. Первая и наиболее известная таблица хранит функции собственного API, предоставляемые исполнительным модулем ядра (ntoskrnl.exe, ntkrnlpa.exe и так далее). Вторая таблица, известная как теневая SSDT, хранит функции GUI, предоставляемые win32k.sys. Как показано на рисунке 13-7, остальные две таблицы по умолчанию не используются, если только не запущен сервер IIS: в этом случае третью таблицу использует spud.sys (драйвер службы IIS).

Следующий код показывает соответствующие структуры данных для 64-разрядной системы Windows 7. Символы nt!KeServiceDescriptorTable и nt!KeServiceDescriptorTableShadow являются экземплярами _SERVICE_DESCRIPTOR_TABLE, содержащими до четырех дескрипторов (записей). Каждый дескриптор имеет член KiServiceTable, который указывает на массив функций, а ServiceLimit задает количество функций в массиве.

Для перечисления SSDT в дампах памяти Windows можно использовать плагин ssdt. Из-за различий между 32- и 64-разрядными версиями плагин находит данные SSDT совершенно разными способами, но формат вывода остается единообразным. В частности, в 32-разрядной Windows мы перечисляем все объекты потоков и собираем уникальные значения члена _ETHREAD.Tcb.ServiceTable. На 64-разрядных платформах этого члена нет, поэтому вместо этого мы дизассемблируем экспортированную функцию nt!KeAddSystemServiceTable и извлекаем относительные виртуальные адреса (RVA) символов KeServiceDescriptorTable и KeServiceDescriptorTableShadow, как показано на рисунке 13-8.

Рисунок 13-8. RVA таблиц SSDT и Shadow SSDT доступны из API KeAddSystemServiceTable.

Вот как выглядит вывод плагина ssdt на чистой машине с 64-разрядной Windows 7:

Как показано, таблица по адресу 0xfffff800028dc300 является SSDT[0], то есть первым дескриптором в массиве _SERVICE_DESCRIPTOR_TABLE.Descriptors. Иными словами, эта таблица предназначена для собственных API, экспортируемых модулем NT. Таблица по адресу 0xfffff960001a1f00 является SSDT[1] (вторым дескриптором), а значит, это таблица API подсистемы GUI. Все показанные функции принадлежат надлежащему модулю (либо модулю NT, либо win32k.sys).

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

Этот метод состоит в перезаписи указателей в SSDT для перехвата отдельных функций. Для этого обычно требуются базовый адрес таблицы вызовов в памяти ядра и индекс функции, которую нужно перехватить. Таблицу вызовов можно найти несколькими способами, но вредоносные программы часто используют MmGetSystemRoutineAddress (версию GetProcAddress для ядра), чтобы найти символ KeServiceDescriptorTable, экспортируемый модулем NT. Затем они обращаются к члену ServiceTable. Для непосредственной замены указателя часто используется API InterlockedExchange.

Все адреса в таблице собственных функций должны указывать внутрь модуля NT, а все адреса в таблице функций GUI - внутрь win32k.sys. В этом отношении обнаружение перехватов SSDT просто: достаточно проверить каждую запись и определить, указывает ли она на правильный модуль. Ниже показан образец вредоносной программы, который перехватывает различные функции и направляет их на модуль с именем lanmandrv.sys. Результаты можно отфильтровать с помощью egrep -v, исключив легитимные модули:

Руткит перехватывает четыре функции: NtEnumerateValueKey для сокрытия значений реестра, NtOpenProcess и NtQuerySystemInformation для сокрытия активных процессов и NtQueryDirectoryFile для сокрытия файлов на диске. Несмотря на несколько вводящее в заблуждение имя (lanmandrv.sys звучит как легитимный компонент), модуль выделяется, поскольку не должен обрабатывать API, обычно реализуемые модулем NT.

Злоумышленники хорошо знают методы, используемые для обнаружения изменений, которые их инструменты вносят в системы. Поэтому вместо направления функций SSDT за пределы модуля NT или win32ks.sys они могут просто использовать метод внутреннего перехвата. Он также перенаправляет выполнение вредоносной функции, но делает это менее очевидно. Вот как выглядел перехват NtEnumerateKey руткитом Skynet (для проверки таких внутренних перехватов мы добавили флаг --verbose):

Указатель 0x80570d64 действительно принадлежит ntoskrnl.exe, но инструкции по этому адресу перезаписаны инструкцией JMP, ведущей к 0x820f1b3c. Поэтому, если проверить только первоначальный модуль-владелец, факт перехвата SSDT этой вредоносной программой останется незамеченным.

Каждый поток в 32-разрядной системе имеет член _ETHREAD.Tcb.ServiceTable, идентифицирующий используемую им таблицу SSDT. Хотя возможность назначать таблицы вызовов отдельно для каждого потока неприменима к 64-разрядным системам, по существу она означает, что каждый поток может «смотреть» на другую SSDT в зависимости от значения своего члена ServiceTable. В таком случае вредоносная программа может создать копию таблицы собственных функций, перехватить несколько функций, а затем обновить значение ServiceTable конкретного потока или всех потоков конкретного процесса так, чтобы оно указывало на новую копию. В результате многие инструменты не сообщают о перехватах SSDT, поскольку проверяют только исходную таблицу, а не копии.

Ниже приведен пример вывода плагина ssdt при анализе дампа памяти, зараженного Blackenergy. Показаны только соответствующие строки:

Обратите внимание, что присутствуют три разных экземпляра SSDT[0], тогда как в типичной системе имеется лишь один. Определить, что таблица по адресу 0x80501030 является исходной чистой копией, можно потому, что NtWriteVirtualMemory указывает на модуль NT. Однако обе таблицы по адресам 0x814561b0 и 0x81882980 перехвачены: их версии NtWriteVirtualMemory указывают на модуль с именем 00000B9D.

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

• Patchguard: в 64-разрядных системах перехват SSDT предотвращает Kernel Patch Protection (KPP), также известная как Patchguard.

• Несколько ядер: таблицы системных вызовов не являются структурой, отдельной для каждого процессора. Поэтому, пока одно ядро пытается применить перехват, другое может пытаться вызвать API.

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

• Недокументированные API: многие функции SSDT не документированы Microsoft и могут изменяться между версиями Windows. Поэтому написать переносимый и одновременно надежный руткит бывает трудно.

Обратные вызовы ядра, или процедуры уведомления, являются новыми перехватами API. Они решают многие описанные ранее проблемы перехватов SSDT. В частности, они документированы, поддерживаются в 64-разрядных системах и безопасны для многоядерных машин; кроме того, совершенно нормально, когда несколько модулей регистрируются для одного типа события. В следующем списке описаны различные типы событий, которые обнаруживает плагин Volatility callbacks:

• Создание процесса: эти обратные вызовы устанавливаются с помощью API PsSetCreateProcessNotifyRoutine; на них полагаются утилита Process Monitor от SysInternals, различные антивирусные продукты и многие руткиты. Они срабатывают при запуске или завершении процесса.

• Создание потока: эти обратные вызовы устанавливаются с помощью API PsSetCreateThreadNotifyRoutine. Они срабатывают при запуске или завершении потока.

• Загрузка образа: эти обратные вызовы устанавливаются с помощью API PsSetLoadImageNotifyRoutine. Они предназначены для предоставления уведомлений, когда в память отображается любой исполняемый образ, например процесс, библиотека или модуль ядра.

• Завершение работы системы: эти обратные вызовы устанавливаются с помощью API IoRegisterShutdownNotification. В этом случае обработчик IRP_MJ_SHUTDOWN целевого драйвера вызывается, когда система готовится к выключению.

• Регистрация файловой системы: чтобы получать уведомления о появлении новой файловой системы, используется API IoRegisterFsRegistrationChange.

• Отладочное сообщение: для перехвата отладочных сообщений, выдаваемых модулями ядра, используется API DbgSetDebugPrintCallback.

• Изменение реестра: драйверы могут вызывать CmRegisterCallback (Windows XP и 2003) или CmRegisterCallbackEx (Windows Vista и более новые версии), чтобы получать уведомления, когда любой поток выполняет операцию с реестром.

• PnP (Plug and Play): эти обратные вызовы устанавливаются с помощью API IoRegisterPlugPlayNotification и срабатывают при добавлении, удалении или изменении устройств PnP.

• Проверки ошибок: эти обратные вызовы устанавливаются с помощью функций API KeRegisterBugCheckCallback или KeRegisterBugCheckReasonCallback. Они позволяют драйверам получать уведомление при проверке ошибок (необработанном исключении), предоставляя возможность сбросить конфигурации устройств или добавить сведения о состоянии конкретного устройства в файл аварийного дампа (например, перед появлением синего экрана смерти [BSoD]).

Следующий пример показывает работу плагина callbacks в чистой системе с 64-разрядной Windows 7. Хотя для краткости вывод сокращен, в этой системе было установлено около 80 обратных вызовов разных типов. Столбец Callback сообщает адрес функции которая вызывается при наступлении интересующего события. Столбец Module сообщает имя модуля ядра, занимающего память функции обратного вызова. В зависимости от типа обратного вызова можно также увидеть имя объекта драйвера или описание компонента, установившего обратный вызов.

Многие известные руткиты, такие как Mebroot, ZeroAccess, Rustock, Ascesso, Tigger, Stuxnet, Blackenergy и TDL3, используют обратные вызовы ядра. В большинстве случаев они также пытаются скрыться, исключая KLDR_DATA_TABLE_ENTRY из списка или выполняясь как поток-сирота из пула ядра. Из-за такого поведения вредоносные обратные вызовы легко заметить, поскольку столбец Module в выводе плагина Volatility callbacks показывает UNKNOWN. В других случаях авторы вредоносных программ вообще не скрывают модуль, но используют жестко заданное (а значит, предсказуемое) имя, по которому можно создавать индикаторы компрометации (IOC).

Первый пример относится к Stuxnet. Он загружает два модуля: mrxnet.sys и mrxcls.sys. Первый устанавливает обратный вызов изменения регистрации файловой системы, чтобы получать уведомление о появлении новых файловых систем (и сразу распространяться или скрывать файлы). Второй устанавливает обратный вызов загрузки образа, который используется для внедрения кода в процессы, когда они пытаются загрузить другие динамически подключаемые библиотеки (DLL).

Следующий пример относится к Rustock.C. Он регистрирует обратный вызов проверки ошибок, чтобы очистить свою память до создания аварийного дампа (см. отчет Фрэнка Болдевина: reconstructer.org). Его артефакты видны в этом дампе памяти только потому, что память была получена не в виде аварийного дампа, а в необработанном формате.

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

Руткит Blackenergy устанавливает обратный вызов создания потока, чтобы немедленно заменять указатель _ETHREAD.Tcb.ServiceTable во всех потоках, запускающихся в системе. Как обсуждалось в разделе «Дублирование таблицы» этой главы, в 32-разрядных системах член ServiceTable указывает на таблицу системных вызовов, в которой находятся адреса всех API режима ядра.

Поиск и анализ обратных вызовов являются критически важной частью криминалистического анализа памяти ядра. Удивительно, но для действующих систем не существует инструментов системного администрирования и имеется очень мало инструментов против руткитов, анализирующих обратные вызовы ядра (RkU - Rootkit Unhooker является одним из них). Даже собственный отладчик Microsoft по умолчанию не обладает такой возможностью. Однако Скотт Нун (analyze-v.com) и Матье Суиш (moonsols.com) опубликовали скрипты, помогающие заполнить этот пробел.

Чаще всего вредоносные программы используют таймеры для синхронизации и уведомления. Драйвер руткита может создать таймер (обычно вызвав KeInitializeTimer), чтобы получить уведомление по истечении заданного времени. Если вам кажется, что это похоже на простой вызов Sleep, вы правы. Однако вызов Sleep переводит поток в спящее состояние и не позволяет ему выполнять другие действия во время ожидания, в отличие от уведомлений на основе таймеров. Кроме того, Sleep не создает дополнительных криминалистических артефактов. Можно также создавать таймеры, которые сбрасываются после истечения. Иными словами, вместо однократного уведомления поток может получать уведомления периодически. Возможно, руткит хочет каждые пять минут проверять, разрешается ли имя узла DNS, или каждые две секунды опрашивать заданный раздел реестра на предмет изменений. Таймеры прекрасно подходят для таких задач.

При создании таймеров драйверы могут предоставить процедуру DPC, также известную как отложенный вызов процедуры. Когда срок таймера истекает, система вызывает заданную процедуру. Адрес процедуры или функции хранится в структуре _KTIMER вместе со сведениями о том, когда (и как часто) выполнять процедуру. Теперь становится понятно, почему таймеры ядра являются столь полезными артефактами для криминалистического анализа памяти. Руткиты загружают драйверы в память ядра и всеми силами стараются остаться незамеченными. Но использование таймеров дает четкий индикатор того, где руткит скрывается в памяти. Нужно лишь найти объекты таймеров.

С годами Microsoft меняла способ и место хранения таймеров в памяти. Например, в Windows 2000 символ nt!KiTimerTableListHead указывал на массив из 128 структур _LIST_ENTRY для _KTIMER. Позднее размер массива изменился на 256, затем на 512, пока наконец символ nt!KiTimerTableListHead не был полностью удален в Windows 7. Теперь объекты таймеров можно находить через структуру области управления каждого процессора (_KPCR). Подробнее об этих изменениях см. в статье Ain’t Nuthin But a K(Timer) Thing, Baby: mnin.blogspot.com.

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

Кроме того, тот же вариант Rustock.C, который анализировался в разделе «Вредоносные обратные вызовы», установил несколько таймеров. Он также пытается скрыть свой модуль ядра, оставляя следы подозрительной активности, которые легко увидеть с помощью плагина timers.

Как отмечалось в предыдущем анализе, хотя в этих случаях имя вредоносного модуля неизвестно, у вас по крайней мере имеются указатели на области памяти ядра, где находится код руткита. Затем его можно дизассемблировать с помощью volshell или извлечь код в отдельный файл для статического анализа в IDA Pro либо других средах.

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

Следующий вывод показывает пример работы плагина unloadedmodules. Как уже упоминалось, ядро ведет этот список для целей отладки. Например, модуль может поставить в очередь отложенный вызов процедуры (Deferred Procedure Call, DPC) или запланировать таймер, а затем выгрузиться, не отменив его. Поэтому при вызове процедуры предполагаемая функция-обработчик уже отсутствует в памяти. Это может привести к проблеме висячего указателя и непредсказуемым последствиям. Если бы ядро не сохраняло этот список недавно выгруженных модулей и ранее занятых ими диапазонов адресов, определить модуль с ошибкой было бы почти невозможно.

Сеансы являются самыми внешними контейнерами ландшафта GUI, как показано на рисунке 14-1. Когда пользователи входят в систему через консоль, RDP или быстрое переключение пользователей, ядро создает новый сеанс, который по существу является контейнером для процессов и объектов (таких как оконные станции и рабочие столы, рассматриваемые далее), принадлежащих сеансу. Дамп ОЗУ содержит сведения об активных, а в некоторых случаях и завершенных сеансах входа, включая связанные с ними процессы, модули ядра, диапазоны адресов выделений пула и таблицы страниц.

Ваши цели таковы:

• Связать процессы с пользователями RDP: если вы видите работающий процесс и хотите узнать, запустил ли его пользователь через RDP, сведения из этого раздела помогут это выяснить.

• Обнаружить скрытые процессы: каждая структура сеанса содержит связанный список процессов этого сеанса. Если вредоносная программа исключает процесс из PsActiveProcessHead (см. главу 6), этот альтернативный список процессов можно использовать для выявления скрытого процесса.

• Определить драйверы ядра: каждая структура сеанса содержит список драйверов, отображенных в сеанс. С его помощью можно отличать сеансы RDP от консольных сеансов.

Основной структурой сеанса является _MM_SESSION_SPACE. Это большая структура, поэтому в следующем коде для 64-разрядной Windows 7 показана лишь небольшая ее часть. Найдя все структуры _EPROCESS (путем обхода списка или сканирования пула) и просмотрев уникальные указатели _EPROCESS.Session, можно собрать полный список структур _MM_SESSION_SPACE. Каждый сеанс имеет собственный список рабочего набора, список быстрого поиска, страничный пул, каталог страниц и таблицы отслеживания больших страниц пула.

Ключевые моменты таковы:

• SessionId: уникально идентифицирует сеанс. В Windows XP и Server 2003 один сеанс (сеанс 0) совместно используется системными службами и пользовательскими приложениями. Начиная с Vista Microsoft ввела «изоляцию сеанса 0» для предотвращения атак с разрушением окон (см. ссылки в разделе «Вредоносное использование окон»), после чего сеанс 0 предназначен только для системных служб.

• ProcessList: этот член можно использовать как альтернативный список процессов для процессов, скрывающихся посредством обычного DKOM (исключения из PsActiveProcessHead). Каждый процесс принадлежит ровно одному сеансу, за исключением процесса System и smss.exe. Во время инициализации процесса член _EPROCESS.Session обновляется и начинает указывать на _MM_SESSION_SPACE. Аналогичным образом ProcessList обновляется ссылкой на новый _EPROCESS. Процесс остается в этом списке до завершения.

• ImageList: список структур _IMAGE_ENTRY_IN_SESSION, по одной для каждого драйвера устройства, отображенного в пространство сеанса. Если имеется два сеанса, будет две копии win32k.sys. Поэтому криминалистические инструменты, которым требуется анализировать код или переменные в драйвере win32k.sys, должны извлекать его по одному разу для каждого сеанса.

Как показано в следующем коде для 32-разрядной системы Windows 2003, определить вход пользователя через RDP можно по тому, что в сеансе работают драйвер RDPDD.dll и процесс rdpclip.exe. RDPDD.dll является драйвером дисплея RDP, а rdpclip.exe - процессом, обрабатывающим операции удаленного буфера обмена. Теперь по этой связи известно, что mbamgui.exe, cmd.exe и notepad.exe (помимо прочих) были открыты или отображены через RDP, а не на консоли компьютера. Это очень полезно при реконструкции действий удаленного злоумышленника.

Следует помнить, что Volatility также может извлекать из ОЗУ истории команд и целые экранные буферы (подробнее см. в главе 17). Из предыдущего вывода известно, что cmd.exe был запущен через RDP, но с какой целью? Хотя протокол RDP допускает передачу файлов, она может быть включена не всегда, поэтому обычно злоумышленники передают файлы на свои сайты и с них по FTP. Пример показан в следующем коде (для защиты личности жертвы многие поля скрыты):

Как видите, всего несколько команд позволяют установить, что пользователь вошел в систему жертвы через RDP. Затем он использовал cmd.exe с идентификатором процесса 5544, чтобы найти определенные записи журнала IIS, и скопировал журналы на свой FTP-сайт. Можно увидеть адрес FTP-сервера, имя пользователя и пароль злоумышленника, а также точные файлы, которые его интересовали.

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

Справочную информацию об оконных станциях см. в материалах Sessions, Desktops, and Window Stations на TechNet (blogs.technet.com) и Window Stations and Desktops на MSDN (msdn.microsoft.com).

Перед вами стоят следующие цели:

• Слежение за буфером обмена: можно обнаруживать приложения, следящие за активностью буфера обмена.

• Использование буфера обмена: можно определить частоту использования буфера обмена и доступные форматы. Копировал ли вошедший пользователь данные в буфер обмена? Если да, то данные какого типа? Это пригодится, когда вы фактически извлечете содержимое буфера обмена из ОЗУ.

В следующем выводе показана интерактивная оконная станция WinSta0 для сеанса 2. Таблица атомов этой оконной станции находится по адресу 0xe7981648, она содержит три рабочих стола (Default, Disconnect и Winlogon), а rdpclip.exe в настоящее время просматривает буфер обмена. Это логично, поскольку rdpclip.exe является процессом, который обрабатывает операции копирования и вставки через RDP. Поддерживаются четыре формата буфера обмена, включая текст Unicode и ASCII, а судя по серийному номеру, пользователь к этому моменту скопировал в буфер обмена девять элементов.

Следующая оконная станция называется __X78B95_89_IW и содержит один рабочий стол с именем __A8D9S1_42_ID. Это стандартное соглашение об именовании, используемое inetinfo.exe, поэтому известно, что в тот момент в системе работал IIS.

Последняя оконная станция в примере - WinSta0 для сеанса 0. Хотя она интерактивна, значения cNumClipFormats и iClipSerialNumber равны 0, а значит, буфер обмена этой оконной станции никогда не использовался.

Рабочий стол - это контейнер для окон приложений и объектов пользовательского интерфейса. Вредоносные программы используют рабочие столы различными способами: от запуска приложений в альтернативных рабочих столах, чтобы текущий вошедший пользователь их не видел, до программ-вымогателей, которые блокируют пользователю доступ к его собственному рабочему столу до уплаты выкупа (см. тематическое исследование в главе 15).

Перед вами стоят следующие цели:

• Скрытые рабочие столы: находить посторонние рабочие столы, используемые для сокрытия приложений от вошедших пользователей.

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

• Поиск скрытых потоков: подсистема GUI определяет структуру tagTHREADINFO, которая не зависит от _ETHREAD и содержит сведения о потоке. Подобно тому как альтернативные списки процессов позволяют находить скрытые процессы, эту альтернативную структуру потока можно использовать для выявления потоков, когда другие методы не дают результата.

Плагин deskscan сканирует оконные станции, а затем обходит список рабочих столов (rpdeskList). В следующем выводе показаны WinSta0\Default, WinSta0\Disconnect и WinSta0\Winlogon.

Обратите внимание на следующее:

• Рабочий стол Winlogon отображает приглашение ко входу, в котором вводятся имя пользователя и пароль. Если вход выполнен успешно, система переключает пользователя на рабочий стол Default. Как и ожидалось, explorer.exe работает на рабочем столе Default; обратите внимание, что на этом же рабочем столе работают шесть разных потоков Explorer.

• Число окон на рабочем столе Default гораздо больше, чем на других (238 по сравнению с 25 в Disconnect и 6 в Winlogon). Чтобы позволить создать намного больше окон и других объектов, размер кучи рабочего стола Default также закономерно намного больше (0x300000 по сравнению с 0x10000 и 0x20000).

• Единственные потоки на рабочем столе Winlogon действительно принадлежат winlogon.exe. Если вы когда-либо увидите на этом рабочем столе потоки, принадлежащие другому процессу, это может указывать на попытку кражи учетных данных для входа.

• Единственный рабочий стол с установленными глобальными перехватами - Default, поскольку значение fsHooks ненулевое. Это значение подробнее объясняется в главе 15, а пока достаточно знать, что оно указывает на способность потоков рабочего стола перехватывать сообщения окон, например нажатия клавиш и движения мыши, прежде чем они достигнут целевого окна.

Атомы - это строки, которыми могут легко совместно пользоваться процессы одного сеанса. Вкратце, один процесс явно добавляет атом в таблицу атомов, передавая строку такой функции, как AddAtom или GlobalAddAtom. Эти API возвращают целочисленный идентификатор, который данный или другие процессы могут использовать для получения строки. Таблица атомов - это хеш-контейнер, содержащий соответствия целых чисел строкам.

Таблицы атомов чрезвычайно интересны с точки зрения криминалистического анализа, поскольку многие функции Windows API создают атомы неявно или косвенно. Авторы вредоносных программ используют эти API, но не знают об артефактах, которые оставляют в системе, поэтому и не пытаются замести следы. Кроме того, атомы склонны сохраняться дольше, чем иногда предполагалось. Например, у атомов есть счетчик ссылок, который автоматически увеличивается и уменьшается при их добавлении в таблицу атомов и удалении из нее. Согласно статье Microsoft About Atom Tables (technet.microsoft.com), строковые атомы остаются в таблице атомов, пока счетчик ссылок больше нуля, даже после завершения приложения, которое поместило их в таблицу.

Перед вами стоят следующие цели:

• Обнаружение имен классов окон: когда приложения используют RegisterClassEx для регистрации нового класса окна, имя класса добавляется в глобальную таблицу атомов.

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

• Выявление внедренных DLL: когда вредоносная программа использует SetWindowsHookEx или SetWinEventHook для установки соответственно перехватов сообщений или событий, путь на диске к DLL, содержащей функцию-перехватчик, добавляется в глобальную таблицу атомов. Подробнее об этих API рассказывается в главе 15.

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

Плагин atomscan сканирует память и сообщает об атомах в порядке их обнаружения. Однако при указании --sort-by=atom атомы из нескольких таблиц атомов сортируются отдельно по идентификатору атома. Кроме того, их можно отсортировать численно по счетчику ссылок, указав параметр --sort-by=refcount. Ниже приведен пример:

Можно увидеть множество строк, выполняющих в системе различные функции. Среди них пути к DLL, зарегистрированные сообщения окон (WM_HTML_GETOBJECT), имена классов и типы данных (text/css). Эти строки атомов во многом похожи на мьютексы: их настолько много, что невооруженным глазом трудно заметить аномальные. Примеры выявления подозрительных атомов рассматриваются в следующих разделах. Кроме того, всегда можно расширить плагины так, чтобы они выводили только атомы, соответствующие списку входных правил (например, IOC).

Когда приложения вызывают RegisterClassEx, они передают структуру WNDCLASSEX, инициализированную желаемыми свойствами нового класса. Модуль win32k.sys создает атом из члена lpszClassName этой структуры. Некоторые вредоносные программы пытаются действовать скрытно и создают пустые имена классов окон (" ") или используют непечатаемые символы ASCII, полагая, что их никто никогда не увидит. Такое поведение можно наблюдать по адресам 00401355 и 00401387 в дизассемблированном коде образца Mutihack на рисунке 14-6.

Рисунок 14-6. Оба API, вызванные mutihack, приводят к созданию новых атомов

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

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

За кулисами система создает атом на основе строки, указанной в параметре lpString.

Классический пример показан на рисунке 14-7 с дизассемблированным кодом вредоносной программы Clod. Регистрация сообщения окна WM_HTML_GETOBJECT - один из необходимых шагов для получения полностью маршалированного интерфейса IHTMLDocument2 (support.microsoft.com) из HWND (дескриптора окна). Иными словами, именно так Clod получает программируемое управление Internet Explorer, включая возможность добавлять, удалять или изменять элементы DOM либо проверять переменные формы при ее отправке, например учетные данные для банковских сайтов.

Рисунок 14-7. Clod регистрирует сообщение окна перед внедрением HTML

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

Однако вы, скорее всего, никогда не слышали об использовании атомов для обнаружения вредоносных программ. Немногие знают, что атомы могут использоваться и уже использовались для той же цели, что и мьютексы. Например, дизассемблированный код на рисунке 14-8 показывает, как Tigger использует атомы вместо мьютексов. Сначала он вызывает GlobalFindAtomA, чтобы проверить, существует ли на машине атом с именем ~Sun Nov 16 15:46:54 2008~. Если он существует, вредоносная программа завершается, предполагая, что уже выполнила заражение. В противном случае она вызывает GlobalAddAtomA, чтобы отметить машину как зараженную.

Рисунок 14-8. Tigger использует атомы, чтобы отметить свое присутствие

Следующая функция, показанная на рисунке 14-9, входит в цикл, который каждые 200 миллисекунд ищет атом с именем putas38. Она будет спать бесконечно, если атом так и не будет создан, либо до тех пор, пока другой поток не создаст атом, вследствие чего следующий код выйдет из цикла. Затем вредоносная программа приступает к перехвату различных функций API.

Рисунок 14-9. Tigger использует атомы для синхронизации

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

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

Перед вами стоят следующие цели:

• Проверка подлинности процессов: можно сопоставлять имена окон с процессами, которым они должны принадлежать. Например, explorer.exe всегда владеет окном с именем SysFader (окном, помогающим с анимацией). Если вы видите процесс с именем explorer.exe без такого окна, вероятно, это не настоящий Проводник Windows.

• Обнаружение ПО, противодействующего мониторингу: многие семейства вредоносных программ в качестве метода уклонения ищут имена окон, создаваемых антивирусами, средствами мониторинга и другими защитными приложениями. Например, они могут вызвать FindWindow в поисках окна Process Monitor - Sysinternals: www.sysinternals.com.

Так называется окно, создаваемое Process Monitor; затем вредоносная программа может попытаться завершить приложение. Либо она может искать окна, связанные с Wireshark, и просто отказаться выполняться при наличии любого из них.

• Криминалистический анализ метаданных: заголовки окон часто содержат метаинформацию, например системное время, имена вошедших пользователей, просматриваемые в данный момент веб-страницы и части команд cmd.exe.

В базовом списке процессов можно увидеть iexplore.exe и установить, что браузер был открыт, однако плагин windows позволяет углубиться до любого окна класса IEFrame и увидеть, какая страница просматривается в данный момент:

Старый механизм доставки эксплойтов заключался во включении исполняемого файла в сжатые файлы справки Windows (.chm). Стандартным средством просмотра CHM является hh.exe, который можно увидеть в списке процессов, однако, как показывает следующий код, можно также извлечь имя просматриваемой страницы. В данном случае это всего лишь файл справки для отладчика Windows, но если бы заголовок выглядел как Congrats, you won 10 million dollars, это могло бы подсказать, как машина изначально была заражена: доверчивый пользователь стал жертвой социальной инженерии.

Как показано в следующем выводе, окна класса TrayClockWClass обычно отображают текущее местное время компьютера. Аналогично окна класса Desktop User Picture раскрывают имя вошедшего в данный момент пользователя.

Плагин wintree менее многословен, чем плагин windows. Он предназначен для отображения связей между родительскими и дочерними окнами рабочего стола. Следующий код - предварительный просмотр дерева окон hh.exe: видно, что все окна видимы, начиная с HH Parent, затем HH Child, включая различные экземпляры Button, ComboBox, Edit, Toolbar и встроенное Shell DocObject View с Internet Explorer_Server. Именно поэтому файлы .chm так опасны: их содержимое визуализируется с помощью IE, а значит, простое открытие файла .chm может привести к срабатыванию любой уязвимости в IE.

Одна из ранних утилит GDI Брендана Долана-Гэвитта для Volatility включала плагин снимков экрана (moyix.blogspot.com). Плагин рисовал каркасы окон в виде прямоугольников в соответствии с их положением на рабочем столе. Это далеко не настоящий снимок экрана, но с точки зрения криминалистического анализа памяти результат тем не менее очень интересен, поскольку способен предоставить некоторый контекст того, что отображалось на экране компьютера во время захвата ОЗУ.

Внутреннее устройство плагина screenshot довольно простое. Он перечисляет окна каждого рабочего стола в их Z-порядке (фокус от переднего плана к заднему). Координаты каждого окна он берет из структуры tagWND и рисует прямоугольники с помощью Python Imaging Library (PIL).

Для демонстрации два пользователя вошли на одну и ту же машину с Windows 7, используя быстрое переключение пользователей. Каждый оставил открытыми различные окна. Затем была получена память и запущен плагин screenshot. Как показано в следующем коде, достаточно передать ему параметр -D/--dump-dir, указывающий, куда сохранять PNG-файлы.

Многие снимки экрана будут пустыми, поскольку окна отображаются не на всех рабочих столах. Да и зачем им там отображаться? На каждого пользователя приходится только одна интерактивная оконная станция (WinSta0), поэтому отображать окна внутри рабочих столов других оконных станций не имеет смысла.

Как вы увидите, Session1\WinSta0\Default (для первого вошедшего пользователя) и Session2\WinSta0\Default (для второго пользователя) хорошо совпадают при сопоставлении с миниатюрами реального вида экрана. На рисунке 14-10 экран первого пользователя находится в верхней левой панели, а вывод плагина - в нижней левой. Экран второго пользователя находится справа вверху, непосредственно над созданной плагином версией снимка.

Рисунок 14-10. Сравнение каркасных снимков экрана с реальным видом

Заголовки окон дают гораздо более ясное представление о происходящем в данный момент, что видно на следующем примере (см. рисунок 14-11) с реально скомпрометированной машины. Обратите внимание на предупреждение Trend Micro OfficeScan в 21:27 о двух заражениях вирусами.

Рисунок 14-11. Извлеченный снимок экрана показывает два предупреждения о вирусах

В области создания более реалистичных снимков экрана из дампов памяти еще предстоит поработать: нужны подписанные кнопки и отображаемый текст из панелей инструментов и полей редактирования, не говоря уже о цветах и градиентах. Однако основа заложена. Решение написать Volatility на Python оказалось удачным, поскольку благодаря этому он легко взаимодействует с такими библиотеками, как PIL, PyGame и тысячи других модулей для безопасности, обратного проектирования и криминалистики.

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

Сообщение окна по существу является уведомлением, отправляемым окну (либо в некоторых случаях транслируемым всем окнам) о том, что произошло определенное событие пользовательского интерфейса. Например, когда пользователь нажимает клавишу, система генерирует сообщение WM_KEYDOWN и доставляет его окну переднего плана или окну в фокусе с помощью API SendMessage или PostMessage. Как показывает следующий прототип функции, параметр Msg является одной из определенных системой констант WM_ (приложения также могут определять собственные коды для нестандартного поведения).

Параметры wParam и lParam хранят дополнительные сведения о сообщении, например была ли нажата клавиша Shift в момент нажатия другой клавиши. Если созданное сообщение относится к движению мыши, дополнительные параметры задают координаты X и Y нового положения.

Старые версии Kaspersky Antivirus (KAV) были уязвимы для атаки Shatter. Иными словами, потоки с меньшими привилегиями могли отправить окну __AVP.Root антивирусного механизма особым образом сформированное сообщение окна и заставить механизм прекратить защиту системы, фактически отключив антивирус. Tigger доставлял сообщение с помощью PostMessageA, как показано на рисунке 14-12. Специальные значения - WPARAM 0x466 и LPARAM 0x10001.

Рисунок 14-12. Tigger отключает KAV с помощью посторонних сообщений окон

Bankpatch отключает защиту файлов Windows и перезаписывает kernel32.dll, wininet.dll и другие системные DLL троянизированными копиями. Его цель - затем заставить все процессы загрузить вредоносные DLL. Поскольку не существует простого и стабильного способа заменить DLL в работающем процессе без перезапуска процесса, авторы Bankpatch решили использовать ExitWindowsEx для перезагрузки машины. Таким образом, при следующем запуске были бы загружены троянизированные копии.

Вредоносная программа использует архитектуру сообщений окон, чтобы закрыть любые запросы, создаваемые операционной системой из-за требования перезагрузки (например, You have unsaved work, do you really want to reboot?). Как показано на рисунке 14-13, вредоносная программа делает это, вызывая EnumWindows в цикле до выключения системы и передавая управление функции обратного вызова EnumFunc, которую мы рассмотрим далее.

Следующий дизассемблированный код на рисунке 14-14 показывает, что EnumFunc вызывает GetWindowTextA, чтобы искать текст, отображаемый внутри окна запроса. Если он начинается со строки Windows, функция использует GetDlgItem, чтобы выбрать кнопку OK, а затем публикует сообщение BM_CLICK в очереди сообщений потока окна. Это имитирует нажатие пользователем кнопки OK: система даже не подозревает, что все произошло автоматически. В итоге Bankpatch смог перезагрузить систему и скрыть все созданные всплывающие предупреждения без какого-либо участия пользователя.

Рисунок 14-13. Bankpatch использует EnumWindows для перехвата запросов

Рисунок 14-14. Bankpatch имитирует щелчок мышью

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

Blazgel - пример вредоносной программы, способной открыть рабочий стол Winlogon и имитировать нажатие пользователем Ctrl+Alt+Del для получения доступа к приглашению ко входу на случай, если включена экранная заставка с автоматической блокировкой. Для этого можно транслировать сообщение WM_HOTKEY с номером 0x2E0003 (MOD_ALT|MOD_CTRL|MOD_DEL), как показано на рисунке 14-15.

Рисунок 14-15. Blazgel имитирует Ctrl+Alt+Del

Следующий снимок на рисунке 14-16 показывает, как вредоносная программа туннелирует движения мыши по каналу управления. Один пакет отправляет строку EVENTMOUSE, если злоумышленники хотят имитировать движение мыши. Следующий пакет, прочитанный функцией с меткой Recv_Data, задает координаты X и Y, которые затем применяются с помощью SetCursorPos и инициируются посредством mouse_event. Объединяя эти две функции API, вредоносная программа может динамически управлять мышью из удаленного местоположения. Помните, что структура tagWND каждого окна помимо прочих значений содержит координаты X и Y, поэтому злоумышленники способны в любой момент точно определить место щелчка, ни разу фактически не увидев экран.

Два наиболее распространенных семейства вредоносных программ последнего десятилетия, Conficker и Stuxnet, распространялись путем заражения USB-накопителей файлами autorun.inf. Вы когда-нибудь задумывались, как вредоносная программа узнает точный момент подключения USB к компьютеру жертвы? Непрерывно ли она опрашивает доступные аппаратные устройства? Нет, на самом деле она использует несколько весьма интересных возможностей подсистемы GUI, чтобы пассивно ждать уведомления о подключении устройств.

Рисунок 14-16. Blazgel имитирует движения мыши

Conficker начинал с генерации случайной строки для использования в качестве имени класса окна, а затем создавал окно этого класса с помощью CreateWindowEx. Оконная процедура была настроена на отслеживание уведомлений WM_DEVICECHANGE, транслируемых по всей системе. Таким способом вредоносная программа могла немедленно обнаружить подключение новых USB-устройств и приступить к заражению. Дизассемблированный код на рисунке 14-17 показывает фрагмент двоичного файла Conficker, который настраивает новое окно:

Рисунок 14-17. Conficker использует окна для уведомлений USB

Подобно Conficker, Stuxnet начинал с регистрации класса окна, но вместо случайно сгенерированного имени использовал жестко заданное имя AFX64c313. Поэтому сканировать дамп памяти в поисках индикаторов компрометации Stuxnet по заголовкам и классам окон очень просто. Как вы помните из раздела о таблицах атомов, имена зарегистрированных классов окон становятся видимыми при использовании плагина atomscan. Ниже приведен пример того, что можно увидеть:

Следующая команда показывает артефакт CreateWindowEx. Обратите внимание, что окном владеет services.exe, поскольку это одна из целей Stuxnet для внедрения кода. Видимость окна установлена в False, поскольку оно не предназначено для показа пользователю, а оконная процедура находится по адресу 0x13fe695 в памяти services.exe.

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

Все функции оконных процедур должны принимать одинаковое число и тип параметров, а также возвращать значение одного и того же типа. Ниже показан прототип. Первый аргумент - дескриптор окна (hwnd), за ним следует целое число (uMsg), указывающее принимаемое сообщение. Это может быть любая из определенных системой констант WM_ (например, WM_PAINT, WM_KEYDOWN, WM_MOUSEMOVE) либо определенное приложением значение для поддержки нестандартных действий. Последние два параметра (wParam и lParam) содержат дополнительные сведения, различающиеся в зависимости от значения uMsg.

В прототипе функции мы пометили смещение каждого параметра относительно EBP (указателя базы стека). Эти сведения полезны, поскольку, увидев инструкции, обращающиеся к значениям по смещению (например, EBP+8), вы будете знать, что соответствующий параметр функции - hwnd. Помните об этом при просмотре вывода следующих команд volshell, дизассемблирующих функцию обратного вызова оконной процедуры по адресу 0x13fe695 для окна AFX64c313.

Как показано в предыдущем коде, по смещениям относительно EBP можно определить, что EBP+0xC хранит значение параметра uMsg. В данном случае оно сравнивается с 0x219, то есть сообщением WM_DEVICE_CHANGE. Система транслирует это сообщение, чтобы уведомить приложения об изменении аппаратной конфигурации устройства или компьютера. Поскольку изменения бывают разных типов, далее необходимо изучить значение, переданное как wParam: в подпрограмме оно сравнивается с 0x8000 (DBT_DEVICEARRIVAL). Этот параметр указывает, что устройство или носитель подключен и теперь доступен приложениям компьютера.

На основании кодов сообщений, которые ищет оконная процедура, теперь точно известно, зачем Stuxnet создал окно с именем AFX64c313.

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

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

На рисунке 14-18 показано, как вредоносная DLL вызывает CreateWindowExA, чтобы создать перекрывающееся окно класса button размером 10x10. Затем она использует SetWindowLongA с флагом GWL_WNDPROC, чтобы изменить оконную процедуру кнопки на функцию с меткой NewButtonWndProc. Теперь для кнопки создан подкласс, и ее поведение соответствует спецификации новой оконной процедуры.

Рисунок 14-18. Vundo создает подкласс кнопок для скрытых действий

Обратите внимание, что новую процедуру особенно интересуют сообщения WM_QUERYENDSESSION. Эти сообщения создаются, когда пользователь решает завершить сеанс либо когда приложение сеанса вызывает функцию выключения системы, например NtSystemShutdown. Поэтому NewButtonWndProc выполняется, когда пользователь выходит из системы либо компьютер готовится к перезагрузке или выключению.

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

В следующем выводе мы исследовали заражение с помощью плагина windows. Видно, что DLL была внедрена в procexp.exe - Process Explorer. Адрес функции оконной процедуры - 0x20a21a7, что не является стандартной оконной процедурой класса Button.

Дальнейшее исследование можно провести, дизассемблировав код процедуры:

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

Приложения могут устанавливать перехваты в подсистеме GUI Windows, чтобы настраивать взаимодействие с пользователем, получать уведомления о выполнении определенных действий или записывать все действия пользователя, например для создания учебного видео по работе с компьютером (CBT). Как вы, вероятно, и ожидали, вредоносные программы часто злоупотребляют таким доступом и управлением, чтобы перехватывать нажатия клавиш, внедрять вредоносные библиотеки динамической компоновки (DLL) в доверенные процессы и выполнять другие злонамеренные действия.

Когда пользователь нажимает клавишу, система создает сообщение WM_KEYDOWN и доставляет его (вместе с дополнительными сведениями, например о конкретной клавише, о том, была ли в этот момент нажата SHIFT, и так далее) в очередь целевого окна. Целевым обычно является окно переднего плана, находящееся в фокусе. Когда сообщение попадает в очередь, поток, владеющий окном, просыпается и обрабатывает сообщение: это может означать добавление введенного символа в поле редактирования текста, выполнение особого действия, если клавиша является горячей, или даже простое игнорирование. На рисунке 15-1 показана сильно упрощенная схема системы сообщений без перехвата.

Рисунок 15-1. Система сообщений окон без перехвата

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

На рисунке 15-2 показана работа системы сообщений при установленных перехватах. Когда создается сообщение, DLL, содержащая процедуру-перехватчик, отображается в адресное пространство указанных потоков, если она еще не загружена. Сообщение передается процедуре-перехватчику, которая обрабатывает его требуемым образом; наконец, если это разрешено, сообщение достигает целевой оконной процедуры для обычной обработки.

Рисунок 15-2. Вредоносная программа может встроить перехват в систему сообщений

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

Ниже описаны параметры:

• idHook - одна из констант WH_, например WH_KEYBOARD или WH_MOUSE. Она задает типы сообщений, которые следует отслеживать.

• lpfn - адрес процедуры-перехватчика, которая обрабатывает сообщение до целевого окна. Эта процедура является функцией типа HOOKPROC: она получает сообщение, обрабатывает его и при необходимости передает следующему перехватчику в цепочке (либо целевому окну, если других перехватчиков нет) с помощью CallNextHookEx.

• hMod - дескриптор DLL, содержащей процедуру-перехватчик. Эта DLL загружается в адресное пространство потока, владеющего целевым окном.

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

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

Перед вами стоят следующие цели:

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

• Атрибуция DLL: проследить функцию-перехватчик до содержащей ее DLL на диске.

• Анализ функции-перехватчика: проанализировать код функции-перехватчика, чтобы понять, какие взаимодействия с пользовательским интерфейсом (нажатия клавиш, движения мыши и так далее) отслеживаются.

Плагин messagehooks перечисляет глобальные перехваты, находя все рабочие столы и обращаясь к tagDESKTOP.pDeskInfo.aphkStart - массиву структур tagHOOK, положения которых в массиве указывают, какой тип сообщения должен фильтроваться (например, WH_KEYBOARD или WH_MOUSE). Значение tagDESKTOP.pDeskInfo.fsHooks используется как битовая карта, сообщающая, какие позиции массива активно используются. Аналогично для каждого потока плагин ищет локальные (то есть относящиеся к конкретному потоку) перехваты, проверяя tagTHREADINFO.aphkStart и tagTHREADINFO.fsHooks.

На рисунке 15-3 показан дизассемблированный код вредоносной программы Laqma, устанавливающей перехват WM_GETMESSAGE. Это пример использования вредоносной программой SetWindowsHookEx просто как средства загрузки DLL в другие процессы, а не для мониторинга или перехвата сообщений. Это можно понять по тому, что lpfnWndProc лишь передает управление следующему перехватчику в цепочке, вызывая CallNextHookEx. Обратите также внимание, что параметр dwThreadId равен 0: перехват является глобальным и повлияет на все потоки GUI того же рабочего стола, на котором выполняется вредоносная программа.

Запуск плагина messagehooks на дампе памяти, зараженном Laqma, дает примерно следующие результаты:

Рисунок 15-3. Laqma устанавливает перехват сообщений для внедрения Dll.dll в другие процессы

Как видите, все перехваты являются глобальными, поскольку флаги включают HF_GLOBAL. Это означает, что они являются непосредственным результатом вызова SetWindowsHookEx с параметром dwThreadId, равным 0. Хотя не все глобальные перехваты вредоносны, все виденные нами образцы вредоносных программ, перехватывающие сообщения окон, используют глобальные перехваты.

Разница между тремя показанными перехватами заключается в том, что первый является глобальным и был получен из структуры tagDESKTOP. Это видно по тому, что целевой поток указан как <any>. Запись сообщает, что любые потоки GUI, работающие на рабочем столе WinSta0\Default, подвергаются мониторингу вредоносной программой. Следующие два перехвата связаны с конкретными потоками (в результате глобального перехвата) и привели к внедрению Dll.dll в explorer.exe и VMwareUser.exe.

Из дизассемблированного кода на рисунке 15-3 уже известно, что lpfnWndProc не содержит специальной полезной нагрузки: этот перехват существует только для внедрения DLL в другие процессы. Однако не упускайте из виду, что плагин messagehooks показывает адрес процедуры-перехватчика в DLL как RVA. В приведенных примерах процедуру-перехватчик можно найти по смещению 0x1fd9 от базы Dll.dll в затронутых процессах. Поэтому, если назначение перехвата заранее неизвестно, можно легко использовать volshell, переключиться в контекст целевого процесса и дизассемблировать функцию.

Как показано в следующем коде, базовый адрес (0xac0000) внедренной DLL внутри explorer.exe можно найти с помощью плагина dlllist. Затем можно дизассемблировать код по смещению 0x1fd9. Обратите внимание, что функция состоит всего из нескольких инструкций, которые по существу передают свои аргументы в неизменном виде функции CallNextHookEx.

Последний артефакт, который следует отметить при использовании перехватов сообщений для внедрения DLL, заключается в добавлении полного пути на диске к вредоносной DLL в таблицу атомов. Как ранее описано в главе 14, таблицы атомов можно исследовать с помощью плагинов atoms или atomscan. В следующем выводе вы должны узнать строку Dll.dll:

Дескрипторы USER - это ссылки на объекты подсистемы GUI. Подобно тому как CreateFile возвращает HANDLE на _FILE_OBJECT, которым управляет диспетчер исполнительных объектов NT, CreateWindow возвращает HWND (дескриптор tagWND), которым управляет подсистема GUI. Существует либо 20 (от Windows XP до Vista), либо 22 (Windows 7) типа объектов USER, включая TYPE_FREE.

С точки зрения вредоносных программ и криминалистического анализа таблицы дескрипторов USER чрезвычайно ценны, поскольку предоставляют альтернативный способ поиска доказательств. Например, мы уже обсуждали, как находить окна и перехваты, но те же объекты можно найти, обходя таблицу дескрипторов USER. Поэтому, если злоумышленник проявит изобретательность и попытается скрыть объекты с помощью DKOM, для эффективности ему придется скрыть их двумя способами, а не одним. Кроме того, таблицы дескрипторов USER могут служить основным способом поиска объектов, которые невозможно обнаружить иначе, например перехватов событий и данных буфера обмена.

Перед вами стоят следующие цели:

• Программируемый API: API таблицы дескрипторов USER внутри Volatility можно использовать для создания плагинов, анализирующих определенные типы объектов USER. Именно так в настоящее время работают плагины eventhooks и clipboard.

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

Кратко рассмотрим вывод плагина gahti в 64-разрядной системе Windows 7. Этот плагин находит и анализирует win32k!_gahti (gahti означает global array of handle table information, глобальный массив сведений таблицы дескрипторов), чтобы показать, какие типы объектов можно ожидать в целевой операционной системе.

Первая запись в gahti всегда относится к TYPE_FREE, и все ее члены равны 0. Когда дескриптор перестает использоваться, он не удаляется из таблицы дескрипторов немедленно. Вместо этого его тип просто устанавливается в TYPE_FREE, что дает возможность потенциально восстановить сведения о ранее использованных дескрипторах.

Объекты TYPE_WINDOW принадлежат потокам; они выделяются из кучи рабочего стола (либо, если это не удается, из пула сеанса), а отдельные выделения помечаются байтами Usdw.

Объекты TYPE_TIMER принадлежат процессам. Объекты TYPE_CLIPDATA не принадлежат ни потоку, ни процессу, что логично, поскольку данные, скопированные в буфер обмена, свободно доступны любому процессу сеанса, вызывающему GetClipboardData.

Собранной к этому моменту информации достаточно, чтобы написать код для Volatility, действительно способный найти эту иголку в стоге сена. Процедура такова:

1. Определить базовый адрес win32k.sys, отображенного в пространство сеанса.

2. Найти раздел данных PE. Если заголовок PE поврежден или выгружен из памяти (мы наблюдали такое в очень загруженных системах с большим объемом памяти), перейти к поиску полным перебором во всем диапазоне win32k.sys размером 3-5 МБ, а не только в разделе данных.

3. Перебирать данные с шагом по четырехбайтовой границе, создавая объект tagSHAREDINFO по каждому адресу, после чего вызывать метод объекта is_valid для выполнения необходимых проверок корректности.

Чтобы увидеть код Python, соответствующий описанным шагам, откройте файл volatility/plugins/gui/win32k_core.py. Теперь вы должны без проблем находить структуру tagSHAREDINFO во всех версиях Windows.

Запись таблицы дескрипторов в 64-разрядной Windows 7 выглядит так:

Все объекты USER начинаются с одного из общих заголовков, на которые указывает член _HANDLEENTRY.phead. Поле bType сообщает тип объекта, на который ссылается дескриптор, а по ранее выгруженным сведениям из win32k!_gahti известно, какие объекты принадлежат потокам, а какие - процессам. Объекты, принадлежащие потоку, начинаются с _THRDESKHEAD, а принадлежащие процессу - с _PROCDESKHEAD. Такие объекты, как TYPE_CLIPBOARD, начинаются с универсального _HEAD. Ниже приведены три варианта:

Если объект в таблице дескрипторов принадлежит потоку, конкретный владеющий поток можно определить по _THRDESKHEAD.pti.pEThread, указывающему на исполнительную структуру _ETHREAD. Если же объект принадлежит процессу, поле _HANDLEENTRY.pOwner является указателем на владеющую структуру tagPROCESSINFO. Из нее tagPROCESSINFO.Process идентифицирует исполнительную структуру _EPROCESS.

Таким образом, независимо от ситуации объекты USER всегда можно проследить до владеющего ими потока или процесса.

Плагин userhandles находит структуру общих сведений каждого сеанса, обходит таблицу дескрипторов и выводит содержимое:

У этого плагина есть три дополнительных аргумента командной строки:

Чтобы показать только объекты USER, принадлежащие определенному процессу, используйте параметр --pid=PID. Для фильтрации по типу объекта используйте конструкцию вроде --type=TYPE_HOOK. Наконец, чтобы включить сведения о дескрипторах, помеченных как освобожденные, используйте --free. Освобожденные объекты могут представлять интерес при поиске свидетельств событий недавнего прошлого.

Хотя вывод этого плагина не слишком подробен, он дает представление о типах объектов, которые использует конкретный поток или процесс. Кроме того, его можно применять как API для других плагинов, например eventhooks и clipboard, которые рассматриваются далее.

Приложения могут использовать перехваты событий, чтобы получать уведомления о возникновении определенных событий, связанных с пользовательским интерфейсом. Например, Проводник Windows создает события при воспроизведении звука (EVENT_SYSTEM_SOUND), при начале прокрутки (EVENT_SYSTEM_SCROLLSTART) или при выборе элемента строки меню, например меню Пуск (EVENT_SYSTEM_MENUSTART). Если клиентское приложение хочет показывать маленький значок динамика в системном трее при воспроизведении звука, оно может синхронизировать поведение, установив перехват событий, который прослушивает EVENT_SYSTEM_SOUND.

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

Перед вами стоят следующие цели:

• Определение области действия перехвата событий: можно исследовать ОЗУ в поисках артефактов, созданных при установке перехвата событий. Они сообщат, какие процессы и потоки затронуты, а также какие именно события отслеживаются.

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

Определение содержимого буфера обмена компьютера может стать ценным источником сведений. Например, в одном сценарии мы проследили действия пользователя протокола удаленного рабочего стола (RDP), выгрузив историю его команд и увидев, как он запустил исходящую FTP-транзакцию с машины жертвы, компьютера. Мы видели адрес FTP-сервера и имя пользователя для входа, но не пароль. В данном случае злоумышленник скопировал пароль в буфер обмена и вставил его через канал RDP. Используя плагины истории команд и извлечения буфера обмена, мы восстановили из ОЗУ полный набор учетных данных.

Перед вами стоят следующие цели:

• Восстановление паролей: можно извлекать содержимое данных буфера обмена из ОЗУ, где в некоторых случаях могут находиться конфиденциальные сведения, например пароли, имена пользователей и так далее.

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

На конференции Digital Forensics Research Conference (DFRWS) 2011 года Околица и Петерсон (dfrws.org) первыми представили метод извлечения содержимого буфера обмена из ОЗУ с помощью инструмента Compiled Memory Analysis Tool (CMAT). Они обсудили методы поиска данных из пользовательского режима и режима ядра с использованием PDB-файлов с сервера символов Microsoft для разрешения соответственно user32!gphn и win32k!gSharedInfo.

Плагин Volatility работает одновременно сходным и довольно отличным образом. Ниже кратко описаны шаги:

1. Перечислить все уникальные структуры _MM_SESSION_SPACE.

2. Найти tagSHAREDINFO для каждого сеанса и обойти таблицу дескрипторов USER, собирая все объекты TYPE_CLIPDATA.

3. Просканировать ОЗУ в поисках объектов оконных станций и перечислить структуры tagCLIP из tagWINDOWSTATION.pClipBase.

4. Сопоставить значения дескрипторов tagCLIP.hData с соответствующими tagCLIPDATA.

5. В завершение перебрать все оставшиеся объекты tagCLIPDATA, найденные через таблицу дескрипторов USER, но еще не связанные с tagCLIP. Это позволяет сообщать данные буфера обмена, даже если объект оконной станции не найден.

Один из общедоступных образов памяти, о котором известно, что во время получения в буфере обмена находились данные, - dfrws2008-rodeo-memory.img. В следующем коде показан вывод плагина для этого образа:

Как видите, пользователь в сеансе 0\WinSta0 поместил в буфер обмена строку Unicode pp -B -p -o out.pl file. Судя по всему, это часть команды, запускающей сценарий Perl.

Формат CF_LOCALE не показан, поскольку он двоичный, но шестнадцатеричный дамп можно просмотреть, передав плагину -v/--verbose. Для CF_TEXT и CF_OEMTEXT данные также не показаны, поскольку значение дескриптора равно 1 (DUMMY_TEXT_HANDLE).

В следующем примере были открыты Microsoft Word и Microsoft Paint. В Paint создали небольшой рисунок, скопировали его в буфер обмена, а затем вставили в Word. Можно увидеть различные частные форматы Object Linking and Embedding (OLE), созданные Word (дополнительные сведения о частных форматах см. в ранее упомянутой статье Околицы и Петерсона). Кроме того, появились новые форматы CF_METAFILEPICT, CF_ENHMETAFILE, CF_BITMAP и CF_DIBV5 для поддержки двоичных изображений в буфере обмена. Данные не показаны, поскольку они двоичные, однако после небольшой доработки изображения можно было бы извлечь из памяти и сохранить для просмотра в аналитической системе.

В следующем примере пользователь выбрал файл на рабочем столе и нажал Ctrl+C, чтобы скопировать его в другой каталог. Как можно предположить, в данном случае в буфер обмена копируется не все содержимое файла. Вместо этого создается объект формата CF_HDROP с полным путем к копируемому файлу:

Помните, что плагин clipboard восстанавливает данные буфера обмена из всех сеансов и всех оконных станций. Это означает, что если в систему вошло несколько пользователей (один через консоль, другой по RDP и так далее), можно извлечь данные буфера обмена каждого из них.

В NTFS все хранится в виде файла. В том числе специальные файлы метаданных, используемые для организации и отслеживания других файлов. Например, MFT - это специальный файл, расположенный в корне файловой системы (\$Mft) и хранящий критически важные сведения обо всех остальных файлах раздела. Как вы сейчас увидите, поскольку Windows читает MFT, в любой момент в памяти можно найти весь этот файл или его часть. Поэтому, обнаружив и вырезав содержимое одного этого файла, можно быстро перечислить большую часть метаданных файловой системы.

MFT содержит по одной записи для каждого файла и каталога файловой системы. Каждая запись, максимальный размер которой составляет 1024 байта, содержит такие сведения, как имя, тип (скрытый, обычный файл, каталог) и расположение на диске, где можно найти ее данные. Атрибуты каждой записи также включают временные метки, указывающие, когда связанный файл был создан, изменен и открыт. Большинство представляющих интерес атрибутов являются резидентными, то есть содержатся внутри 1024-байтовой записи MFT. Однако из-за ограниченного размера записи некоторые атрибуты, например $DATA (используемый для хранения содержимого файла), часто являются нерезидентными и поэтому располагаются за пределами записи MFT.

Перед вами стоят следующие цели:

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

• Исследование съемных носителей: в памяти можно находить записи MFT, описывающие файлы, к которым обращались на съемных носителях, включая тома TrueCrypt.

• Восстановление альтернативных потоков данных: восстанавливать данные, которые вредоносные программы скрывают в ADS, например конфигурационные и исполняемые файлы.

• Восстановление сценариев злоумышленника: узнать, как использовать MFT для восстановления сценариев злоумышленника из памяти. Например, пакетные сценарии автоматизации повторяющихся задач часто достаточно малы, чтобы помещаться внутри записи MFT, поэтому их легко извлечь из памяти.

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

• Доказательство выполнения кода: анализируя файлы Prefetch, можно также определить, выполнялись ли определенные программы в системе и когда.

• Отслеживание действий пользователя: можно выяснить, обращались ли пользователи к определенным файлам (по ярлыкам LNK) и пытались ли они замести следы, перемещая файлы в Корзину.

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

• атрибут $FILE_NAME ($FN);

• атрибут $STANDARD_INFORMATION ($SI);

• атрибут $DATA.

Атрибут $DATA содержит содержимое файла для резидентных файлов. Запись MFT также может иметь несколько атрибутов $DATA, как в случае ADS, которые описываются далее в этой главе.

На рисунке 16-1 показан упрощенный пример записи MFT. Хотя обычно запись содержит и другие типы атрибутов, на этой схеме показаны только атрибуты, наиболее важные для обсуждений в данной главе. Следует отметить, что запись MFT может фактически использовать не все отведенное пространство, оставляя в конце неиспользуемое slack-пространство, как показано на рисунке.

Если размер данных файла не превышает 700 байт, все его содержимое будет резидентным в атрибуте $DATA записи MFT, что позволяет восстановить его с помощью этого плагина. И наоборот, плагин mftparser нельзя использовать для восстановления содержимого нерезидентных файлов; однако файл, возможно, удастся извлечь с помощью плагина dumpfiles, как рассматривается далее в этой главе.

Рисунок 16-1. Пример записи MFT

У плагина mftparser есть два режима вывода: стандартный режим verbose и режим body, который выводит данные в формате bodyfile для совместимости с утилитой mactime набора Sleuthkit (см. wiki.sleuthkit.org). Вывод подробного режима включает путь записи MFT, тип файла, временные метки, номер записи и резидентные данные (если они есть).

В следующем примере показана запись MFT для файла журнала, созданного клавиатурным шпионом. В выводе можно увидеть физическое смещение записи MFT (0x2a41600), номер записи 22052 и то, что она относится к файлу (а не каталогу). Кроме того, видны временные метки из атрибутов $SI и $FN, путь файла на диске и его резидентный $DATA:

Можно также извлечь $DATA как необработанный файл, что полезно при работе с двоичным содержимым. Плагин mftparser принимает параметр -D/--dump-dir, который заставляет его выгружать все резидентные файлы на диск. Имена выгруженных файлов формируются по следующему правилу:

Поскольку атрибутов $DATA может быть несколько, соглашение об именовании файлов включает счетчик, начинающийся с нуля и увеличивающийся для каждого раздела $DATA. Следующая команда показывает использование mftparser для извлечения всех резидентных в MFT файлов. Видно, что был также извлечен файл с двумя потоками данных (в источнике он выделен полужирным):

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

Для расследования мы выполнили следующую команду, которая создает вывод mftparser в формате body и сохраняет его в файл mft.body.

Исследуя вывод mftparser, мы нашли доказательство того, что пользователь обращался к файлу Merger Update.docx. В частности, мы нашли несколько файлов LNK для файла с именем Merger Update, а также сам файл Merger Update.docx. Это доказывает, что файл не только был в системе, но и что пользователь взаимодействовал с ним, дважды щелкнув по нему, вследствие чего был создан файл LNK.

Поскольку в выводе mftparser на каждый файл приходится три строки (по одной для каждого атрибута с временными метками), следующие команды grep сосредоточены только на записи $FN, содержащей длинное имя Unicode, а не короткие имена DOS.

Чтобы установить время доступа к документу, можно также использовать утилиту mactime набора Sleuthkit. Ниже приведен пример:

Джек Крук создал похожее на APT криминалистическое задание (docs.google.com), иллюстрирующее типы ситуаций, с которыми мы сталкивались в некоторых делах. Плагин mftparser весьма полезен, поскольку показывает, какие файлы разместил злоумышленник и когда они выполнялись.

Когда программа выполняется на машине, создается (или обновляется) файл Prefetch. Файлы Prefetch предназначены для ускорения запуска приложений. Поэтому хорошая отправная точка - поиск интересных файлов Prefetch, доказывающих, какие исполняемые файлы запускались в системе. В следующем выводе mftparser выполняется для дампа памяти, после чего вывод фильтруется несколькими командами grep. Каждая команда рассматривается в следующем списке (параметр -i делает фильтры нечувствительными к регистру):

• grep -i ".pf": вернуть файлы с расширением .pf (Prefetch).

• grep -i exe: среди возвращенных выше файлов выбрать те, путь которых содержит exe.

• cut -d\| -f2: разделить строку по символам вертикальной черты (|) и вывести второе поле.

Затем необходимо просмотреть получившийся вывод и проверить, нет ли чего-либо подозрительного:

Как видите, одна строка вывода, выделенная в источнике полужирным, выглядит странно. Исходное имя SWING-MECHANICS.DOC[1].EXE указывает, что файл должен был выглядеть как документ Word, но на самом деле является исполняемым. Поскольку Windows по умолчанию скрывает расширения известных файлов, многие пользователи могут ошибочно принять файл за документ Word, так как видно только расширение .DOC.

Поиск других файлов Prefetch позволяет найти свидетельства выполнения исполняемых файлов, которые обычно не встречаются в чистых системах Windows (в источнике они выделены полужирным):

После этого сведения можно использовать для поиска исходных полных путей к этим файлам. Ниже приведен пример:

Теперь у вас есть путь, и известно, что папка systems отсутствует в стандартных системах Windows, что делает файл еще подозрительнее. Далее можно посмотреть, что еще находится в этой папке. В следующем выводе видна также папка с именем 1, которая могла использоваться для подготовки конфиденциальных PDF-файлов:

Отсортировав вывод mftparser с помощью утилиты mactime, можно определить, что следующие файлы Prefetch были созданы после SWING-MECHANICS.DOC[1].EXE-013CEA10.pf. Это свидетельство указывает, что злоумышленник проводил разведку сети после получения доступа к системе.

Кроме того, в отсортированном выводе видны свидетельства того, что злоумышленник мог упаковать PDF-файлы в архив RAR. В частности, сразу после выполнения r.exe в каталоге Application Data пользователя была создана папка WinRAR. Хорошо известно, что WinRAR создает эту папку при первом запуске в системе. Вскоре после появления этих артефактов запускается приложение ftp.exe:

Чтобы проверить, является ли программа r.exe WinRAR, можно извлечь ее плагином dumpfiles (рассматриваемым далее в этой главе), а затем проанализировать утилитой strings. Следующий вывод показывает, как это сделать:

Плагин dumpfiles извлекает один файл:

Если вы используете утилиту strings в Linux, необходимо выполнить два прохода: один для ASCII и один для Unicode:

После этого можно исследовать вывод strings. Прокрутив его вниз, вы найдете справочное сообщение. Это сообщение принадлежит WinRAR (см. discussions.apple.com) и помогает доказать, что злоумышленники использовали WinRAR для создания архива файлов:

Поскольку сценарии злоумышленников часто достаточно малы, чтобы быть резидентными в MFT, имеет смысл запустить плагин mftparser в подробном режиме для извлечения всех возможных сценариев. В данном случае подробный вывод mftparser извлекает один из сценариев злоумышленника (f.txt). Этот сценарий открывает соединение с 66.32.119.38, используя имя пользователя jack и пароль 2awes0me, переходит в каталог systems, куда были помещены все файлы, а затем загружает все текстовые файлы из этого каталога в каталог /home/jack удаленной системы:

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