Вступление
Всех приветствую! Говоря простым языком, компьютерный инцидент – это последствия после проведенной компьютерной атаки. (Далее вместо термина «компьютерный инцидент» будем кратко говорить – «КИ») В настоящее время реагирование на КИ занимает одну из ключевых областей компьютерной безопасности, а специалистов, которые занимаются их расследованием красиво называют «компьютерными криминалистами» или SOC аналитиками.
На данный момент в странах СНГ и в частности России, тематика реагирования на КИ развита очень слаба. Частично это связано с тем, что количество русскоязычных материалов по данной тематике очень мало. В этом плане запад ушел далеко вперед, но мы потихоньку их догоняем.
Сегодня в сети отсутствуют простые и практичные методики реагирования на КИ никак не связанные с юридической частью. Поэтому цель данной статьи – описать простую методику реагирования на КИ, которую можно применять в небольших корпоративных сетях и привести несложный пример из реальной жизни для повышения уровня понимания этой тематики.
Дисклеймер: если эта статья будет интересна и понравится читателям, то я планирую написать цикл статей по данной тематике, где мы подробно разберем различные инциденты не только в ОС семейства Windows, но и Linux-подобных, Android и IOS системах. Будут разобраны различные утилиты, методики атакующих по сокрытию своих следов и сама логика процесса реагирования. В каждой статье будут приводиться только реальные примеры из жизни.
Методика реагирования
Сразу предупрежу, что разбора используемых утилит на каждом этапе не будет, чтобы не раздувать статью. Пример реагирования будет выбран достаточно простой, в том числе для того, чтобы для разбора хватило основных утилит, которые все и так знают.
Для успешного реагирования на КИ в данной методике необходимо реализовать 6 этапов:
1. Обнаружение
На этапе обнаружения необходимо определить является ли возникшее ИБ событие КИ или нет.
2. Изоляция
На этапе изоляции необходимо произвести изоляцию скомпрометированных компьютеров от внешней среды.
3. Сбор данных
На этапе сбора данных производится фиксация состояния всех скомпрометированных компьютеров.
4. Изучение
На этапе изучения по полученным данным скомпрометированных компьютеров производится криминалистический анализ для получения подробной информации об инциденте.
5. Ликвидация
На этапе ликвидации по полученной информации производится удаление ВПО и восстановление штатного режима информационной системы.
6. Выводы
На этапе выводов производится перенастройка и конфигурация информационной системы для предотвращения возникновения похожих КИ в будущем.
Далее обсудим эти этапы подробнее.
Этап «Обнаружение»
Этап «Обнаружение»
Инциденты могут быть обнаружены ответственными на объекте за реагирование на КИ сотрудниками, через различные автоматизированные средства обнаружения, такие как: IDS, IPS, антивирусное программное обеспечение, SIEM-системы и прочее.
Также, инциденты могут быть обнаружены ручными средствами, такими как сообщения пользователей о проблемах.
«Компьютерные криминалисты» не занимаются обнаружением инцидентов. Для этого существует отдел мониторинга, который собирает, анализирует информацию с сенсоров установленных на объектах и передает её следующим специалистам.
Этап «Изоляция»
Необходимо определить зараженные компьютеры по общим признакам, например, если известен IP или URL адрес центра управления, то поместить их в отдельный сегмент корпоративной сети и настроить правила безопасности таким образом, чтобы распространение не продолжалось дальше.
При этом запрещено физически отключать компьютер от локальной сети, т.к. ВПО может начать удаление себя и своих следов при отсутствии сетевого соединения.
Так же недопустимо отключать питание компьютера, т.к. некоторые угрозы не создают файлов на диске, а полностью размещают себя в оперативной памяти, так как там их сложнее обнаружить. Поэтому, при отключении питания будет утрачена вся информация, содержащаяся в оперативной памяти.
Конфигурации межсетевого экрана, маршрутизатора или прокси сервера в корпоративной сети должны быть изменены таким образом, чтобы остановить сетевой трафик, который является частью инцидента.
Этап «Сбор данных»
Этап «Сбор данных»
Необходимо снять образ жесткого диска и образ оперативной памяти скомпрометированных компьютеров. При этом образ оперативной памяти имеет больший приоритет, поэтому нужно начинать с него.
Снятие образов позволяет получить все компоненты ВПО. По результатам исследования этих компонентов можно определить, как следует бороться с заражением. Также анализ образов позволит определить вектор распространения угрозы, чтобы не допустить повторного заражения по аналогичному сценарию.
Этап «Изучение»
Этап «Изучение»
На данном этапе в первую очередь используя автоматические и ручные инструменты с помощью которых производится поиск ВПО и индикаторов компрометации. Необходимо проверить на подозреваемых компьютерах следующие основные ИБ события:
- Наличие неизвестного ПО в автозагрузке
- Наличие неизвестного сервиса
- Неполадки в работе антивируса
- Наличие подозрительных процессов
- Нестандартное расположение некоторых исполняемых файлов
- Нестандартное расположение некоторых DLL библиотек
- Наличие инструментов удаленного администрирования
- Наличие инструментов для извлечения паролей
- Непредвиденное повышение привилегий пользователя
Этап «Ликвидация»
Этап «Ликвидация»
На этапе ликвидации производятся активные действия по удалению угрозы из сети: удаляется ВПО, изменяются взломанные учетные записи (их можно временно заблокировать, сменить пароль или, например, переименовать), устанавливаются обновления и патчи для проэксплуатированных уязвимостей. Указанные действия выполняются для всех затронутых инцидентом сущностей — и для устройств, и для учетных записей, и для программ.
Этап «Выводы»
Этап «Выводы»
На этапе выводы анализируются причины инцидента для того, чтобы свести к минимуму вероятность повторного аналогичного инцидента в будущем. Принимаются все меры по предотвращению повторных атак. Такие как:
- Изменение настроек средств защиты информации
- Изменение архитектуры информационной системы
- Внедрение новых средств защиты информации
- Обновление уязвимого и устаревшего ПО
- Консультирование рабочего персонала
Пример реагирования на КИ
Пример реагирования на КИ
Для того, чтобы не раздувать разбор примера, архитектура сети была сильно упрощена, а также пропущены некоторые шаги методики и самого расследования. Инцидент произошел в 2015 году.
Исходные данные:
- Имеется компьютер под управлением ОС «Windows 7 x64»
- Известен факт того, что на нем произошел КИ типа «Заражение ВПО», но ip-адрес центра управления неизвестен.
- Данный компьютер находится в общей локальной сети с двумя другими компьютерами
- У компьютеров в локальной сети имеется выход в сеть Интернет
- Весь трафик проходит через внешнюю машину с установленной «IDS Snort»
Этап «Обнаружение»
Этот этап пропускаем, т.к. по условию известен факт возникновения КИ.Этап «Изоляция»
Тут возможно два варианта. Перенастроить Snort таким образом, чтобы дропать весь трафик в режиме IPS, либо полениться и на трех рабочих компьютерах настроить правила брандмауэра Windows таким образом, чтобы у всех приложений отключить входящие и исходящие соединения. Делается это в пару кликов.Этап «Сбор данных»
Для получения образа оперативной памяти и жесткого диска я как правило пользуюсь утилитой “FTK Imager”, которая установлена у меня на рабочей флешке. Опустим этот этап. В интернете полно мануалов как нажать пару кнопок в гуи для снятия дампов с помощью этой утилиты.Этап «Изучение»
Самый сложный и трудоемкий этап. Может занимать очень продолжительное время. Зависит не только от сложности ВПО, но и архитектуры сети компании, а также на сколько руководство пострадавшей компании готовы идти на контакт… Часто бывают случаи сокрытия фактов инцидента и звонить не начнут, пока не потеряют кучу денег.В первую очередь необходимо выгрузить из образа жесткого диска конфигурационные файлы, в которых хранится реестр Windows. Для этого воспользуемся набором утилит для криминалистического анализа «The Sleuth Kit».
С помощью утилиты «mmls» получим информацию о имеющихся разделах:
На скриншоте видно, что имеется два NTFS раздела. По столбцу Length видно, что размер второго раздела во много раз превышает размер первого. Это говорит о том, что система скорее всего установлена на втором разделе, а первый раздел зарезервирован операционной системой. Нас интересует базовый адрес основного раздела, который указан в столбце Start.
Далее выгрузим основные, необходимые файлы, в которых хранится реестр Windows, а именно: NTUSER.DAT, SYSTEM, SOFTWARE. Это не все файлы реестра, поэтому при необходимости остальные выгружаются аналогично. Для этого с помощью утилиты «fls» узнаем их соответствующий номер записи в главной файловой таблице MFT:
С помощью утилиты «icat» скопируем необходимые нам файлы:
Узнаем точную версию ОС скомпрометированного компьютера. Для этого рассмотрим куст реестра «Microsoft\Windows NT\CurrentVersion»:
Видим, что исследуемый компьютер работает под управлением ОС Windows 7 Ultimate с пакетом обновления SP1.
Далее поработаем с файлом «NTUSER.DAT»:
В первую очередь просмотрим последние записи в основном разделе отвечающую за автозагрузку «Software\Microsoft\Windows\CurrentVersion\Run» на наличие подозрительных приложений. Особое внимание привлекают последние две записи:
Эти записи являются подозрительными и имеют очень нестандартное расположение «C:\Users\PC\AppData\Roaming». Так же заметим, что в той же директории находится dll библиотека. Судя по синтаксису, «rund1132.exe» это системная утилита Windows которая импортирует функцию «Enter» из библиотеки «comctl32.dll». (Отличие в названии. Буква “l” заменена на “единицу”)
Утилита «rundll32.exe» предоставляет контейнер для выполнения DLL и имеет следующий синтаксис:
Также стоит отметить, что библиотека «comctl32.dll» является системной и поэтому находиться в данной директории не может.
Посмотрим запускался ли он. Для этого воспользуемся файлом реестра «SYSTEM»:
Рассмотрим куст реестра «ControlSet001\Control\Session Manager\AppCompatCache»:
Имеем некоторую отправную точку: знаем, что он запускался и как следствие имеем некоторую дату в малой окрестности которой произошел КИ.
Далее проведем анализ временных меток. Для этого с помощью утилит «fls» и «mactime» из пакета «The Sleuth Kit» построим таймлайн по временным меткам:
Теперь проанализируем полученный файл «timeline.csv» с помощью утилиты «Timeline Explorer».
Т.к. запуск ВПО был произведен 27.05.2015 в 07:31:05 то посмотрим, что происходило в окрестности этого времени в системе:
В эту же секунду до создания вредоносных файлов, в кэше браузера появляются временные word документы.
Выгрузим один из экземпляров. Для удобства переименуем временный файл на «suspicious_word.tmp» и проанализируем его с помощью утилиты «OfficeMalScanner»:
После анализа по известным сигнатурам, утилита установила временному файлу «suspicious_word.tmp» индекс вредоносности равный 20. Это говорит о том, что в документе имеется вредоносный исполняемый shell-код.
Узнаем подробнее какой эксплойт использовался для выполнения исполняемого shell-кода в word документе. Для этого воспользуемся утилитой «Yara-scanner». На гитхабе был найден репозиторий с готовым Yara-правилом для анализа вредоносных документов «quicksand_exploits». Воспользуемся им:
CVE-2012-0158 - уязвимость переполнения буфера в некоторых функциях библиотеки MSCOMCTL.OCX. Вредоносный код может быть вызван специально созданным файлом DOC или RTF для версий MS Office 2003, 2007 и 2010.
Узнаем подробнее откуда взялся этот документ. Самым известным способом доставки вредоносных документов является – почта. На скомпрометированной машине имеется несколько почтовых клиентов. Один из них это «Mozilla Thunderbird». Т.к. после анализа реестра стала известна дата запуска ВПО, а именно 27.05.2015, то в первую очередь просмотрим письма, присланные на скомпрометированный компьютер в окрестности этого дня. Среди всех писем имеется три письма с вложениями:
- Приглашение к участию в конференции ГА-2016
- Конкурс
- Монголия возвращает визовый режим для россиян
Убедимся, что вложения вредоносные. Для этого выгрузим их и снова воспользуемся утилитой «Yara-scanner» вместе с правилом для анализа вредоносных документов «quicksand_exploits»:
Видим, что все документы эксплуатируют уязвимость CVE-2012-0158. Посмотрим запускались ли они. Для этого рассмотрим куст реестра «Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.doc» из файла «NTUSER.DAT»:
Убеждаемся, что все они запускались.
После анализа SMTP заголовков писем было выявлено, ip адреса отправителей принадлежат компании «Chunghwa Telecom», которая является крупнейшей телекоммуникационной компанией в Китайской Республике, а также Японской телекоммуникационной компании «KDDI Corporation», которая является оператором мобильной связи. Адреса отправителей не подделаны.
На виртуальной машине с Windows 7 для анализа вредоносных word-документов установим такой же MS-WORD, как и на скомпрометированной машине, а именно MS-WORD 2010.
Для доставки полезной нагрузки на компьютер с помощью word-документа могут применяться два метода:
- После запуска, из документа выгружается дроппер, который скачивает основную полезную нагрузку.
- После запуска, из документа выгружается основная полезная нагрузка.
Проверить это можно открыв «wireshark» и открыть документ. Увидим что трафик отсутствует, а в папке %AppData% появились вредоносные файлы. Ещё для проверки есть «умный» способ. Если в документе эксплуатируется данная CVE, то можно просто открыть его как архив и увидим вредоносные файлы.
Таким образом, была восстановлена схема атаки:
- На компьютер жертвы было прислано три письма с вредоносными вложениями, эксплуатирующие уязвимость CVE-2012-0158.
- При открытии вредоносных вложений выгружается основная полезная нагрузка в виде dll-библиотеки «comctl32.dll» и системной утилиты «rundll32exe».
- Утилита «rundll.exe» импортирует единственную функцию из вредоносной библиотеки, после чего ВПО закрепляется в системе и начинает производить деструктивное воздействие.
С помощью плагина “pstree” выведем список процессов в виде дерева. На скринсшоте ниже видим вредоносный процесс с PID 3376 «rund1132.exe».
Рассмотрим его подробнее. Для этого воспользуемся плагином «dlllist», который выводит список импортированных библиотек и параметры командной строки, с которыми был запущен процесс:
Рассмотрев пункт «Command line» снова убеждаемся в том, что утилита «rund1132.exe» импортирует функцию «Enter» из библиотеки «comctl32.dll». Особый интерес вызывает библиотека “comctl32.dll”. С помощью плагина “dlldump” выгрузим её из оперативной памяти для дальнейшего анализа:
Также заметим, md5 суммы выгруженной библиотеки и той, которая располагается в директории «C:\Users\PC\AppData\Roaming» отличаются:
Для того, чтобы понять в чем между ними разница произведем базовый статический анализ данной библиотеки. Сначала узнаем каким компилятором была скомпилированна библиотека и запакована ли она:
Для того, чтобы понять в чем отличие библиотек, воспользуемся утилитой «Strings» из пакета «SysinternalsSuite» и сравним их строки. При анализе первой библиотеки, почти все строки имеют «мусорный вид», а значит скорее всего они обфусцированны. При анализе второй библиотеки выяснилось, что в ней почти все строки имеют читаемый вид. Это говорит о том, что после импортирования функции «Enter» все статические данные деобфусцируются.
В процессе изучения первой библиотеки, были найдены такие строки:
Пробуя их загулить попадаем на гит в проект под названием «ZLIB»:
Теперь становится ясно чем обфусцируются ключевые данные. Чтобы наверняка убедиться в этом, произведем дизассемблирование данной библиотеки и сравним полученный код с тем, что размещен на гитхабе. В качестве дизассемблера будет использоваться «IDA Pro».
Ниже приведены два фрагмента одинакового кода с гитхаба и дизассемблера, что подтверждает нашу теорию:
Далее имеет смысл рассматривать только «unload_comctl32.dll». Большинство её строк — это название функций функции. Это говорит о том, что вероятнее всего все они вызываются по адресу полученному с помощью функции «GetProcAddress». Полный список строк приводится не будет, т.к. он слишком огромный, но стоит отметить что в программе используются все функции для работы с сокетами, интернетом, файлами, процессами, сервисами, шифрованием, мьютексами, пайпами, клавиатурой, экраном и прочим.
DNS-адреса центров управления:
Проведем базовый динамический анализ в песочнице «Cuckoo Sandbox».
Т.к. вредоносный трафик нежелательно выпускать в сеть Интернет, то при загрузке библиотеки в песочницу, в качестве сетевого окружения выберем INetSim.
INetSim - это программный пакет на основе Linux, предназначенный для симуляции распространенных интернет-служб. Он позволяет анализировать сетевую активность неизвестных вредоносных образцов путем эмуляции серверов, работающих по протоколам HTTP, HTTPS, FTP, IRC, DNS, SMTP и т. д.
Перейдем во вкладку «Summary» и увидим какие «Yara» правила обнаружили вредоносную активность:
Видим, что у ВПО имеется как минимум следующий функционал:
- Соединение с центром управления по HTTP и TCP протоколам
- Повышение привилегий
- Создание скринсшотов
- Запуск кейлогера
- Кража учетных данных в системе
- Кража учетных данных в браузере IE7
- Изменение реестра
Скачаем образец сетевого трафика и проанализируем его вручную с помощью утилиты «Wireshark». В самом начале производится соединение на 80 порт. После этого идет GET запрос вида «GET /wpad.dat HTTP/1.1».
Просмотрим их в удобочитаемом виде:
Web Proxy Auto-Discovery Protocol (WPAD) — протокол для автоматической настройки прокси-сервера. Он служит для того, чтобы найти файл PAC (Proxy Auto Config), представляющий собой JavaScript с описанием логики, по которой браузер будет определять, как подключаться к нужному URL. При совершении любого запроса браузер вызывает функцию «FindProxyForURL» из PAC-файла, передает туда URL и хост, а в результате ожидает узнать, через какие прокси ходить на этот адрес.
Анализируя нашу функцию «FindProxyForURL» видим, что все запросы, которые производятся вне локальной сети «192.168.1.0/24», перенаправляются на прокси атакующего, который слушает на порту 8080. Стоит отметить, что данная техника позволяет перехватывать весь HTTP трафик, а также частично обойти HTTPS-шифрование и получить доступ к URL’ам всех запросов пользователя, где часто передаются OAuth-токены.
После данных манипуляций можно увидеть, что весь трафик идет на порт 8080, но все TCP соединения разрываются, т.к. «INetSim» не поддерживает симуляцию прокси и порт недоступен:
https://xss.pro/attachments/16211/?hash=421f119d8b5236b878a571ffe62b3cd6
На этом анализ сетевого трафика закончен.
Далее было произведено дизассемблирование этой библиотеки. Разбора реверса не будет, чтобы и так не раздувать статью. Приведу лишь результаты. На протяжении выполнения остальной части кода, используется методика противодействия динамическому анализу, которая заключается в подсчете миллисекунд между двумя участками кода с помощью функции «GetTickCount». Стоит отметить, что данный прием анти-отладки легко обойти с помощью большинства дизассемблеров, т.к. функция «GetTickCount» возвращает количество миллисекунд в регистр EAX, а его всегда можно обнулить вручную, либо скачать плагин к IDA, который будет это делать за вас.
Был найден механизм удаленного управления. Перед выполнением каждой команды ВПО посылает GET-запрос. Причем с каждым новым запросом значение «struct_counter[65]», которое изначально равно нулю инкрементируется на единицу. Таким образом самый первый GET-запрос будет выглядеть следующим образом: «/bbs/0/forum.php?sid=0»:
Этот факт понадобиться далее, чтобы написать правила детектирования для Snort.
Ответ сервера парсится в соответствии со своим сетевым протоколом и расшифровывает их используя следующий алгоритм. Для удобства читаемости алгоритм был переписан на «Python»:
Сам сетевой протокол имеет следующий вид:
- command_id – номер команды, которую нужно выполнить.
- length_of_encrypted_data – длина зашифрованной команды.
- length_of_decrypted_data – длина расшифрованной команды.
- encrypted_data – зашифрованная команда.
- Удаление ВПО
- Получение информации о ПК
- Выполнение консольной команды
- Получение списка сервисов
- Запуск/остановка/удаление сервиса
- Получение списка процессов
- Завершение процесса
- Получение списка файлов в директории
- Запись/чтение/удаление файла
- Создание каталога
Этап «Ликвидация»
После того, как на этапе «Изучение» ВПО было полностью разобрано, можно приступать к его удалению. Для этого необходимо выполнить следующие действия:
- Удалить фишинговые письма
- Удалить вредоносные вложения, выгруженные из этих писем
- Удалить вредоносную библиотеку «comctl32.dll» и утилиту для импортирования функций «rundll32.exe» из директории «C:\Users\PC\AppData\Roaming».
- Почистить ветку реестра «Software\Microsoft\Windows\CurrentVersion\Run» от автоматического запуска утилиты «rundll32.exe».
После полного удаления ВПО, необходимо удалить правила МЭ на блокирование входящего и исходящего траффика.
Этап «Выводы»
Этап «Выводы»
В процессе изучения ВПО было выяснено, что оно попало на компьютеры с помощью вредоносных вложений в фишинговых письмах используя уязвимость для старых версий «MS-WORD» CVE-2012-0158. По функционалу данное ВПО относится к типу «backdoor», но также имеет функционал «keylogger» и перехвата трафика. Оно имеет статические и динамические приемы обфускации в виде использования библиотеки «ZLIB» для сжатия ключевой информации и высчитывания время выполнения между интервалами команд с помощью функции «GetTickCount».
Для того, чтобы в следующий раз вовремя отреагировать на данный инцидент, необходимо на СЗИ внести новые правила, реагирующие на это ВПО. Для примера напишем следующее регулярное правило для «Snort», где спецсимвол \d означает целочисленное значение:
Также занесем DNS-адреса центров управления в черный список «/etc/snort/blacklist»:
- top.gupdiic.com
- panaba.empleoy-plan.com
- peak.measurepeak.com
На этом разбор закончен. Спасибо за внимание!?
