Введение

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

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

Существует множество инструментов для анализа дампов памяти, наиболее популярные из которых – фреймворки volatility и rekall, оба с открытым исходным кодом. Однако самих по себе инструментов может оказаться недостаточно: исследователю полезно иметь алгоритм, который помогал бы действовать эффективно, систематично и не упускать важные детали. Один такой алгоритм под названием SANS Six-Step Investigative Methodology был предложен институтом SANS.

SANS Six-Step Investigative Methodology

Описание методологии SANS Six-Step можно найти на одном из постеров SANS. Алгоритм, как следует из названия, состоит из шести шагов:

Идентификация вредоносных процессов.
Анализ DLL и хэндлов процесса.
Изучение сетевых артефактов.
Поиск свидетельств инъекции кода.
Проверка признаков наличия руткита.
Выгрузка подозрительных процессов и драйверов.

Для пошаговой демонстрации методологии я воспользовался известным образом Jackcr’s Challenge в качестве первого семпла и дампом с Linux-машины, подготовленным моим коллегой, в качестве второго. Среди инструментов, которыми я пользовался, – фреймворк volatility, последнюю версию которого можно найти на GitHub, Wireshark и стандартные Linux-утилиты, такие как strings и grep.

Jackcr’s Challenge

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

Применение методологии к дампу из челленджа

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

1. Идентификация вредоносных процессов

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

Затем я воспользовался плагином volatility pslist. В списке запущенных процессов, который он вывел на консоль, я заметил несколько подозрительных.

Здесь выглядят подозрительными из-за их времени запуска процессы 364, 1796 и 244. Также я взял на заметку процессы 1024 и 284, которые являются родительскими для процессов 364 и 1796 соответственно.

2. Анализ DLL процесса

В состав volatility входит плагин dlllist, предназначенный для получения списка используемых процессом DLL. Запустив dlllist для подозрительных процессов и проверив ряд DLL, я обнаружил 6to4ex.dll, используемый процессом svchost.exe с PID 1024, который был помечен большинством движков VirusTotal как вредоносный. Запустив strings на этой DLL, я заметил вхождения строки “gh0st” – это название известного трояна.

Рисунок 3. Название известного трояна Gh0st фигурирует в DLL

3. Анализ сетевых артефактов

Третий шаг состоял из изучения дампа трафика в Wireshark и запуска плагина volatility connscan, который показывает артефакты подключений, в том числе недавно закрытых. Это дало мне адрес C2, запуск grep по которому показал также, каким образом было доставлено вредоносное ПО: злоумышленники отправили нескольким пользователям фишинговые письма с требованием установить новый антивирус и ссылкой на дроппер под названием Symantec-1.43-1.exe.

Рисунок 4. Вредоносное ПО было доставлено с помощью фишинговых писем

4. Поиск свидетельств инъекции кода

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

Рисунок 5. Malfind не находит свидетельств инъекции кода для PID 1024

5. Проверка признаков наличия руткита

Руткиты часто перехватывают вызовы System Service Descriptor Table (SSDT), поэтому проверка на владельцев функций SSDT – один из способов обнаружить руткит в системе. В составе volatility есть плагин, перечисляющий функции SSDT и их владельцев, который так и называется – ssdt. Запуск ssdt, однако, не показал ничего. Надо полагать, это связано с тем, что Gh0st, обнаруженный на исследуемой системе, согласно исследованию InfoSec способен зачищать существующие перехваты SSDT.

6. Выгрузка подозрительных процессов и драйверов

Плагин volatility procdump позволяет выгружать исполняемый файл по переданному на вход номеру процесса. Именно так я и поступил с процессами 1024 и 1796.

Применение методологии к дампу с Linux-машины

Теперь, когда мы закончили с Windows-дампом, давайте попробуем адаптировать тот же алгоритм к имитирующему несложный инцидент Linux-образу.

1. Идентификация вредоносных процессов

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

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

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

2. Анализ DLL процесса

Несмотря на то, что термин DLL применим только к Windows, этот шаг легко остается актуальным для Linux-дампа, так как исполняемые файлы под Linux также используют динамические библиотеки, называемые обычно shared libraries. Единственное отличие состоит в том, что если для Windows-дампа я использовал плагин dlllist, то для Linux-дампа я использовал плагин linux_library_list, аналогичным образом выводящий список библиотек для процесса. В случае процесса 1353 список библиотек, однако, оказался пустым.

Рисунок 7. Volatility не показывает список библиотек подозрительного процесса

3. Анализ сетевых артефактов

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

Рисунок 8. Вывод linux_netstat (фрагмент)

Более того, запустив strings на дампе и отфильтровав результат по потенциальному адресу C2, я заметил фрагмент bash-скрипта.

Была там и строчка, дающая возможность понять, как файл wallet.elf попал в систему.

Рисунок 10. Подозрительный исполняемый файл был загружен скриптом

4. Поиск свидетельств инъекции кода

Как и в случае Windows, в составе volatility есть плагин для поиска возможной инъекции кода. Его Linux-версия называется linux_malfind. Запустив его, я получил несколько положительных сработок для процесса 1353, однако я уже знал, что запущенный в этом процессе исполняемый файл был загружен извне подозрительным скриптом, так что это было не очень полезно.

Рисунок 11. Malfind нашел признаки инъекции кода в процессе 1353

5. Проверка признаков наличия руткита

В составе volatility есть несколько инструментов для обнаружения руткитов в случае Linux:

linux_check_fop проверяет на наличие модификаций структуры file_operation;
linux_check_idt проверяет, были ли изменены IDT;
linux_check_modules сравнивает список модулей с данными sysfs;
linux_hidden_modules пытается обнаружить скрытые модули ядра;
И другие.

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

6. Выгрузка подозрительных процессов и драйверов

Работая над Windows-дампом, я использовал плагин volatility procdump, чтобы выгрузить исполняемый файл подозрительного процесса. В volatility есть аналогичный плагин и для Linux-дампов – он называется linux_procdump. С помощью этого плагина я выгрузил исполняемый файл процесса 1353 для дальнейшего анализа.

Заключение

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

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

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

Как обнаружить вредонос: методология SANS