[Информационная безопасность] Как обнаружить вредонос: методология SANS
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
ВведениеКогда происходит взлом какой-то системы, зачастую возникает необходимость выяснить, как система была взломана, какие компоненты были скомпрометированы, какая информация была похищена, и кто произвел атаку. Ветвь криминалистики, отвечающая на вопросы такого рода, называется компьютерной криминалистикой или форензикой.Одна из важнейших техник форензики – анализ дампов памяти, сделанных на потенциально скомпрометированных системах. Дамп памяти – это файл, содержащий данные из оперативной памяти компьютера, в том числе данные запущенных процессов. Именно поэтому их анализ так важен: если система была скомпрометирована, и на ней запущено вредоносное программное обеспечение, эксперт по компьютерной криминалистике сможет обнаружить это, изучая дамп.Существует множество инструментов для анализа дампов памяти, наиболее популярные из которых – фреймворки 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. Содержимое архива по ссылкеПрименение методологии к дампу из челленджаТеперь я продемонстрирую применение каждого шага методологии к дампу из челленджа, снятому на машине ENG-USTXHOU-148.1. Идентификация вредоносных процессовСогласно методологии, первый шаг – идентификация вредоносных процессов. Однако, начиная работу с volatility, первым делом нужно выяснить, какой профиль следует использовать с рассматриваемым дампом, иначе volatility не сможет прочитать дамп. Для этого пригодится команда volatility imageinfo: в ее выводе можно найти основную информацию о переданном на вход дампе, в том числе подходящий профиль – в моем случае таковым оказался WinXPSP2x86.Затем я воспользовался плагином volatility pslist. В списке запущенных процессов, который он вывел на консоль, я заметил несколько подозрительных.
Рисунок 2. Список процессовЗдесь выглядят подозрительными из-за их времени запуска процессы 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 фигурирует в DLL3. Анализ сетевых артефактовТретий шаг состоял из изучения дампа трафика в Wireshark и запуска плагина volatility connscan, который показывает артефакты подключений, в том числе недавно закрытых. Это дало мне адрес C2, запуск grep по которому показал также, каким образом было доставлено вредоносное ПО: злоумышленники отправили нескольким пользователям фишинговые письма с требованием установить новый антивирус и ссылкой на дроппер под названием Symantec-1.43-1.exe.
Рисунок 4. Вредоносное ПО было доставлено с помощью фишинговых писем4. Поиск свидетельств инъекции кодаПоиск свидетельств возможного внедрения кода можно осуществить с помощью malfind – ещё одного плагина volatility, разработанного специально для этих целей. В моем случае ничего найдено не было. Это связано с тем, что malfind не способен обнаруживать инъекции DLL (разработчики подчеркивают это в документации).
Рисунок 5. Malfind не находит свидетельств инъекции кода для PID 10245. Проверка признаков наличия руткитаРуткиты часто перехватывают вызовы 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. Список процессов (фрагмент)Обнаружить подозрительный процесс было нетрудно: 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-скрипта.
Рисунок 9. Скрипт в выводе stringsБыла там и строчка, дающая возможность понять, как файл wallet.elf попал в систему.
Рисунок 10. Подозрительный исполняемый файл был загружен скриптом4. Поиск свидетельств инъекции кодаКак и в случае Windows, в составе volatility есть плагин для поиска возможной инъекции кода. Его Linux-версия называется linux_malfind. Запустив его, я получил несколько положительных сработок для процесса 1353, однако я уже знал, что запущенный в этом процессе исполняемый файл был загружен извне подозрительным скриптом, так что это было не очень полезно.
Рисунок 11. Malfind нашел признаки инъекции кода в процессе 13535. Проверка признаков наличия руткитаВ составе 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, вам может показаться, что она контринтуитивна – например, вы захотите сначала изучить сетевые подключения, а уже потом посмотреть на список запущенных процессов. Однако следует понимать, что это обратная сторона систематизации. Если вы не опытный специалист по компьютерной криминалистике с развитой профессиональной интуицией, скорее всего, методология поможет вам выполнить работу быстрее и получить более точные и структурированные результаты.Разумеется, я не утверждаю, что это единственная методология, достойная внимания, но она может стать для вас хорошей отправной точкой.
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, C++, Системное программирование, Конференции] Онлайн-конференция KasperskyOS Night: доклады о нестандартных задачах
- [Информационная безопасность, Разработка для интернета вещей] Приглашаем на летнюю конференцию KasperskyOS Night
- [Информационная безопасность, Браузеры] Пора запретить рекламу, основанную на слежке (перевод)
- [Информационная безопасность, Криптография, Серверное администрирование] Инфраструктурой российского DoubleVPN завладели зарубежные спецслужбы
- [Информационная безопасность, Разработка мобильных приложений, Разработка под Android] Google до конца года потребует от разработчиков приложений включить двухфакторную авторизацию
- [Информационная безопасность, Хранение данных, Софт, Накопители] Как быстро и надёжно удалить файлы, зачистить HDD/SSD перед обыском
- [Информационная безопасность, Хранение данных, Хранилища данных, Законодательство в IT, Софт] Российские IТ-компании используют обвинения в иностранном происхождении для конкуренции
- [Информационная безопасность, Мессенджеры, Законодательство в IT, Социальные сети и сообщества] РКН потребовал от суда признать незаконной деятельность Telegram-бота «Глаз Бога»
- [Информационная безопасность, DNS, Разработка под Windows, Софт] В превью Windows 11 появился DNS-over-HTTPS
- [Информационная безопасность] В сети продают базу данных LinkedIn на 700 млн записей
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_sans, #_damp (дамп), #_windowsdamp (Windows-дамп), #_linuxdamp (Linux-дамп), #_rutkit (руткит), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 05:59
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
ВведениеКогда происходит взлом какой-то системы, зачастую возникает необходимость выяснить, как система была взломана, какие компоненты были скомпрометированы, какая информация была похищена, и кто произвел атаку. Ветвь криминалистики, отвечающая на вопросы такого рода, называется компьютерной криминалистикой или форензикой.Одна из важнейших техник форензики – анализ дампов памяти, сделанных на потенциально скомпрометированных системах. Дамп памяти – это файл, содержащий данные из оперативной памяти компьютера, в том числе данные запущенных процессов. Именно поэтому их анализ так важен: если система была скомпрометирована, и на ней запущено вредоносное программное обеспечение, эксперт по компьютерной криминалистике сможет обнаружить это, изучая дамп.Существует множество инструментов для анализа дампов памяти, наиболее популярные из которых – фреймворки volatilityи rekall, оба с открытым исходным кодом. Однако самих по себе инструментов может оказаться недостаточно: исследователю полезно иметь алгоритм, который помогал бы действовать эффективно, систематично и не упускать важные детали. Один такой алгоритм под названием SANS Six-Step Investigative Methodology был предложен институтом SANS.SANS Six-Step Investigative MethodologyОписание методологии SANS Six-Step можно найти на одном из постеров SANS. Алгоритм, как следует из названия, состоит из шести шагов:
 Рисунок 1. Содержимое архива по ссылкеПрименение методологии к дампу из челленджаТеперь я продемонстрирую применение каждого шага методологии к дампу из челленджа, снятому на машине ENG-USTXHOU-148.1. Идентификация вредоносных процессовСогласно методологии, первый шаг – идентификация вредоносных процессов. Однако, начиная работу с volatility, первым делом нужно выяснить, какой профиль следует использовать с рассматриваемым дампом, иначе volatility не сможет прочитать дамп. Для этого пригодится команда volatility imageinfo: в ее выводе можно найти основную информацию о переданном на вход дампе, в том числе подходящий профиль – в моем случае таковым оказался WinXPSP2x86.Затем я воспользовался плагином volatility pslist. В списке запущенных процессов, который он вывел на консоль, я заметил несколько подозрительных.  Рисунок 2. Список процессовЗдесь выглядят подозрительными из-за их времени запуска процессы 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 фигурирует в DLL3. Анализ сетевых артефактовТретий шаг состоял из изучения дампа трафика в Wireshark и запуска плагина volatility connscan, который показывает артефакты подключений, в том числе недавно закрытых. Это дало мне адрес C2, запуск grep по которому показал также, каким образом было доставлено вредоносное ПО: злоумышленники отправили нескольким пользователям фишинговые письма с требованием установить новый антивирус и ссылкой на дроппер под названием Symantec-1.43-1.exe.  Рисунок 4. Вредоносное ПО было доставлено с помощью фишинговых писем4. Поиск свидетельств инъекции кодаПоиск свидетельств возможного внедрения кода можно осуществить с помощью malfind – ещё одного плагина volatility, разработанного специально для этих целей. В моем случае ничего найдено не было. Это связано с тем, что malfind не способен обнаруживать инъекции DLL (разработчики подчеркивают это в документации).  Рисунок 5. Malfind не находит свидетельств инъекции кода для PID 10245. Проверка признаков наличия руткитаРуткиты часто перехватывают вызовы 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. Список процессов (фрагмент)Обнаружить подозрительный процесс было нетрудно: 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-скрипта.  Рисунок 9. Скрипт в выводе stringsБыла там и строчка, дающая возможность понять, как файл wallet.elf попал в систему.  Рисунок 10. Подозрительный исполняемый файл был загружен скриптом4. Поиск свидетельств инъекции кодаКак и в случае Windows, в составе volatility есть плагин для поиска возможной инъекции кода. Его Linux-версия называется linux_malfind. Запустив его, я получил несколько положительных сработок для процесса 1353, однако я уже знал, что запущенный в этом процессе исполняемый файл был загружен извне подозрительным скриптом, так что это было не очень полезно.  Рисунок 11. Malfind нашел признаки инъекции кода в процессе 13535. Проверка признаков наличия руткитаВ составе volatility есть несколько инструментов для обнаружения руткитов в случае Linux:
=========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 05:59
Часовой пояс: UTC + 5