Alvaros
.
- Регистрация
- 14.05.16
- Сообщения
- 21.452
- Реакции
- 101
- Репутация
- 204
О расследовании компьютерных инцидентов, или Digital Forensics, уже много всего написано, есть много готового аппаратного и программного инструментария, основные артефакты операционных систем хорошо известны и описаны в пособиях, книгах и статьях. Казалось бы, что тут сложного – читай мануал и находи требуемое. Но встречаются технически сложные случаи, когда анализ тех самых общеизвестных артефактов не дает достаточной информации для восстановления хронологии событий. Как быть в такой ситуации? Разбираем на реальных примерах наших расследований.
Почему вообще возникает недостаток основных артефактов? Причин может быть несколько:
1) Инфраструктура не подготовлена подобающим образом для полноценного мониторинга и реагирования на события (об этом мы писали тут
You must be registered for see links
)2) Злоумышленник заметает следы, удаляя или модифицируя некоторые артефакты (он ведь тоже читает книги и статьи про Digital Forensic)
3) Некоторые артефакты затерты системой, если с момента инцидента прошло достаточно времени (примеры – ротация журналов событий, затирание MFT-записей).
Таким образом, если инфраструктура большая и разнообразная, инцидент развивался продолжительное время, а злоумышленник – «тертый калач», необходимы дополнительные источники информации, чтобы раскрыть все его действия и восстановить хронологию событий.
В зависимости от ситуации на помощь могут прийти SIEM-системы, анализ сетевых потоков Netflow или сырого трафика (хотя в реальности в 90% случаев эта возможность отсутствует), а также необычные артефакты, которые относятся к какому-либо стороннему ПО, по стечению обстоятельств оказавшемуся в инфраструктуре заказчика.
Именно на последнем типе артефактов мы и остановимся.
Ivanti Endpoint Manager (ранее LANDESK Management Suite). Система управления ИТ-активами
You must be registered for see links
Подключая к мониторингу одного из наших новых заказчиков, мы задетектировали в его инфраструктуре очистку журналов событий на одном из серверов, при этом в SIEM-системе не было никаких других проявлений вредоносной активности. В ходе анализа выяснили, что сервер таки был скомпрометирован, а злоумышленник использовал специальную технику, чтобы оставаться незамеченным. Заключалась она в следующем:
1) события журнала Security перенаправлялись в отдельный временный файл,
2) злоумышленник выполнял необходимые действия,
3) события перенаправлялись обратно в журнал Security,
4) временный файл удалялся.
5) Profit!
В результате, несмотря на то, что журнал Security был настроен подобающим образом, в нем отсутствовали какие-либо события, связанные с вредоносной активностью, а сам он при этом выглядел нетронутым.
После непродолжительного анализа мы выяснили, что злоумышленник «живет» в инфраструктуре уже около 2-3 лет, что позволило скомпрометировать все ключевые серверы. В таких случаях возрастает ценность любых дополнительных источников информации, так как некоторые базовые артефакты либо перетираются, либо малоинформативны и не позволяют составить полную картину инцидента.
В поисках дополнительных источников информации мы провели устную инвентаризацию сервисов и систем, используемых в инфраструктуре и выяснили, что совместно с внедрением нашего мониторинга заказчик начал разворачивать систему управления ИТ-активами
Ivanti Endpoint Manager.
Так как система работала пока нестабильно (события с агентов частично не отправлялись
на сервер), нам не удалось централизованно посмотреть на сервере события с хостов. Тем не менее, решив поискать артефакты, хранимые Ivanti Endpoint непосредственно на хосте, мы обнаружили, что это ПО хранит информацию о запусках процессов локально в следующей ветке реестра:
HKLM\SOFTWARE\Wow6432Node]\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog\
При этом в соответствующих ключах хранится следующая информация:
• время первого запуска (в формате FILETIME)
• время последнего запуска (в формате FILETIME)
• количество запусков
• пользователь, с правами которого был запущен исполняемый файл
Артефакты запуска процессов от Ivanti Endpoint
Благодаря этой информации мы смогли определить время появления злоумышленника на некоторых системах, о которых ранее не знали. Кроме того, часть его инструментария удалось раскрыть, исходя только лишь из названия исполняемых файлов.
Citrix NetScaler. Система предоставления доступа к корпоративным ресурсам и приложениям
You must be registered for see links
Схема работы 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. Система защиты информации от НСД
You must be registered for see links
В один прекрасный день на нашу первую линию упал тикет с инцидентом на подозрительную аутентификацию под учетной записью ИТ-сотрудника компании на сервере администрирования в ночное время (сам сотрудник в это время был в отпуске, 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. Бесплатное антивирусное средство
You must be registered for see links
К нам обратились за помощью в расследовании инцидента, связанного с исходящей вредоносной активностью (деятельность ботнета и майнер) с публичных адресов компании. Получив образы и логи системы, мы начали анализ и нашли некоторые артефакты, указывающие на компрометацию публичного веб-сервиса организации и оставленные вредоносные файлы. К сожалению, этого не хватило, чтобы ответить на все вопросы, заданные нам заказчиком: среди прочего мы не нашли файловых следов майнера, хотя времени между фиксацией вредоносной активности и нашим расследованием прошло немного.
Вернувшись еще раз к артефактам и логам, мы обратили внимание на следы работы нескольких бесплатных антивирусных сканеров. Стало ясно, что файлы, которых нам не доставало, были зашифрованы и помещены в карантин, а метки времени файловой системы благополучно стерты.
Среди используемых сканеров был KVRT, который обнаружил некоторые вредоносные файлы и поместил в карантин. Стандартное расположение файлов карантина – C:\KVRT_Data\Quarantine, а расшифровать их очень легко: простой XOR с общеизвестным ключом – e2 45 48 ec 69 0e 5c ac.
Расшифрованный карантин KVRT
Как выяснилось позже, ИТ-администратор все же успел просканировать системы бесплатными антивирусными сканерами до нашего приезда, несмотря на рекомендации ничего не трогать.
В итоге файлы, полученные из карантина, помогли закрыть пробелы в хронологии событий и ответить на все вопросы.
_____________________
Каждое расследование – это всегда что-то необычное, уникальное и разностороннее. Да, есть известные артефакты операционных систем, но до начала расследования трудно спрогнозировать полноту информации, которую можно будет получить после их анализа. Поэтому перед техническим расследованием инцидента мы рекомендуем провести инвентаризацию ПО и систем и не лениться изучить их как возможный источник в расследовании.



