Расследование инцидентов ИБ in the wild: неожиданные источники информации

О расследовании компьютерных инцидентов, или Digital Forensics, уже много всего написано, есть много готового аппаратного и программного инструментария, основные артефакты операционных систем хорошо известны и описаны в пособиях, книгах и статьях. Казалось бы, что тут сложного – читай мануал и находи требуемое. Но встречаются технически сложные случаи, когда анализ тех самых общеизвестных артефактов не дает достаточной информации для восстановления хронологии событий. Как быть в такой ситуации? Разбираем на реальных примерах наших расследований.

Почему вообще возникает недостаток основных артефактов? Причин может быть несколько:

1) Инфраструктура не подготовлена подобающим образом для полноценного мониторинга и реагирования на события (об этом мы писали тут habr.com/ru/company/solarsecurity/blog/434176 ^[1])

2) Злоумышленник заметает следы, удаляя или модифицируя некоторые артефакты (он ведь тоже читает книги и статьи про Digital Forensic)

3) Некоторые артефакты затерты системой, если с момента инцидента прошло достаточно времени (примеры – ротация журналов событий, затирание MFT-записей).

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

В зависимости от ситуации на помощь могут прийти SIEM-системы, анализ сетевых потоков Netflow или сырого трафика (хотя в реальности в 90% случаев эта возможность отсутствует), а также необычные артефакты, которые относятся к какому-либо стороннему ПО, по стечению обстоятельств оказавшемуся в инфраструктуре заказчика.

Именно на последнем типе артефактов мы и остановимся.

Ivanti Endpoint Manager (ранее LANDESK Management Suite). Система управления ИТ-активами

www.ivanti.ru/company/history/landesk ^[2]

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

1) события журнала Security перенаправлялись в отдельный временный файл,
2) злоумышленник выполнял необходимые действия,
3) события перенаправлялись обратно в журнал Security,
4) временный файл удалялся.
5) Profit!

В результате, несмотря на то, что журнал Security был настроен подобающим образом, в нем отсутствовали какие-либо события, связанные с вредоносной активностью, а сам он при этом выглядел нетронутым.

После непродолжительного анализа мы выяснили, что злоумышленник «живет» в инфраструктуре уже около 2-3 лет, что позволило скомпрометировать все ключевые серверы. В таких случаях возрастает ценность любых дополнительных источников информации, так как некоторые базовые артефакты либо перетираются, либо малоинформативны и не позволяют составить полную картину инцидента.

В поисках дополнительных источников информации мы провели устную инвентаризацию сервисов и систем, используемых в инфраструктуре и выяснили, что совместно с внедрением нашего мониторинга заказчик начал разворачивать систему управления ИТ-активами
Ivanti Endpoint Manager.

Так как система работала пока нестабильно (события с агентов частично не отправлялись
на сервер), нам не удалось централизованно посмотреть на сервере события с хостов. Тем не менее, решив поискать артефакты, хранимые Ivanti Endpoint непосредственно на хосте, мы обнаружили, что это ПО хранит информацию о запусках процессов локально в следующей ветке реестра:

HKLMSOFTWAREWow6432Node]LANDeskManagementSuiteWinClientSoftwareMonitoringMonitorLog<Путь к исполняемому файлу>

При этом в соответствующих ключах хранится следующая информация:

• время первого запуска (в формате FILETIME)
• время последнего запуска (в формате FILETIME)
• количество запусков
• пользователь, с правами которого был запущен исполняемый файл

Артефакты запуска процессов от Ivanti Endpoint

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

Citrix NetScaler. Система предоставления доступа к корпоративным ресурсам и приложениям

www.citrix.com/ru-ru/products/citrix-adc ^[3]

Схема работы Citrix NetScaler

Еще одно любопытное расследование. Злоумышленник проник в инфраструктуру компании через VPN. Работал во временной зоне UTC +8. После аутентификации вел себя достаточно агрессивно (активно сканировал внутренние подсети по маске /24 и /16), вследствие чего, собственно, и был замечен.

VPN был настроен на системе предоставления доступа к корпоративным ресурсам и приложениям Citrix NetScaler. Изучив ее логи, мы смогли установить время первого «визита» (читай – дату компрометации), используемые злоумышленником учетные записи сотрудников (к слову, было скомпрометировано больше 5 учеток) и IP-адреса прокси-серверов, с которых он вел работу.

Само расследование закончилось удачно: нам удалось установить источник компрометации – оказалось, что внутренняя система сброса учетных данных, доступная из интернета, была подвержена SQL-инъекции.

Но сейчас хочется отметить другое: после прохождения VPN-аутентификации на Citrix NetScaler удачно логировались все HTTP-запросы пользователей. Злоумышленник, вероятно, либо не знал этого, либо перепутал свои сетевые интерфейсы и пустил собственные запросы к поисковым системам через корпоративную сеть заказчика. Это позволило нам получить информацию об интересующих злоумышленника системах, его компетенциях и используемом инструментарии.

Лог-файл Citrix NetScaler

Информация, которую злоумышленник искал через Citrix NetScaler

Информация, которую злоумышленник искал через Citrix NetScaler

Secret Net Studio. Система защиты информации от НСД

www.securitycode.ru/products/secret_net ^[4]

В один прекрасный день на нашу первую линию упал тикет с инцидентом на подозрительную аутентификацию под учетной записью ИТ-сотрудника компании на сервере администрирования в ночное время (сам сотрудник в это время был в отпуске, VPN у него не было). Архитектурно сервер администрирования находился в отдельном сетевом сегменте вместе с еще несколькими ключевыми серверами компании (в том числе и сервером Secret Net), при этом к нам в SIEM события поступали только с самого сервера администрирования (к сожалению, заказчики не всегда соглашаются подключать все потенциальные источники).

Первая линия, отрабатывая тикет и собирая информацию о том, что происходило после аутентификации, натыкается на различные подозрительные запуски процессов (нестандартные пути, имена бинарных файлов в одну букву) и запуск mstsc.exe, свидетельствующий о возможной RDP-сессии.

Поняв, что речь идет о потенциальной компрометации, мы запросили образы всех серверов
и начали свой анализ. Открыв первый же образ (сервер Secret Net), получили в подарок «большой сюрприз»: журналы System, Security и Application были удалены, причем удалены так, что даже попытки восстановления не увенчались успехом. Удалось лишь сопоставить, что записи в журналах TerminalServices сервера Secret Net по времени совпадают с запуском mstsc.exe на сервере администрирования, а значит, злоумышленник точно был на Secret Net. Анализ остальных серверов также не дал результатов.

В итоге мы оказались в ситуации, когда точно известно, что злоумышленник есть (он точно что-то делал и запускал), но хостовых логов у нас нет, потому что следы удалены,
а сетевых логов нет, потому что все серверы из одной подсети.

Выход нашелся даже из такой ситуации. Система Secret Net очень разносторонняя и состоит из многих компонентов как уровня ядра, так и уровня пользователя. Проанализировав каждый лог-файл, записанный и сохраненный различными компонентами Secret Net, мы наткнулись на несколько отличных артефактов, оставленных файловым контролем. Когда собрали все воедино, получили информацию и о действиях злоумышленника (он действительно был на каждом сервере из этой подсети), и о его инструментарии.

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

Схема работы злоумышленника через сервер Secret Net Studio

Лог-файл файлового контроля Secret Net Studio

KVRT. Бесплатное антивирусное средство

www.kaspersky.ru/downloads/thank-you/free-virus-removal-tool ^[5]

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

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

Среди используемых сканеров был KVRT, который обнаружил некоторые вредоносные файлы и поместил в карантин. Стандартное расположение файлов карантина – C:KVRT_DataQuarantine, а расшифровать их очень легко: простой XOR с общеизвестным ключом – e2 45 48 ec 69 0e 5c ac.

Расшифрованный карантин KVRT

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

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

Автор: JSOC_CERT

Источник ^[6]