Введение
Когда происходит взлом какой-то системы, зачастую возникает необходимость выяснить, как система была взломана, какие компоненты были скомпрометированы, какая информация была похищена, и кто произвел атаку. Ветвь криминалистики, отвечающая на вопросы такого рода, называется компьютерной криминалистикой или форензикой.
Одна из важнейших техник форензики – анализ дампов памяти, сделанных на потенциально скомпрометированных системах. Дамп памяти – это файл, содержащий данные из оперативной памяти компьютера, в том числе данные запущенных процессов. Именно поэтому их анализ так важен: если система была скомпрометирована, и на ней запущено вредоносное программное обеспечение, эксперт по компьютерной криминалистике сможет обнаружить это, изучая дамп.
Существует множество инструментов для анализа дампов памяти, наиболее популярные из которых – фреймворки 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 специалист по безопасности Джек Крук поделился ссылкой на образ челленджа в своем Твиттере. Сейчас образ доступен по ссылке. Челлендж состоит из дампов памяти с нескольких машин, дампа трафика и текстового файла с вопросами, на которые предлагается ответить. После публикации челлендж стал весьма популярным, в интернете можно найти ряд посвященных ему статей-прохождений, поэтому образ вполне подходит для того, чтобы попрактиковаться с новыми инструментами и методами работы.
![Рисунок 1. Содержимое архива по ссылке Рисунок 1. Содержимое архива по ссылке](https://habrastorage.org/getpro/habr/upload_files/c33/482/3fd/c334823fd24345efa38ddc8ead2e2c43.png)
Применение методологии к дампу из челленджа
Теперь я продемонстрирую применение каждого шага методологии к дампу из челленджа, снятому на машине ENG-USTXHOU-148.
1. Идентификация вредоносных процессов
Согласно методологии, первый шаг – идентификация вредоносных процессов. Однако, начиная работу с volatility, первым делом нужно выяснить, какой профиль следует использовать с рассматриваемым дампом, иначе volatility не сможет прочитать дамп. Для этого пригодится команда volatility imageinfo: в ее выводе можно найти основную информацию о переданном на вход дампе, в том числе подходящий профиль – в моем случае таковым оказался WinXPSP2x86.
Затем я воспользовался плагином volatility pslist. В списке запущенных процессов, который он вывел на консоль, я заметил несколько подозрительных.
![Рисунок 2. Список процессов Рисунок 2. Список процессов](https://habrastorage.org/getpro/habr/upload_files/736/b81/295/736b812953814548d42469655945ed04.png)
Здесь выглядят подозрительными из-за их времени запуска процессы 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. Название известного трояна Gh0st фигурирует в DLL](https://habrastorage.org/getpro/habr/upload_files/1a0/52f/386/1a052f386b2b9d012a177037382edaa1.png)
3. Анализ сетевых артефактов
Третий шаг состоял из изучения дампа трафика в Wireshark и запуска плагина volatility connscan, который показывает артефакты подключений, в том числе недавно закрытых. Это дало мне адрес C2, запуск grep по которому показал также, каким образом было доставлено вредоносное ПО: злоумышленники отправили нескольким пользователям фишинговые письма с требованием установить новый антивирус и ссылкой на дроппер под названием Symantec-1.43-1.exe.
![Рисунок 4. Вредоносное ПО было доставлено с помощью фишинговых писем Рисунок 4. Вредоносное ПО было доставлено с помощью фишинговых писем](https://habrastorage.org/getpro/habr/upload_files/e3c/4cf/cfc/e3c4cfcfc00cdb91409878c9daacb6e1.png)
4. Поиск свидетельств инъекции кода
Поиск свидетельств возможного внедрения кода можно осуществить с помощью malfind – ещё одного плагина volatility, разработанного специально для этих целей. В моем случае ничего найдено не было. Это связано с тем, что malfind не способен обнаруживать инъекции DLL (разработчики подчеркивают это в документации).
![Рисунок 5. Malfind не находит свидетельств инъекции кода для PID 1024 Рисунок 5. Malfind не находит свидетельств инъекции кода для PID 1024](https://habrastorage.org/getpro/habr/upload_files/16b/8d5/c3e/16b8d5c3e41484a06f42c11db17eb6dc.png)
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, чтобы просмотреть список процессов и выделить подозрительные.
![Рисунок 6. Список процессов (фрагмент) Рисунок 6. Список процессов (фрагмент)](https://habrastorage.org/getpro/habr/upload_files/7f5/844/cc1/7f5844cc1fb328cbd6f7d8f4764c2c58.png)
Обнаружить подозрительный процесс было нетрудно: wallet.elf не только единственный процесс с расширением .elf у исполняемого файла, но еще и родитель для процесса sh, который в свою очередь является родителем vim. Не самая обычная цепочка.
2. Анализ DLL процесса
Несмотря на то, что термин DLL применим только к Windows, этот шаг легко остается актуальным для Linux-дампа, так как исполняемые файлы под Linux также используют динамические библиотеки, называемые обычно shared libraries. Единственное отличие состоит в том, что если для Windows-дампа я использовал плагин dlllist, то для Linux-дампа я использовал плагин linux_library_list, аналогичным образом выводящий список библиотек для процесса. В случае процесса 1353 список библиотек, однако, оказался пустым.
![Рисунок 7. Volatility не показывает список библиотек подозрительного процесса Рисунок 7. Volatility не показывает список библиотек подозрительного процесса](https://habrastorage.org/getpro/habr/upload_files/acc/7f0/0eb/acc7f00eb3489c71e967e8335f08c860.png)
3. Анализ сетевых артефактов
На этот раз у меня не было дампа трафика, поэтому на этапе анализа сетевых артефактов мне оставалось только изучить список подключений с помощью плагина volatility linux_netscan, который выводит список открытых сокетов. Его вывод снова направил внимание в сторону процесса 1353, а также дал потенциальный адрес C2.
![Рисунок 8. Вывод linux_netstat (фрагмент) Рисунок 8. Вывод linux_netstat (фрагмент)](https://habrastorage.org/getpro/habr/upload_files/a5d/678/b95/a5d678b956c7e4439f02fe0dbf7ecdd8.png)
Более того, запустив strings на дампе и отфильтровав результат по потенциальному адресу C2, я заметил фрагмент bash-скрипта.
![Рисунок 9. Скрипт в выводе strings Рисунок 9. Скрипт в выводе strings](https://habrastorage.org/getpro/habr/upload_files/ed8/afe/b08/ed8afeb08ba9a7f73d114e329ad48ea6.png)
Была там и строчка, дающая возможность понять, как файл wallet.elf попал в систему.
![Рисунок 10. Подозрительный исполняемый файл был загружен скриптом Рисунок 10. Подозрительный исполняемый файл был загружен скриптом](https://habrastorage.org/getpro/habr/upload_files/b3d/58d/ac7/b3d58dac720d87f7b3b4e547321524c5.png)
4. Поиск свидетельств инъекции кода
Как и в случае Windows, в составе volatility есть плагин для поиска возможной инъекции кода. Его Linux-версия называется linux_malfind. Запустив его, я получил несколько положительных сработок для процесса 1353, однако я уже знал, что запущенный в этом процессе исполняемый файл был загружен извне подозрительным скриптом, так что это было не очень полезно.
![Рисунок 11. Malfind нашел признаки инъекции кода в процессе 1353 Рисунок 11. Malfind нашел признаки инъекции кода в процессе 1353](https://habrastorage.org/getpro/habr/upload_files/197/546/001/1975460014828f5b69ea4e8ae949d1cc.png)
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, вам может показаться, что она контринтуитивна – например, вы захотите сначала изучить сетевые подключения, а уже потом посмотреть на список запущенных процессов. Однако следует понимать, что это обратная сторона систематизации. Если вы не опытный специалист по компьютерной криминалистике с развитой профессиональной интуицией, скорее всего, методология поможет вам выполнить работу быстрее и получить более точные и структурированные результаты.
Разумеется, я не утверждаю, что это единственная методология, достойная внимания, но она может стать для вас хорошей отправной точкой.