Расследование инцидента ИБ по горячим следам

Бэкграунд

В России сложилась интересная ситуация с расследованием инцидентов в сфере информационной безопасности. Большинство инцидентов замалчивается — если, конечно, дело не касается банковских счетов и финансовых транзакций. Администраторы и служба ИБ (если она есть) пытаются предпринять какие-то меры, затем все отчитываются перед руководством и об инциденте забывают. О полноценном расследовании речи, как правило, не идет, потому что либо безопасностью заниматься в компании просто некому, либо есть отдел, который разработал политику безопасности, внедрил современные технические средства, но этим и ограничивается. Ликвидация последствий сводится к смене чувствительной информации, такой как пароли и ключи, переустановке пары-тройки операционных систем (не всегда тех, которые необходимо).

Если следовать букве закона, когда обнаруживается инцидент информационной безопасности, нужно обращаться в государственные органы правопорядка. Но коммерческие структуры редко на это идут: мало того что приходится открыто признаться в собственном косяке, так еще и возникает множество вопросов — лицензионный ли софт, обеспечиваются ли меры, требуемые регуляторами… Потому у плохих ребят складывается ложное ощущение абсолютной безопасности, особенно если эти ребята занимаются взломом ради морального удовлетворения, а не ради коммерческой выгоды. Об одном таком случае я и расскажу в этой статье.

ТТХ

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

IT-инфраструктура представляет собой следующее:

• серверы располагаются в демилитаризованной зоне, доступ по сети в ДМЗ ограничивается межсетевыми экранами;
• повсеместно введена виртуализация серверов;
• присутствует сегментация сети с ограничением доступа между сегментами. Рабочие станции разнесены по VLAN’ам, с фильтрацией трафика между ними, в соответствии с внутренней иерархией;
• права доступа пользователям выделяются по принципу минимальных привилегий;
• централизовано софт обновляется только для продуктов Microsoft;
• ведется централизованный мониторинг серверов, правда, в основном с позиции доступности.

Инцидент

В начале года костяк топ-менеджмента компании N отправился на корпоративный выезд в далекие страны. Поездка предполагала не только развлечения, но и рабочие моменты, однако им не суждено было состояться: материал, который планировали презентовать и обсудить по-современному — с мобильного планшета, был утерян.

Прекрасное солнечное утро омрачилось: смартфоны и планшеты всех собравшихся в отеле на берегу океана (и не только их) оказались девственно чисты.

Данная информация была доведена до службы безопасности, которая разумно предположила, что тут не обошлось без внешнего вмешательства. Очевидно, что у всех сразу аккаунты iCloud взломать не могли, и служба безопасности заподозрила, что угроза исходит из корпоративной сети. Удаленно очистить мобильные устройства можно только через соответствующий сервис, например через корпоративный сервер Microsoft Exchange. Команда, позволяющая очистить устройство пользователя с адресом admin@local.host, выглядит следующим образом:

Clear-MobileDevice -Identity WM_TonySmith -NotificationEmailAddresses "admin@local.host"

Другие статьи в выпуске:

Хакер #184. Современный фронтенд

• Содержание выпуска
• Подписка на «Хакер»-60%

ИТ-службе поставили задачу проверить журналы сервера OWA: не было ли подозрительной активности в отношении аккаунтов пострадавших и компрометации пароля администратора сервера MS Exchange. Администраторы обнаружили зацепку — доступ к аккаунтам пострадавших в предшествующие инциденту дни неоднократно осуществлялся с нескольких нетипичных для них IP-адресов. Как я позже выяснил, засвеченные IP-адреса были выходными Tor-нодами.

Анализ логов OWA

Логи OWA хранятся по умолчанию в %SystemRoot%\System32\logfiles\w3svc1. Структура логов — обычные текстовые файлы, изучать которые без вспомогательного инструмента, особенно при большом количестве пользователей, утомительно. На помощь придет Log Parser — очень ценный инструмент, который пригодится не только в подобной ситуации.

Для удобства преобразуем все имеющиеся логи в один файл формата CSV:

c:\Program Files\Log Parser 2.2>LogParser.exe -i:iisw3c "select * into d:\temp\alllog.log from %SystemRoot%\System32\logfiles\w3svc1\*" -o:csv

После чего составим список событий, отражающих доступ пользователей к OWA:

c:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date,time, c-ip, cs-uri-stem, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access.csv" -o:csv

Выясняем, кто обращался к функциям OWA, отвечающим за удаление данных с устройства:

c:\Program Files\Log Parser 2.2>LogParser.exe -i:csv "select cs-username, date, time, c-ip, cs-uri-stem, cs-uri-query, cs(User-Agent) FROM d:\temp\alllog.log to d:\temp\access2.csv WHERE cs-uri-query LIKE '%wipe%'" -o:csv

Судя по системным логам, аккаунт администратора сервера OWA скомпрометирован не был. Целый день админы читали логи серверов, а служба безопасности тем временем беседовала со всеми админами по очереди, предполагая, что диверсант внутри компании. Однако это ни к чему не привело. Тогда они обратились по старому знакомству ко мне.

Поставили они такие задачи:

• установить источник угрозы — внутренний или внешний;
• выяснить сценарий атаки;
• определить последствия — скомпрометированные аккаунты и системы;
• определить дальнейшие действия для ликвидации угрозы.

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

Перепроверил результаты анализа логов администраторами. С помощью ntfswalk проанализировал MFT на наличие удаленных в последнее время файлов. Сервер OWA был чист и нетронут.

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

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

Я получил актуальные копии виртуальных машин и начал с ними разбираться. Подключив виртуальные жесткие диски к своей системе, запустил процесс восстановления данных — есть вероятность обнаружить удаленные логи файлов, которые использовал злоумышленник. Для этого можно взять любой удобный софт для восстановления данных, результат будет примерно одинаков. Я предпочитаю R-Studio.

Так как у меня в исследовании были только образы виртуальных машин, процедура несколько упрощалась — не нужно тратить время на снятие образов жесткого диска и оперативной памяти. Файлы жестких дисков виртуальных машин можно либо конвертировать в raw, либо монтировать как есть, с помощью соответствующих утилит. Образ RAM и файл сохраненного состояния можно сконвертировать в «сырой» образ. Не стоит забывать и про файлы подкачки — в них тоже порой находится много интересного. Volatility версии 2.3 умеет все это разбирать и конвертировать в случае необходимости.

Отличия работы с физической системой от виртуальной в том, что образ памяти заполучить сложнее — это связано с риском повредить текущее состояние и потерять данные, которые могут оказаться существенными. Также при исследовании физической системы необходимо применять дополнительные инструменты и методики для определения скрытых областей (например, Host Protected Area — HPA и Device Configuration Overlay — DCO).

Обследовать Windows-машины в моем случае я решил по следующему сценарию:

1. Определить, какие файлы и их атрибуты подвергались модификации (создавались, открывались, редактировались, удалялись). Для этого я использую инструментntfswalk или logparser. Например, командой:

   c:\Program Files (x86)\Log Parser 2.2\LogParser.exe" -i:FS -o:CSV -preserveLastAccTime:ON "Select HASHMD5_FILE(Path),CreationTime,LastWriteTime,LastAccessTime,Name,Path,Size into 'D:\FileTreeFD.csv' From 'Y: \*.*'
   

   Так мы получаем перечень всех файлов на анализируемом диске, со всеми необходимыми для анализа атрибутами. Делать это, конечно, лучше после восстановления данных, экспортируя все данные вместе с атрибутами на другой диск, для полноты картины.

   

   Как говорится — все есть файл. Если злоумышленник что-либо делал, об этом всегда остается информация, хотя бы удаленные файлы — пусть даже их содержимое уже недоступно, это может помочь выстроить понимание того, что произошло.

2. Необходимо определить, подключались ли внешние носители. В реестре всегда остается запись о подключении нового устройства. В логах System.evtx по умолчанию сохраняется запись c ID 20001. Для работы с логами есть соответствующие утилиты, например Windows USB Storage Parser. Этот кейс рассматривается на случай, если мы имеем дело с внутренним нарушителем, который просто закинул необходимый инструментарий с флешки, скопировал что нужно и унес домой для дальнейшей работы.
3. Необходимо проследить, в отношении каких учетных записей домена происходили следующие события: вход, выход, изменение пароля, групп и других свойств. Записи об этих изменениях хранятся в реестре и базах NTDS.dit или SAM. В логах остаются события с ID: 46274, 46265, 4634, 4624, 4778(при подключении по RDP).
4. Необходимо определить, какие программы или команды исполнялись. Записи остаются в логах, в папке Prefetch, в реестре (NTUSER.DAT).
5. Необходимо определить, какие сетевые подключения были. Данные об этом обычно можно снять либо с живой системы, либо из образа памяти, снятого с живой системы. Плагины Netscan или Linux_netstat в Volatility. В работе над слепком оперативной памяти я, как и многие, использую Volatility и в некоторых случаях Redline. Redlineинтересна тем, что позволяет полностью провести анализ, а затем наглядно визуализирует результат. При этом Redline позволяет загружать хеши известных файлов (которые можно также составлять самостоятельно), что упрощает задачу по анализу — утилита подскажет, что файл доверенный.

Помимо этого, можно извлечь содержимое процесса в файл для дальнейшего исследования.

След найден

В оперативной памяти одного из контроллеров домена обнаружились явные признаки компрометации:

• процесс svchost.exe запущен из C:\Windows\WOW64, а не из System32, как ему полагается;
• исходящие сетевые соединения, на IP-адрес частного хостинга в Штатах;
• неизвестный процесс запущен с PPID, не отображающимся в списке процессов.

Процесс был идентифицирован с помощью утилиты vol.exe.

vol.exe pslist -f image.vmem --profile=Win2008R2SP1x64 >pslist
Offset(V)  Name                  PID   PPID
0xfffffa801996cb30 spintlx64.exe         2820   1388 ....

Но PID 1388 больше нигде не значился, что всегда очень подозрительно. В первую очередь необходимо было извлечь тело этого процесса и проверить хотя бы антивирусом.

vol.exe dumpfiles -r spintlx64 -f image.vmem --profile=Win2008R2SP1x64 -D ./

При проверке на VirusTotal показатель выявления был 34/50. При поверхностном анализе обнаружилось, что дата компиляции и сборки бинарника 1992-06-19 22:22:17, а найденный при офлайн-анализе образа диска файл имел типичные для малвари изменения в атрибутах. Дата создания, изменения, последнего обращения были одинаковы и гораздо старше остальных системных файлов. Файл имел небольшой вес, создавал логи в зашифрованном виде и отправлял их по сети посредством HTTPS. С виду — типичный кейлоггер. Интересно, теперь предстоит разобраться, откуда и когда он попал в систему.

После восстановления данных все лог-файлы были загружены в Event Log Explorer для дальнейшего анализа. Штатные средства в такой ситуации не подходят: они не так поворотливы при поиске, а размеры логов очень большие (>30 Гб).

Отсортировав события по сетевому адресу источника, я получил несколько записей логов, показывающих, что осуществлялся сетевой вход (тип 3) одного из администраторов с сервераZabbix. По событию входа была определена дата установки кейлоггера. Ее подтвердило время появления первых файлов, создаваемых кейлоггером, — они удалялись, но их получилось восстановить вместе с атрибутами. Больше ничего подозрительного ни в логах, ни в памяти, ни в реестре обнаружено не было. Дополнительно я проанализировал домашние каталоги пользователей сервера, но это не принесло новых результатов.
Завершив работу с контроллером домена, я переключил внимание на сервер Zabbix — именно с него осуществлялся доступ к контроллеру домена по сети.

Обследование Linux-системы концептуально не отличается от обследования Windows-системы. Ищем все то же самое: историю действий, производимых с системой. Если копнуть глубже, то исследовать можно все, от аппаратного уровня до истории запуска Microsoft Paint или набранных текстов. Но к счастью, обычно такой задачи не стоит. Зачастую задача достаточно конкретна и нет необходимости тратить время на то, что не принесет результата.

В данном случае предстояло обследовать Linux-систему на предмет несанкционированного доступа. О сервере предварительно было известно следующее: установлен Suse Linux,Apache + PHP + MySQL + Zabbix с сопутствующим программным обеспечением — всем знакомым LAMP. Выяснилось, что сотрудник, ответственный за сервер, с ОС Linux общается на «вы». Установил и обслуживал сервер его предшественник, который давно ушел из компании.

Для виртуального образа диска сервера был запущен поиск удаленных файлов. Стоит заметить, что, когда имеешь дело с образами, всегда лучше работать с копией, а полученный оригинал хранить отдельно. Естественно, желательно протестировать работоспособность любого программного обеспечения до того, как приступать к исследованию. Приходилось сталкиваться с тем, что образы памяти, созданные разными способами, выдавали при исследовании разный результат. Хотя не стоит исключать вариант, что в систему исследователя закрался вирус, — может быть и такое.

Изучать образ содержимого оперативной памяти системы Linux можно тем же комплектом Volatility, желательно последнего стабильного релиза, хотя после версии 2.0 он вполне справляется. Существует некоторая разница в сравнении с анализом образов RAM семейства Windows — в Volatility нет и в принципе не может быть шаблонов структуры памяти для каждого ядра. Поэтому шаблон придется создать. Для этого необходимо:

• запустить копию исследуемой системы;
• скопировать туда директорию volatility/tools/linux;
• собрать проект, получив в результате файл module.dwarf, и скопировать его вместе с актуальным /boot/System.map того ядра, на котором работала система при снятии образа RAM, обратно на систему исследователя;
• упаковать оба файла, например в Linux.zip, и поместить архив вvolatility/plugins/overlays/linux/.

Теперь при запуске Volatility с ключом --info созданный тобой профайл будет виден в списке и с ним уже можно начать работу над образом. Без этого ничего не получится, потому что Volatility необходимо знать структуры данных ядра (module.dwarf) и иметь имена переменных, функций и их адреса в памяти (System.map).

Вернемся к исследованию. У меня было подозрение, что система, на которой установлен Zabbix, был скомпрометирована. Осталось понять, как и кто это сделал. Лишних ключей для SSH, посторонних учетных записей в системе не обнаружилось. Я предположил, что в системе есть backdoor, а возможно, и руткит. Для установки подобного рода софта зачастую требуются максимальные привилегии. Это очевидно, достаточно вспомнить основные принципы работы более-менее передовых руткитов в Linux-системах:

• загрузка модуля ядра;
• скрытие процессов, входов пользователей, модулей ядра, файлов, сетевых соединений;
• подмена системных файлов.

В первую очередь необходимо было проверить самые простые вещи, а именно историю выполненных команд: vol -f image.vmem —profile=Linux,x86 linux_bash

История команд была совсем небольшой, и первое, что бросилось в глаза, — это insmod rt.ko. Кстати, в файле истории на диске, конечно, ничего подобного не было, более того, восстановить какие-либо данные из файла истории также не удалось — содержимое уже было перезаписано быстро генерирующимися логами. Так что без образа памяти эти данные были бы неизвестны. Далее предстояло найти упомянутый в истории команд модуль ядра. Модуль был обнаружен на диске в директории PHP-скриптов интерфейса Zabbix.

Последующий анализ этого файла показал, что он прячет сам себя, маскирует при необходимости файлы, предоставляет привилегии root по команде. Управление ведется через файловую систему /proc/rt. С сетью не взаимодействует.

Просмотр сетевых соединений в образе памяти показал, что веб-сервер с Zabbix доступен из интернета. Конечно, я об этом не спрашивал, но подразумевал, что систему мониторинга в сеть никто не выставляет. Позже я выяснил у администраторов, что они так следят за системой, когда находятся вне офиса (несмотря на наличие VPN-аккаунта у каждого). Удобно, ничего не скажешь.

Я обратил внимание на Zabbix и пожалел, что не присмотрелся к нему раньше, — версия была подозрительно старая — 1.8.4. Поиск по exploit-db.com показал, что в данной версии в скрипте popup.php присутствует SQL-инъекция, позволяющая получить хеши пользователей (CVE: 2011-4674). Проверка уязвимости показала ее полную работоспособность.

Далее при обследованит файловой системы был обнаружен остаток боевого локального эксплойта, статически собранный бинарник ncat, небольшой веб-бэкдор.

Схема подключения злоумышленника стала очевидна: через веб-шелл запускался back connect, предоставляющий интерактивный шелл, после чего привилегии повышались с помощью руткита. При такой схеме злоумышленник использовал этот хост как промежуточный для передачи зловреда на контроллер домена, а также для передачи базыntds.dit и SYSTEM. Для эффективного поиска с помощью утилиты md5deep была создана база MD5-хешей всех файлов, восстановленных с образа сервера, после чего среди них произведен поиск хеша кейлоггера. Как результат — искомый файл был найден (правда, не с тем именем), а рядом лежал psexec и другие сопутствующие утилиты, которые были удалены.

Теперь можно было точно сказать, как произошел инцидент: злоумышленник, воспользовавшись уязвимостью Zabbix, получил и подобрал хеш пароля администратора Zabbix. С помощью скриптов Zabbix был загружен и запущен вспомогательный инструмент, в частности ncat для создания обратного соединения, с помощью которого был загружен и запущен локальный эксплойт, — версия ядра была полуторагодовалой давности.

Кстати говоря, Zabbix хранит скрипты в БД, и их следы были обнаружены в файле ibdata1.

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

Ради эксперимента я попробовал сбрутить хеши пользователей домена. Легко и непринужденно за пару часов были вскрыты 90% паролей.

По всей видимости, когда злоумышленнику надоело просто читать почту, он решил ее удалить — тем самым развлечься, или отомстить, или выполнить заказ конкурентов? Его мотивация мне неизвестна.

В итоге система Zabbix была переведена в изолированный сегмент, сетевой трафик поставлен на запись, настроена IDS. Я ждал подключений хулигана, но это уже совсем другая история…

Администраторам было рекомендовано восстановить контроллер домена с более ранней, чем заражение резервной копии, обновить версию Linux и Zabbix скомпрометированной системы, поменять пароли.

 

Как защитить свой iDevice

Любой iDevice общается с корпоративным сервером Exchange при помощи протокола ActiveSync. С позиции пользователя — защититься по умолчанию никак нельзя. Политика сервера Exchange подразумевает, что если устройство подключено к корпоративной сети, то администратор должен иметь возможность когда угодно управлять этим устройством для прекращения доступа к конфиденциальной информации. Помимо этого, пользователь, в случае утери или кражи, может зайти в OWA через любой браузер и запустить процесс удаленной очистки.

Если в организации имеется понимающий администратор Exchange — обратиться к нему и попросить убрать права на выполнение данной операции, а еще лучше — убрать доступ к пункту «Мобильные устройства» из веб-интерфейса OWA.

Вердикт

Настало время подвести итоги. К сложившейся ситуации привели ошибки администрирования сети и систем:

• слабая парольная политика — не установлена сложность пароля, не установлен срок действия пароля;
• отсутствует патч-менеджмент — кроме продуктов Microsoft, завязанных на WSUS, системы и софт не обновляется;
• не везде установлено антивирусное ПО — например, на контроллере домена антивирус, скорее всего, помог бы предупредить кражу хешей пользователей;
• отсутствует единая политика по доступу в интернет, доступ разграничивается без внятных правил;
• сеть не сегментирована;
• не осуществляется лог-менеджмент;
• лень.

По возможности старайтесь избегать этого :).