Реагирование на инциденты

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

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

Часть 1. Что скрывают pagefile.sys

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

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

Размер pagefile.sys в файловой системе по умолчанию задается операционной системой, но пользователь всегда может отключить файл подкачки или изменить его максимальный размер. Стандартное расположение файла в корне системного раздела, но он может находиться и на любом другом логическом диске в зависимости от того, куда пользователь его поместил. Нужно помнить этот факт.

Прежде чем мы займемся извлечением pagefile.sys, надо понять, что это за файл с точки зрения файловой системы. Для этого воспользуемся ПО AccessData FTK Imager:


Видно, что это скрытый системный файл, который так просто не скопировать.

Как тогда получить этот файл? Сделать это можно несколькими способами:

• если вы работаете с активной операционной системой, то для извлечения используем ПО FTK Imager или KAPE Эрика Циммермана
  
  
• если есть цифровая копия накопителя или же сам файл просто копируем файл или работаем с ним напрямую.

Не забываем, что файлы pagefile.sys могут находиться в теневых копиях (Volume Shadow Copy) и на других логических дисках. Правда, бывают случаи, когда правила теневого копирования задает сам пользователь и исключает копирование файла подкачки (в системном реестре есть ветвь HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\BackupRestore\FilesNotToSnapshot, где указываются файлы, которые будут исключены из теневого копирования).

На изображении ниже можно увидеть, как меняется объем обнаруженных данных в текущем файле подкачке (на изображении крайний левый) и файлах подкачки, которые были извлечены с этого же накопителя из теневых копий, созданных в разное время.

Важный момент, о котором стоит помнить: начиная со сборки 10525 Windows 10 используется компрессия файла подкачки. При нехватке памяти система сжимает неиспользуемые ресурсы памяти в каждом процессе, позволяя большему количеству приложений оставаться активными одновременно. Для декомпрессии такого файла необходимо использовать специализированное ПО.

Например, можно использовать для декомпрессии утилиту winmem_decompress Максима Суханова:



Это будет полезным, когда поиск в изначальном файле подкачки результатов не дал или же необходимые данные находились в сжатом виде.

Итак, когда файл pagefile.sys у нас в руках, можно приступать к его исследованию. И тут надо выделить две ситуации: первая когда мы знаем, что искать, и вторая когда не знаем. В первом случае это могут быть фрагменты файлов, следы работы того или иного ПО, какая-то пользовательская активность. Для такого поиска обычно используется шестнадцатеричный редактор X-Ways WinHEX (или любой другой). Во втором случае придется полагаться на специализированное ПО, например, MAGNET AXIOM, Belkasoft Evidence Center, утилиту strings (ее можно считать основной и наиболее часто используемой), ПО Photorec (ПО для восстановления, использующее сигнатурный метод), в некоторых случаях применять yara-правила (при условии настройки сканирования файлов большого размера) или же просто просматривать файл вручную.

А что можно найти в файле pagefile.sys, и почему мы делаем акцент на файле подкачки? Все просто: это данные, частично выгруженные из оперативной памяти, то есть процессы, файлы и прочие артефакты то, что было активно и функционировало в ОС. Это может быть часть интернет-истории и IP-адреса, информация о запуске каких-то файлов или же сами файлы, фрагменты изображений и текстов, сведения о сетевых запросах функционировавшего ранее ПО, следы работы вредоносного ПО в виде журналов нажатых клавиш, системные файлы и журналы ОС и много всего другого.

Идем в поля

Пора переходить непосредственно к реальным делам и исследованиям. Итак, что полезного можно найти в файле подкачки Windows с точки зрения цифровой криминалистики?

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

Чтобы дать полный ответ, что произошло и как, криминалисту необходимо установить начальную точку заражения, используемый злоумышленниками инструментарий и последовательность действий. В ходе исследования удалось найти не все следы функционирования вредоносного ПО. И вот тут был проанализирован pagefile.sys. Как мы уже знаем, там можно найти страницы из памяти процессов, выгруженные из оперативной памяти в файл подкачки, которые иногда можно восстановить, например, при помощи ПО Photorec сигнатурным методом, как и было сделано в данном кейсе.

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

Выше представлен пример файлов (Photorec присвоил файлам имена, исходя из смещения относительно начала файла подкачки), выгруженных в ходе проведения этого исследования. Мы видим, что это исполняемые, графические, текстовые и иные файлы. Дальше все просто: анализируем их, исходя из необходимых критериев и задач.

В конкретном случае из файла подкачки были восстановлены dll-файлы, в которых есть вредоносный код. Ниже приведен пример их детектов на VirusTotal (поиск осуществлялся по контрольной сумме файлов):



В ходе анализа был установлен адрес удаленного сервера, с которым могли взаимодействовать эти файлы. При помощи шестнадцатеричного редактора X-Ways WinHEX в исследуемом pagefile.sys обнаружены строки, содержащие адреса удаленного сервера. Это говорит о том, что обнаруженные файлы функционировали в ОС и активно взаимодействовали со своим удаленным сервером. А вот и детекты сервиса VirusTotal за декабрь 2018 года:




Таким образом, в данном кейсе благодаря обнаруженным в pagefile.sys сведениям мы установили всю цепочку заражения.

А что еще?

Существуют порой уникальные случаи, когда в файле подкачки помимо иных следов можно найти закодированные в base64 снимки экрана. Например, такие при отправке создает банковский троян Buhtrap.

В конкретном случае начало файла было следующим: /9j/4AAQSkZJRgABAQEAYABgAAD/. Это заголовок jpeg-файла, закодированный в base64 (представлена часть изображения):



Вышеуказанный фрагмент скопировали, декодировали и добавили к нему расширение jpg. Нам повезло, и обнаруженный скриншот содержал полный снимок активного рабочего стола бухгалтерского компьютера с открытым ПО 1С: Бухгалтерия, на котором отображался финансовый баланс предприятия и прочие важные данные. Другие обнаруженные закодированные изображения из-за особенности хранения информации в файле подкачки были неполными (битыми).

Другой пример. В ходе одного из инцидентов обнаружены следы фреймворка Cobalt Strike (характерные строки в файле подкачки SMB mode, status_448, ReflectiveLoader):




И впоследствии можно попытаться выгрузить модули. На изображении выше это keylogger.dll и screenshot.dll, но могут быть и другие.

Идем дальше. Входящий в Cobalt Strike и часто используемый злоумышленниками модуль mimikatz это инструмент, реализующий функционал Windows Credentials Editor и позволяющий извлекать аутентификационные данные залогинившегося в системе пользователя в открытом виде. Именно в файле подкачки были обнаружены следы его функционирования, а именно следующие символьные строки:

• sekurlsa::logonPasswords извлечение логинов и паролей учетной записи
• token::elevate повышение прав доступа до SYSTEM или поиск токена администратора домена
• lsadump::sam получение SysKey для расшифровки записей из файла реестра SAM
• log Result.txt файл, куда записываются результаты работы ПО (не забываем поискать этот файл в файловой системе):
  
  

Следующий пример следы функционирования банковского трояна Ranbyus, который состоит из множества модулей. В ходе одного исследования в файле подкачки, который находился в теневой копии (VSS), обнаружили строки, сформированные дополнительным модулем, расширяющим функциональные возможности ПО Ranbyus. Строки содержали, помимо всего прочего, и введенные аутентификационные данные пользователя (логин и пароль) в системе клиент-банк. А в качестве примера часть сетевого запроса, включая сведения об управляющем сервере, который был обнаружен в файле pagefile.sys:



На самом деле довольно часто можно встретить примеры POST-запросов вредоносного ПО к своим управляющим серверам, а также ответы этих серверов на запросы. Ниже приведены такие случаи на примере взаимодействия ПО Buhtrap со своим управляющим сервером:



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

В процессе реагирования мы вышли на сервер с ОС Windows Server 2012, участвовавший в инциденте. Файлы системных журналов уже не один раз перезаписаны, а свободное дисковое пространство затерто. Но там был файл подкачки! Благодаря долгой работе сервера без перезагрузки и большому объему файла подкачки в нем сохранились следы запуска ПО злоумышленников и скриптов, которые на момент исследования уже отсутствовали в файловой системе без возможности восстановления. Сохранились и сведения о каталогах и файлах (пути и имена), которые создавались, копировались и впоследствии удалялись злоумышленниками, IP-адреса рабочих станций организации, откуда копировались данные, и прочая важная информация.

Что интересно, автоматизированный анализ при помощи различного криминалистического ПО полных результатов не дал, каких-то определенных критериев поиска не было, поэтому специалисты прибегли к ручному анализу файла подкачки, используя шестнадцатеричный редактор X-Ways WinHEX.

Ниже несколько примеров того, что обнаружили специалисты:





Сведения об использовании утилит pcsp.exe и ADExplorer.exe (присутствуют и даты, и пути).

Дальше сведения об использовании vbs-скрипта (на изображении начало и конец).
Примечательно, что указаны учетные данные (логин и пароль) одного из администраторов контроллера домена, которые ранее были скомпрометированы:




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

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




Можно обнаружить и такую информацию, как имя компьютера и серийный номер тома, где располагался файл подкачки:



А также информацию из файлов Prefetch и, конечно же, системные журналы Windows.

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

Кадр из м/ф Инспектор Гаджет

У людей, занимающихся обнаружением и расследованием компьютерных инцидентов, есть неписаная истина: Инцидент рождается и умирает на хосте. Сегодня подавляющее большинство статей, исследований и правил детекта связаны именно с хостовыми логами (поэтому на рынке и появился EDR). Тем не менее очевидно, что события с хоста не дают полной картины происходящего и необходимо анализировать то, что происходит не только на конечных точках, но и в сети. Не так давно появился Network Traffic Analysis (NTA) относительно молодой класс решений, который помогает обнаружить злоумышленника, живущего в сети. Четкого понимания о функционале NTA у ИБ-сообщества пока не сформировалось, но мы со стороны центра мониторинга и реагирования на кибератаки все-таки попробуем рассказать, какой должна быть такая система и как она должна работать в идеале, чтобы полностью решать свои задачи.

Для анализа сетевого трафика традиционно использовались системы обнаружения атак IDS, работающие по сигнатурному принципу. С появлением SOC сетевые детекты стали обрастать правилами корреляции, которые базировались на различных событиях сетевого оборудования (Netflow, NGFW) и их встроенных механизмах (например, DPI Application Control). Уже эти технологии дали большое преимущество при обнаружении и расследовании инцидентов. Например:

• хостовой детект, вероятно, покажет нам что-то подозрительное,
• но без IDS-правил мы, скорее всего, не сможем однозначно идентифицировать угрозу (например, по детекту активности подозрительный процесс -> сетевая активность, мы сможем понять, что имеем дело с Downloader, но без детекта на уровне сети не сможем определить семейство);
• некоторые хостовые детекты имеют альтернативное отображение в IDS-правилах, и при наличии известных проблем покрытия и масштабирования (которые возникают, когда надо собирать логи или отслеживать состояния того же EDR на большом количестве хостов) возможно перенести детектирующую логику с хостов на сеть, не потеряв таким образом детект события;
• злоумышленники стремятся обходить детекты, построенные на хостовых логах. Например, выгружают Enpdoint Drivers, отключают Kernel Callback, перенаправляют логи во временный файл, а после выполнения вредоносных действий возвращают поток логов в старое место, после чего удаляют временный файл. А вот сетевым детектам они противостоят реже и лишь в собственном кастомном инструментарии;
• некоторые IDS-правила не имеют прямого альтернативного отображения в детектах, построенных на хостовых логах (речь, конечно, про эксплуатацию уязвимостей различных сетевых протоколов (SMB, RDP) для запуска постороннего кода);
• анализ сетевой активности способен решить проблему профилирования пользовательских действий внутри корпоративной инфраструктуры, а значит, увеличивает вероятность обнаружения злоумышленника;
• технология Application Control может выявить использование злоумышленником вполне легитимных Remote Access Tool, в то время как хостовый детект, скорее всего, промолчит, так как подозрительная активность отсутствует.

Почему появился NTA

Но, к сожалению, в современных играх в кошки-мышки со злоумышленником даже указанных выше преимуществ недостаточно, чтобы своевременно обнаружить его присутствие. На то есть несколько причин.

Во-первых, при том, что IDS-правила достаточно эффективны при обнаружении инцидента, слабости сигнатурного подхода и принципов работы современных IDS-систем очевидны. Например, сигнатуру можно сбить даже простейшей операцией XOR, а задетектировать распределенное по времени сканирование крайне сложно.

Кроме того, при сработке IDS-правил обычно сохраняются только несколько сетевых пакетов или сессий (если говорить о распространенных Snort и Suricata). Но для правильного построения работы системы часто требуется дополнительный контекст происходящего, то есть аналитику нужно смотреть внутрь сетевого трафика.

Также у многих организаций нет выделенного IDS-решения. Вместо этого у них стоит обычный модуль в составе навороченного NGFW или UTM-комбайна, который из-за высокой загруженности и вовсе часто отключают. В случае же с подключением событий сетевой активности из NGFW или UTM в SIEM-систему остро встает вопрос количества EPS и стоимости ресурсов для их обработки. Ведь, как мы знаем, данный источник генерирует огромное количество событий.

Если все-таки завести NGFW или UTM в качестве источника в SIEM, то можно потенциально профилировать сетевую активность, но проблема обнаружения аномалий останется открытой, ведь таких возможностей у SIEM нет. Да и не должно быть. Скорее всего, мы сможем лишь отслеживать попытки постучаться на порты или адреса, не прописанные в легитимной активности (а теперь представьте, сколько времени это займет в крупной компании со сложной инфраструктурой).

Все это привело ИБ-сообщество к пониманию, что для эффективного обеспечения сетевого мониторинга и анализа сетевой активности как на периметре, так и в сегментах корпоративной сети необходим обособленный класс решений. Он был назван Network Traffic Analysis NTA (или NDR).

Как и на заре EDR, у сообщества пока нет четкого понимания в части функционала, закладываемого в NTA/NDR, так что к этой категории относят совершенно разные продукты и решения.

Мы же со своей стороны хотели бы пофантазировать о том, каким может быть идеальный коммерческий NTA/NDR в современных реалиях и какие задачи
он должен решать, чтобы своевременно обнаруживать злоумышленника и помогать
при расследовании и реагировании на инциденты.

Что умеет идеальный NTA

Мы опишем задачи, с которыми должны справляться современные NTA/NDR-решения, в формате противодействия подходам, применяемым злоумышленниками.

Подход 1

• Злоумышленник использует известные хакерские утилиты/инструменты/ВПО, 1-day уязвимости
• Противодействие: IDS-правила
• Как решается сейчас: модули IDS в NGFW или UTM

В данном пункте может быть огромное количество примеров, но мы просто отметим, что наш опыт мониторинга и расследований инцидентов подсказывает, что в 2020 году все еще можно поймать злоумышленника посредством IDS-правил. И вот почему:

• злоумышленники до сих пор очень часто используют 1-day уязвимости EternalBlue и начинают брать на вооружение BlueKeep, SMBGhost;
• злоумышленники зачастую ленивы и редко переписывают протоколы общения известного ВПО с серверами управления;
• злоумышленники используют известные инструменты BloodHound, Impacket и другие, которые работают с протоколами и компонентами ОС SMB, WMI, LDAP.

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

Подход 2

• Злоумышленник использует легитимные средств удаленного управления
• Противодействие: Application Control
• Как решается сейчас: модули Application Control в NGFW или UTM

Злоумышленники часто используют легитимные средства удаленного управления: UltraVnc, TeamViewer, Ammyy Admin, Radmin, AnyDesk и др. Без капли сомнения (и стеснения) они устанавливают эти утилиты на хост, еще и разбавляют инструментарий различными ухищрениями: проксируют трафик через определенные порты для преодоления Firewall, используют Dll Hijacking/Dll SideLoading для подгрузки утилитами своих библиотек и скрытной работы, прячут данные утилиты вглубь бинарных файлов, рассылаемых по электронной почте.
Вопрос количества протоколов и ПО, определяемых компонентом Application Control в идеальном NTA/NDR всегда останется открытым ему ведь не нужно поддерживать их столько же, сколько NGFW или UTM Или все-таки нужно? Но детектировать самые известные легитимные средства удаленного управления оно точно должно.

Подход 3

• Злоумышленники используют административные протоколы управления (RDP, SSH)
• Противодействие: профилирование сетевой активности с использованием
• статистических алгоритмов
• Как решается сейчас: события с NGFW или UTM в SIEM и попытка ручного профилирования

Для осознания того, что происходит в сети, нужно профилирование сетевой активности на уровне хоста. Это аксиома. Вы наверняка слышали про систему UEBA (User and Entity Behavior Analytics). К сожалению, ее работающих вариантов пока не так много, но искреннее верим, что именно в продуктах класса NTA/NDR эта технология должна раскрыться ведь она призвана улучшить и дополнить функционал обнаружения.

Над технической реализацией пусть фантазируют вендоры, но мы уверены, что в NTA/NDR нужен компонент, который будет анализировать сетевые потоки, гуляющие как внутри инфраструктуры, так и за ее пределы. И результатом этого анализа хочется видеть статистическую обработку: кто, как, когда и куда ходил, делал ли он это раньше, как часто.

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

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

Подход 4

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

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

Первый пример выявление зараженных систем путем анализа обращений к серверам управления CNC.

Итак, у нас есть хост, зараженный неизвестным типом ВПО, и он периодически обращается (в данном примере достаточно шумно) к своему CNC через http. Вот так:



Здесь мы оставляем за рамками обсуждения тематику обнаружения чего-либо в зашифрованном трафике и считаем, что наш идеальный NTA/NDR работает в режиме SSL-инспекции.

Как мы можем задетектировать такую активность, если, например, сервер управления CNC не входит в список известных индикаторов компрометации и не стоит у нас на мониторинге? Тут нам поможет профилирование сетевой активности (вряд ли сервер управления CnC будет самым популярным по числу обращений, а количество и интервал запросов подсветят нам не пользовательские запросы) и алгоритмы определения похожести сетевого трафика (техническую реализацию оставим на усмотрение вендора).

Если обратить внимание на рисунок выше, то можно заметить, что у всех запросов схожий размер сетевых пакетов, небольшие интервалы времени, путь обращения в коротких запросах хоть и рандомный, но имеет одинаковую длину, путь в длинных запросах имеет общую часть (до второго знака =). Этих данных должно хватить идеальному NTA/NDR для того, чтобы подсветить подозрительную активность и своевременно обнаружить присутствие злоумышленника в инфраструктуре.

Второй пример выявление зараженных систем путем анализа внутреннего трафика инфраструктуры и выявление паттернов схожести.

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



Во всех TCP-сессиях (здесь отдельные пакеты) между зараженными хостами передавался TCP payload, который начинался с двух одинаковых dword. Именно так модуль ВПО, работающий на зараженной системе, узнавал предназначенные для себя сетевые пакеты.

Так как же обнаружить применение подобного инструментария злоумышленником, если мы еще не проводили реверс сэмпла, разбор протокола общения модулей, да и вообще не знаем, что заражены? Здесь нам также поможет механизм нашего NTA/NDR, который сможет обнаружить паттерн среди передаваемых данных в TCP payload внутри инфраструктуры, принимая во внимание дополнительные условия (хосты, порты, размеры сессий, протоколы).

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

Насколько это реально?

Конечно, такое описание функционала идеального NTA/NDR может вызывать споры, но мы лишь рассказали, чего ждем от данного класса решений и какие проблемы в обнаружении и расследовании инцидентов, на наш взгляд, он сможет решить.

И все-таки не хочется, чтобы завтра инструментарий, работающий исключительно на сигнатурном анализе из 90-x, вдруг начали называть NTA или NDR. Этому молодому классу решений (который, к слову, является одним из краеугольных камней современного SOC наряду с SIEM и EDR) нужен глоток свежего воздуха в виде новых подходов к глубокому анализу трафика, новых методов выявления угроз и возможностей по хранению и экспорту данных для расследования и ретроспективного анализа.

Игорь Залевский, руководитель отдела расследования киберинцидентов JSOC CERT