Мы в JSOC CERT расследуем инциденты. Вообще все 170 человек в JSOC занимаются расследованиями, но в руки экспертов CERT попадают наиболее технологически сложные случаи. Как, к примеру, обнаружить следы вредоноса, если злоумышленник прибрал за собой? Каким образом найти «волшебника», удалившего важные бизнес-документы с файлового сервера, на котором толком не настроено логирование? Ну и на сладкое: как может злоумышленник без проникновения в сеть получить пароли от десятков не связанных между собой доменных учеток? Подробности, как всегда, под катом.
Будни JSOC CERT
Часто нам приходится оценивать фактическую компрометацию сети клиентов, для этого мы проводим:
- ретроспективный анализ жестких дисков и образов памяти,
- реверс-инжиниринг вредоносного ПО,
- при необходимости — экстренное разворачивание мониторинга и сканирование хостов на наличие индикаторов компрометации и следов хакинга.
В свободное время мы пишем детальные конспекты, методики и playbook’и — по сути инструкции, помогающие масштабировать даже комплексные расследования, т.к. по ним можно действовать полуавтоматически.
Иногда во время реагирования на инцидент — прямо посреди тушения «пожара» — приходится выступать еще и в роли «службы психологической поддержки». Однажды нас пригласили помочь с противодействием заражению подсети крупной организации. Сеть обслуживали два подрядчика, которые в этой ситуации самоотверженно набрасывали на вентилятор и друг на друга занимались чем угодно, только не поиском вредоносного червя. Дабы снизить градус истерии, пришлось-таки усадить всех за стол достать полотенце и бутылку бурбона и доходчиво объяснить, что сейчас не время искать виноватых. Определили процедуру распространения, развернули дополнительный аудит и стали планомерно вычищать заразу вместе и дружно.
Во время расследования нам часто приходятся ковырять образы дисков и памяти, чтобы найти там активное вредоносное ПО. Чтобы процесс был предсказуемым и объективным, мы формализовали и автоматизировали несколько методик по ретроспективному анализу дисков, а за основу взяли уже ставшую классической методику SANS — в оригинальной версии она достаточно высокоуровневая, но при правильном применении позволяет с очень высокой точностью обнаруживать активное заражение.
Понятно, что для выполнения всех-всех проверок требуются время и глубокие экспертные знания об особенностях работы различных компонентов операционных систем (да и софта специализированного нужно немало).
Как упростить проверку диска на наличие активного заражения? Делимся лайфхаком — его можно проверить динамически (как в песочнице), для этого:
- побитово скопируйте жесткий диск подозрительного хоста;
- сконвертируйте полученный dd-образ в формат VMDK с помощью этой утилиты;
- запустите VMDK-образ в Virtual Box/ VMware;
- и проведите анализ как на живой системе, уделяя внимание траффику.
Но всегда будут инциденты, для которых детальные инструкции не написаны и методики не автоматизированы.
Кейс 1. Бухгалтер ни при чем, или Как мы вредонос искали
Клиент попросил нас проверить компьютер бухгалтера на наличие вредоносного ПО: кто-то провел несколько платежных поручений на неизвестный адрес. Бухгалтер утверждал, что он не причастен к этому и что компьютер до этого вел себя странно: мышка иногда буквально сама двигалась по экрану — собственно, эти показания нас и попросили проверить. Загвоздка была в том, что нацеленный на 1C троянец сделал свои грязные делишки и самоудалился, а после заражения прошел почти месяц — за это время старательный эникейщик поставил кучу софта, перетерев неразмеченное пространство диска и тем самым сведя к минимуму вероятность успеха в расследовании.
В подобных случаях может помочь только опытный, придирчивый к деталям аналитик и обширная, автоматически пополняемая база Threat Intelligence. Так, в ходе проверки папки автозагрузки внимание привлек подозрительный ярлычок, указывающий на якобы утилиту по обновлению антивируса:
Саму тушку троянца с диска восстановить, к сожалению, не удалось, зато в кэше Superfetch «красовались» факты запуска утилиты удаленного администрирования из той же папки:
Сопоставив их с временем инцидента, мы доказали, что в краже денег виновен вовсе не бухгалтер, а внешний злоумышленник.
Кейс 2. Кто удалил мои файлы?
Большая часть наших расследований и реагирований на инциденты так или иначе связана с выявлением вредоносного ПО, целевыми атаками с применением многомодульных утилит и тому подобными историями, где есть внешний злоумышленник. Однако иногда бывают куда более приземленные, но не менее интересные расследования.
У клиента стоял самый обычный старенький файловый сервер, общие папки которого были доступны нескольким департаментам. На сервере лежало множество весьма важных бизнес-документов, которые кто-то взял и удалил. Спохватились поздно — после того как бэкап перезатерся. Стали искать виноватых.
Если вы когда-нибудь пытались гуглить, как определить, кто из пользователей удалил файл, то наверняка натыкались на советы, которые сводятся к тому, что все есть в логах Windows, если их правильно настроить заранее (кстати, мы уже давали пару советов, как настраивать журналы):
Но в реальности аудит файловой системы мало кто проводит, банально потому что файловых операций много и журналы будут быстро перетираться, да и для хранения логов нужен отдельный сервер…
Поставленную задачу мы решили разбить на две: во-первых, определить, КОГДА были удалены файлы; во-вторых, — КТО именно подключался к серверу в момент удаления. Если вы имеете представление об особенностях работы NTFS, то знаете, что в большинстве реализаций этой файловой системы при удалении файла место, которое он занимал, помечается как свободное, а его метки времени не меняются. Поэтому, на первый взгляд, время удаления установить нельзя.
Однако в файловой системе есть не только файлы, но и папки. При этом у папок есть специальный атрибут $INDEX_ROOT, описывающий в виде B-дерева содержимое папки. Естественно, удаление файла изменяет атрибут $INDEX_ROOT папки и тем самым изменяет ее временнЫе метки, в частности, в структуре $STD_INFO. Таким образом можно определить примерное время удаления большого количества файлов и папок, по аномалии в MFT (главной файловой таблице):
Выяснив, когда примерно были удалены файлы, можно попытаться узнать, кто в этот момент работал на севере, чтобы сузить круг подозреваемых. На ум приходят следующие способы:
- по журналам самого сервера — по событиям с EventID 4624/4625 видно, когда пользователь подключился и отключился;
- по журналам контроллера домена — EventID 4768 позволяет определить, что конкретный пользователь запрашивал доступ к серверу;
- по трафику — netflow/журналам внутренних маршрутизаторов — можно прикинуть, кто активно общался по сети с данным сервером по smb.
В нашем случае этих данных уже не было: прошло слишком много времени, логи ротировались. На этот случай есть еще один не очень надежный, но все же метод, а точнее ключ реестра — Shellbags. В нем сохраняется информация, в частности, о том, какой вид был у папки, когда пользователь ее посещал последний раз: таблица, список, крупные значки, мелкие значки, содержимое и т.д. И этот же ключ содержит метки времени, которые можно с высокой долей уверенности интерпретировать как время последнего посещения папки.
Метод нашелся, дело осталось за малым — собрать реестры с нужных хостов и проанализировать их. Для этого нужно:
- определить по доменной группе, кто имел доступ к папке (в нашем случае оказалось около 300 пользователей);
- собирать реестры со всех хостов, на которых работали эти пользователи (просто так этого не сделаешь, нужна специальная утилита для работы с диском напрямую, например, https://github.com/jschicht/RawCopy);
- «скормить» все реестры в Autopsy и воспользоваться Shellbags plugin;
- Profit!
Конкретно в данном инциденте время удаления файлов совпало со временем посещения корня удаленной папки одним из пользователей, что позволило нам сузить круг подозреваемых с 300 человек до 1.
Что произошло дальше с этим сотрудником — история умалчивает. Знаем только, что девушка созналась, что сделала это случайно, и продолжает работу в компании.
Кейс 3. Парольных дел мастер: «угнать» за пару секунд (и даже быстрее)
В сеть клиента, попросившего нас помочь, злоумышленник проник через VPN и сразу же был обнаружен. Что не удивительно, ведь сразу после входа он начал сканировать подсеть сканером уязвимостей — ханипот замигал, как новогодняя ёлка.
После блокировки учетной записи сотрудники службы безопасности клиента стали разбирать журналы VPN и увидели, что для проникновения злоумышленник использовал больше 20 разных доменных учёток (с большинством он успешно логинился, а для некоторых аутентификация завершилась неуспешно). И встал логичный вопрос: а откуда он узнал пароли от этих учетных записей? Для поиска ответа и были приглашены наши ребята из JSOC CERT.
В одной из прошлых статей мы уже говорили, что при расследованиях следует формировать и проверять гипотезы по мере уменьшения их вероятности. Так мы и сделали в этот раз, начав описывать типовые векторы кражи учетных записей:
- утечка данных внешнего сервиса
- Bruteforce
- Mimikatz или аналогичные техники
- Keylogger
- Phishing
- NTLM-hash harvesting (например, https://github.com/CylanceSPEAR/SMBTrap) или аналогичные сетевые атаки.
Проверили кучу версий, но нигде не было даже намека на атаку. Не то чтобы расследование зашло в тупик, но внутренний голос и здравый смысл подсказывали: что-то тут не так — нужно сделать шаг назад и посмотреть на картину шире.
Действительно, на первый взгляд, все эти учётки никак не связаны между собой. Их владельцы из разных, территориально разделённых департаментов. Обычно пользуются не пересекающимся множеством сервисов компании. Даже уровень ИТ-грамотности разный. Да, одного шага назад оказалось недостаточно — нужен был еще один.
К этому времени мы успели собрать огромное количество логов из разных систем предприятия и выделить следы, оставленные злоумышленником. Стали анализировать, где он засветился (напомню: он активно сканировал внутреннюю сеть компании). Заметили, что на фоне равномерно распределённого сетевого шума от разлетающихся эксплойтов есть аномально большое количество запросов к сервису по восстановлению паролей. Сервису, доступному из Интернета. Хм…
Если вы занимаетесь мониторингом событий безопасности, то наверняка знаете, что анализ попыток атак на доступный извне сервер часто не имеет смысла из-за интернет-шума: отличить действительно серьезные атаки от многочисленных попыток script-kiddie в общем случае непросто. Но не всегда.
Проведя некоторое время над журналами web-сервиса, мы смогли выделить следующие атаки на сервис:
- сканирование с помощью Acunetix,
- сканирование с помощью SQLmap,
- большое количество запросов к одной странице.
Третья атака, с первого взгляда, похожа на брут логинов пользователей. Но это не так, потому что сервис от этого защищен, как минимум, тем, что пароли хранятся в хешированном с солью виде — или нет? Нужно было быстро это проверить.
На картинке ниже представлена типовая схема работы сервиса по сбросу паролей:
Интересно в ней то, что пароли не всегда хранятся в защищенном виде — есть момент времени, когда они находятся в открытом доступе – сразу после заведения заявки и до ее исполнения! Большое количество запросов к одной странице оказалось не брутфорсом и не сканированием, а высокочастотными запросами с SQL-инъекцией, целью которых было выуживание паролей в момент их смены.
Вот так, проведя моделирование атаки на сервис, сопоставив информацию из логов web-сервера, журналов смены паролей и нескольких сетевых устройств, мы-таки отыскали точку проникновения злоумышленника на предприятие.
Так что, коллеги, копайтесь в raw data и да пребудет с вами сила!
Автор: Виктор Сергеев
