Введение
Когда происходит взлом какой-то системы, зачастую возникает необходимость выяснить, как система была взломана, какие компоненты были скомпрометированы, какая информация была похищена, и кто произвел атаку. Ветвь криминалистики, отвечающая на вопросы такого рода, называется компьютерной криминалистикой или форензикой.
Одна из важнейших техник форензики – анализ дампов памяти, сделанных на потенциально скомпрометированных системах. Дамп памяти – это файл, содержащий данные из оперативной памяти компьютера, в том числе данные запущенных процессов. Именно поэтому их анализ так важен: если система была скомпрометирована, и на ней запущено вредоносное программное обеспечение, эксперт по компьютерной криминалистике сможет обнаружить это, изучая дамп.
Существует множество инструментов для анализа дампов памяти, наиболее популярные из которых – фреймворки 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. Анализ сетевых артефактов
Третий шаг состоял из изучения дампа трафика в Wireshark и запуска плагина volatility connscan, который показывает артефакты подключений, в том числе недавно закрытых. Это дало мне адрес C2, запуск grep по которому показал также, каким образом было доставлено вредоносное ПО: злоумышленники отправили нескольким пользователям фишинговые письма с требованием установить новый антивирус и ссылкой на дроппер под названием Symantec-1.43-1.exe.
4. Поиск свидетельств инъекции кода
Поиск свидетельств возможного внедрения кода можно осуществить с помощью malfind – ещё одного плагина volatility, разработанного специально для этих целей. В моем случае ничего найдено не было. Это связано с тем, что malfind не способен обнаруживать инъекции DLL (разработчики подчеркивают это в документации).
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 список библиотек, однако, оказался пустым.
3. Анализ сетевых артефактов
На этот раз у меня не было дампа трафика, поэтому на этапе анализа сетевых артефактов мне оставалось только изучить список подключений с помощью плагина volatility linux_netscan, который выводит список открытых сокетов. Его вывод снова направил внимание в сторону процесса 1353, а также дал потенциальный адрес C2.
Более того, запустив strings на дампе и отфильтровав результат по потенциальному адресу C2, я заметил фрагмент bash-скрипта.
Была там и строчка, дающая возможность понять, как файл wallet.elf попал в систему.
4. Поиск свидетельств инъекции кода
Как и в случае Windows, в составе volatility есть плагин для поиска возможной инъекции кода. Его Linux-версия называется linux_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, вам может показаться, что она контринтуитивна – например, вы захотите сначала изучить сетевые подключения, а уже потом посмотреть на список запущенных процессов. Однако следует понимать, что это обратная сторона систематизации. Если вы не опытный специалист по компьютерной криминалистике с развитой профессиональной интуицией, скорее всего, методология поможет вам выполнить работу быстрее и получить более точные и структурированные результаты.
Разумеется, я не утверждаю, что это единственная методология, достойная внимания, но она может стать для вас хорошей отправной точкой.
