Русский
Русский
English
Статистика
Реклама

Threat intelligence

Что такое threat hunting, и как правильно охотиться на киберпреступников

09.07.2020 20:08:37 | Автор: admin


Threat hunting или TH проактивный поиск следов взлома или функционирования вредоносных программ, которые не обнаружены стандартными средствами защиты. Сегодня мы поговорим о том, как устроен этот процесс, какие инструменты можно использовать для поиска угроз, о чем помнить при формировании и проверке гипотез.

Что такое threat hunting и зачем он нужен


В процессе threat hunting аналитик не ждет, пока сработают сенсоры систем защиты, а целенаправленно ищет следы компрометации. Для этого он вырабатывает и проверяет предположения, как злоумышленники могли проникнуть в сеть. Такие проверки должны быть последовательными и регулярными.

Правильное внедрение процесса должно учитывать принципы:

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

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

Особенно актуальны вопросы выявления целевых атак для организаций, которые были ранее взломаны. Согласно отчету FireEye M-Trends, 64% ранее скомпрометированных организаций вновь подверглись атаке. Получается, что больше половины взломанных компаний все еще находятся в зоне риска. Значит, нужно применять меры для раннего выявления фактов компрометации этого можно добиться с помощью TH.

Threat hunting помогает ИБ-специалистам сократить время на обнаружение взлома, а также актуализировать знания о защищаемой инфраструктуре. Также TH полезен при использовании threat intelligence (TI) особенно когда при выдвижении гипотезы используются TI-индикаторы.

Как формировать гипотезы для проверки


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



Рисунок 2. Схема проведения threat hunting

Идея гипотезы может родиться из личного опыта аналитика, однако существуют и другие источники для ее построения, например:

  • Индикаторы threat intelligence (TI-индикаторы). Простейшая гипотеза, имеющая структуру: злоумышленник использует новую модификацию утилиты X, которая имеет MD5-хеш Y.
  • Техники, тактики и процедуры атакующих (TTPs). Информацию про TTPs современных киберпреступников можно найти в базе MITRE ATT&CK. Пример гипотезы: злоумышленник взломал пользовательскую рабочую станцию и методом перебора пытается подобрать пароль от привилегированной учетной записи.
  • Аналитика автоматизированных средств обработки данных об инфраструктуре. Их данные помогут выявить аномалии. Например, с помощью систем asset management можно заметить появление нового узла в сети без ведома администраторов. Резкое увеличение объема трафика на сетевом узле тоже может стать поводом для более детального изучения этого узла.
  • Информация, обнаруженная в ходе проверки предыдущих гипотез.

Инструменты threat hunting


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



Рисунок 3. Классификация источников информации для проведения TH

Наибольшее количество релевантной информации содержится в логах и сетевом трафике. Анализировать информацию из них помогают продукты классов SIEM (security information and event management) и NTA (network traffic analysis). Внешние источники (например, TI-фиды) тоже нужно включать в процесс анализа.

Как это работает на практике


Главная цель проведения TH обнаружить взлом, который не был выявлен автоматизированными средствами защиты.

Для примера рассмотрим проверки двух гипотез. На практике покажем, как системы анализа трафика и анализа логов дополняют друг друга в процессе проверки гипотезы.

Гипотеза 1: злоумышленник проник в сеть через рабочую станцию и пытается получить контроль над другими узлами в сети, для продвижения использует исполнение команд через технологию WMI.

Нарушители получили учетные данные привилегированного пользователя. После этого они пытаются получить контроль над другими узлами в сети с целью попасть на хост с ценными данными. Один из методов запуска программ на удаленной системе использование технологии Windows Management Instrumentation (WMI). Она отвечает за централизованное управление и слежение за работой различных частей компьютерной инфраструктуры. Однако создатели предусмотрели возможность применения такого подхода к компонентам и ресурсам не только отдельно взятого хоста, но и удаленного компьютера. Для этого была реализована передача команд и ответов через протокол DCERPC.

Поэтому для проверки гипотезы нужно исследовать DCERPC-запросы. Покажем, как это можно сделать при помощи анализа трафика и SIEM-системы. На рис. 4 представлены все отфильтрованные сетевые взаимодействия по протоколу DCERPC. Для примера мы выбрали промежуток времени с 06:58 до 12:58.



Рисунок 4. Отфильтрованные DCERPC-сессии

На рис. 4 мы видим два дашборда. Слева перечислены узлы, которые выступали инициаторами DCERPC-соединений. Справа перечислены узлы, с которыми соединялись клиенты. Из рисунка видно, что все клиенты в сети обращаются только к контроллеру домена. Это легитимная активность, поскольку хосты, объединенные в домен Active Directory, обращаются по протоколу DCERPC к контроллеру домена для синхронизации. Она считалась бы подозрительной в случае такой коммуникации между пользовательскими хостами.

Поскольку ничего подозрительного за выбранный промежуток времени не выявлено, двигаясь по временной шкале, выбираем следующие 4 часа. Теперь это интервал с 12:59 по 16:46. В нем мы заметили странное изменение списка хостов назначения (см. рис. 5).



Рисунок 5. После изменения временного интервала, в списке серверов появились два новых узла

В списке хостов назначения два новых узла. Рассмотрим тот, который без DNS-имени (10.125.4.16).



Рисунок 6. Уточнение фильтра, чтобы узнать, кто подключался к 10.125.4.16

Как видно из рис. 6, к нему обращается контроллер домена 10.125.2.36 (см. рис. 4), а значит, такое взаимодействие легитимно.

Далее нужно проанализировать, кто соединялся со вторым новым узлом, на рис. 5 это win-admin-01.ptlab.ru (10.125.3.10). Из названия узла следует, что это компьютер администратора. После уточнения фильтра, остаются только два узла источника сессий.



Рисунок 7. Уточнение фильтра, чтобы узнать, кто подключался к win-admin-01

Аналогично предыдущему случаю одним из инициаторов выступил контроллер домена. Подобные сессии не вызывают подозрений, поскольку это обычное явление в среде Active Directory. Однако второй узел (w-user-01.ptlab.ru), судя по названию, пользовательский компьютер такие подключения являются аномалиями. Если с данным фильтром перейти на вкладку Сессии, то можно скачать трафик и посмотреть подробности в Wireshark.



Рисунок 8. Скачивание релевантных сессий

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



Рисунок 9. Обращение к интерфейсу IWbemServices (Wireshark)

Причем передаваемые вызовы зашифрованы, поэтому конкретные команды неизвестны.



Рисунок 10. Трафик DCERPC зашифрован, поэтому не видно передаваемой команды (Wireshark)

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

В интерфейсе SIEM мы ввели в фильтр условие, которое оставило только логи целевого узла в момент установления DCERPC-подключения, и увидели такую картину:



Рисунок 11. Системные логи win-admin-01 в момент установления DCERPC-соединения

В логах мы увидели точное совпадение со временем начала первой сессии (см. рис. 9), инициатор подключения хост w-user-01. Дальнейший анализ логов показывает, что подключились под учетной записью PTLAB\Admin и запустили команду (см. рис. 12) создания пользователя john с паролем password!!!: net user john password!!! /add.



Рисунок 12. Выполненная команда во время соединения

Мы выяснили, что с узла 10.125.3.10 некто по WMI от имени учетной записи PTLAB\Admin добавил нового пользователя на хост win-admin-01.ptlab.ru. При проведении реального TH на следующем шаге нужно выяснить, не является ли это административной активностью. Для этого нужно обратиться к владельцу аккаунта PTLAB\Admin и узнать, осуществлял ли он описанные действия. Поскольку рассматриваемый пример синтетический, будем считать, что данная активность нелегитимная. Также при проведении реального TН в случае выявления факта неправомерного использования учетной записи нужно создать инцидент и проводить детальное расследование.

Гипотеза 2: злоумышленник проник в сеть и находится на стадии эксфильтрации данных, для вывода данных использует туннелирование трафика.

Туннелирование трафика организация канала таким образом, чтобы пакеты одного сетевого протокола (возможно, в измененном виде) передавались внутри полей другого сетевого протокола. Стандартный пример туннелирования построение шифрованных каналов, например SSH. Шифрованные каналы обеспечивают конфиденциальность передаваемой информации и распространены в современных корпоративных сетях. Однако существуют экзотические варианты, например ICMP- или DNS-туннели. Такие туннели используются злоумышленниками, чтобы замаскировать свою активность под легитимную.

Начнем с поиска наиболее распространенного способа туннелирования трафика через протокол SSH. Для этого отфильтруем все сессии по протоколу SSH:



Рисунок 13. Поиск в трафике DNS-сессий

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

Если отфильтровать трафик по DNS, то можно увидеть, что у одного из узлов аномально большое количество DNS-запросов.



Рисунок 14. Виджет со статистикой сессий DNS-клиентов

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



Рисунок 15. Поиск в трафике SSH-сессий

Если перейти во вкладку Сессии, то можно увидеть, что передается в запросах к подозрительному серверу. Время между запросами достаточно маленькое, а самих сессий много. Такие параметры нехарактерны для легитимного DNS-трафика.



Рисунок 16. Параметры DNS-трафика

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



Рисунок 17. Подозрительный запрос DNS-записи

Анализ трафика показал, что на узле win-admin-01 происходит подозрительная активность по отправке DNS-запросов. Самое время проанализировать логи сетевого узла источника данной активности. Для этого переходим в SIEM.

Нужно найти системные логи win-admin-01 и посмотреть, что происходило в районе 17:06. Видно, что в то же время выполнялся подозрительный PowerShell-скрипт.



Рисунок 18. Исполнение PowerShell в то же время, что и отправка подозрительных запросов

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



Рисунок 19. Фиксация в логах имени запущенного скрипта

Название исполненного скрипта admin_script.ps1 намекает на легитимность, но администраторы обычно дают название скриптам по конкретной функции, а тут имя общее. Более того, скрипт находится в папке для временных файлов. Маловероятно, что важный административный скрипт окажется в папке, которую в любой момент могут очистить.

Среди событий обнаружили создание необычного криптографического класса из библиотеки Logos.Utility. Эта библиотека встречается редко и уже не поддерживается разработчиком, поэтому создание ее классов необычно. Попробуем найти проекты, которые ее используют.



Рисунок 20. Создание нестандартного криптографического класса

Если воспользоваться поиском, можно второй же ссылкой найти утилиту, которая организует DNS-туннель и использует данный класс.



Рисунок 21. Поиск информации о скрипте по названию класса

Чтобы окончательно убедиться в том, что это нужная нам утилита, поищем в логах дополнительные признаки. Так обнаружились доказательства. Первое запуск утилиты nslookup с помощью скрипта.



Рисунок 22. Запуск скриптом утилиты nslookup

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



Рисунок 23. Код запуска утилиты nslookup (GitHub)

Второе доказательство достаточно уникальная строка генерации случайных значений.



Рисунок 24. Генерация скриптом случайных значений

Если воспользоваться поиском по исходным кодам, можно увидеть именно эту строку.



Рисунок 25. Код генерации случайного значения

Гипотеза о туннеле подтвердилась, однако осталось неясной суть выполняемых действий. В ходе последующего анализа логов мы заметили два запуска процессов.



Рисунок 26. Поиск офисных документов для дальнейшей эксфильтрации

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

Выводы


Как показывают последние аналитические отчеты, среднее время присутствия злоумышленников в инфраструктуре остается длительным. Поэтому не ждите сигналов от средств автоматизированной защиты действуйте проактивно. Изучайте свою инфраструктуру и современные методы атак, а также используйте исследования, которые проводят TI-команды (FireEye, Cisco, PT Expert Security Center).

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

В этом помогут следующие советы:

  1. Изучайте свою инфраструктуру. Выберите для себя удобный подход к управлению сетевыми активами. Нужно в любой момент быть готовым дать ответ на вопрос о том, какую функцию выполняет тот или иной узел и дать по нему информацию.
  2. Определите наиболее важные риски и периодически проверяйте гипотезы по ним. Сети бывают разных размеров, для больших и распределенных инфраструктур очень важно выделить критически значимые узлы.
  3. Следите за последними трендами в сфере ИБ. В частности, будьте готовы реагировать на свежие уязвимости и новые методы атак. Периодически проверяйте свои средства защиты на возможность отражения новой угрозы. Если угроза не была выявлена, сделайте из данной атаки гипотезу для TH и проверяйте ее, пока автоматизированные средства защиты не начнут ее выявлять.
  4. Автоматизируйте рутинные задачи, чтобы осталось больше времени на применение творческого подхода и апробации нестандартных решений.
  5. Упрощайте процесс анализа большого объема данных. Для этого полезно использовать инструменты, которые помогают аналитику увидеть происходящее в сети и на сетевых узлах как единую картину. Среди таких инструментов платформа для обмена TI-индикаторами, система анализа трафика и SIEM-система.

Автор: Антон Кутепов, специалист экспертного центра безопасности (PT Expert Security Center) Positive Technologies.

Весь разбор проводился в системе анализа трафика PT Network Attack Discovery и системе управления событиями безопасности MaxPatrol SIEM.
Подробнее..

Анастасия Тихонова Нам крупно повезло, что атаки APT пока еще не привели к массовым человеческим жертвам

02.03.2021 18:23:53 | Автор: admin


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

Профайл:
Имя: Анастасия Тихонова.
Должность: Руководитель отдела исследования сложных киберугроз Департамента Threat Intelligence Group-IB.
Профессия: Threat Intelligence & Attribution Analyst.
Возраст: 29 лет.
Специализация: Киберразведка.
Чем известна: Более 9 лет работает в сфере информационной безопасности, последние четыре года исследует прогосударственные хакерские группы (APT).


С чем я имею дело: APT, киберармии, шпионаж и диверсии



Прямо сейчас мы все являемся свидетелями глобальной гонки кибервооружений разработки нового цифрового оружия, использования уязвимостей нулевого дня (0-day), тестирований новых средств доставки и распространения вредоносных программ. Свои киберармии есть у Китая, Северной Кореи, у США, у Ирана, и в эту гонку включились Турция, Индия, Казахстан, страны из Южной Америки. Я уже более трех лет, с 2017 года, изучаю APT (Advanced Persistent Threat) сложные целевые угрозы, атаки спецслужб или, как их еще называют, прогосударственные хакерские группы и вижу, как каждый год появляется 4-5 новых групп. Сейчас в мире действую более 70 групп, не считая тех, кто временно залег на дно или тех, кто пока еще действует скрыто. Цель большинства APT кибершпионаж, в меньшей степени саботаж и диверсии. Хотя есть и исключения в лице северокорейской группы Lazarus и многочисленных китайских APT, которые, атакуют криптовалютные биржи, банки и разработчиков компьютерных игр, чтобы заработать.

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

Любая кибератака, независимо от мотива, который преследуют хакеры это преступление и нарушение законодательства. Недавняя атака в Майами (Флорида) на АСУ ТП водоочистной системы это история с удаленным входом на компьютер. На машину был установлен TeamViewer, для того, чтобы сотрудники могли что-то удаленно контролировать. Аккаунт был запаролен, но злоумышленник смог подобрать пароль. Он логинился два раза, и во второй раз изменил количественное соотношение гидроокисида натрия в настройках интерфейса на такое, которое могло бы потенциально нанести существенный ущерб здоровью людей. Сотрудник компании, увидев это, тут же изменил настройки обратно на безопасные. И это не сюжет из киберпанк-сериала. В позапрошлом году северокорейским хакерам удалось добиться остановки энергоблоков на АЭС Куданкулам в Индии, предположительно скомпрометировав рабочую станцию довольно высокоуровневого сотрудника. В 2020 году в Израиле атакующим также удалось получить доступ к системам очистки воды и они даже удаленно пытались изменить уровень содержания хлора, что вызвало бы волну отравлений. Нам крупно повезло, что атаки APT пока еще не привели к массовым человеческим жертвам.

Крупные APT-группировки являются трендсеттерами тактики и процедуры, которые они используют в своих атаках, берет на вооружение и обычный киберкриминал. Например, после использования в 2017 году шифровальщиков WannaCry, BadRabbit и NotPetya прогосударственными группами, мир захлестнула настоящая эпидемия криминальных атак ransomware с их помощью можно заработать не меньше, чем в случае успешнои атаки на банк, при том, что техническое исполнение и стоимость атаки значительно проще. Даже такие классические финансово мотивированные преступные группы как Cobalt и Silence, раньше атаковавшие банки для хищения и вывода денег, переключились на использование шифровальщиков и стали участниками приватных партнерских программ. По нашим оценкам, ущерб от атак шифровальщиков а их было около 2000 за прошлый год составил как минимум $1 млрд. И это по самым скромным подсчетам.

Немного личного: как я пришла в профессию и о тонкостях Threat Intelligence


Мне кажется, что в инфобез я попала не случайно. В детстве я хотела стать полицейским. А в 10 классе пыталась поступить в Академию ФСБ я из семьи военнослужащих. До Group-IB я год проработала в антивирусной компании, и уже там часто замечала в прессе новости про Group-IB: выпустили новое исследование, провели расследование, участвовали в задержании. В то время на рынке ИБ-компаний было совсем немного игроков, и уже тогда Group-IB выделялась своей нетерпимостью к киберпреступности, ставкой на технологии, и мне стало интересно, узнать, какие возможности для развития здесь есть. Когда я пришла в 2013 году в Group-IB, наш департамент Threat Intelligence назывался просто отделом аналитики, и мы занимались абсолютно разными вопросами: от исследований хактивистов до помощи отделу расследований с идентификацией хакеров и установлением их личностей. За семь лет наш отдел из трех человек вырос до департамента Киберразведки с более чем тридцатью сотрудниками.

Киберразведка бывает разная. Сейчас очень часто Threat Intelligence и рынок TI-инструментов сводится к отправке клиентов банальных черных списков списка плохих адресов, плохих доменов. Для нас, в Group-IB, Threat Intelligence & Attribution это знание об атакующих, нам уже недостаточно просто анализировать угрозы. Как говорит наш CTO Дима Волков, когда вы сталкиваетесь с реальнои угрозой, вам нужен ответ на один из важных вопросов: кто вас атакует и с помощью чего? Кроме этих данных, мы даем клиентам инструменты для работы, ну и предоставляем наш собственныи сервис, которыи перекладывает часть активных задач на плечи наших специалистов, которые уже обладают необходимым опытом и навыками. Многое теперь делает за нас машинный интеллект и автоматизированные системы. Но это не отменяет тонкую ручную работу.

Одно из моих первых больших исследований было на тему атак на Россию хакеров, которые поддерживают ИГИЛ. Об этом тогда Forbes писал: Хакеры-исламисты из группировок Global Islamic Caliphate, Team System Dz, FallaGa Team атаковали около 600 российских сайтов госведомств и частных компаний. Мы тогда ещё в полу-ручном режиме получали доступ к андеграунду: я заходила на хакерские форумы, регистрировалась, собирала различную полезную информацию и данные для киберразведки (Threat Intelligence), и на их основе делала отчеты для наших клиентов. В какой-то момент мне стало просто скучно уже заниматься андеграундом, захотелось задачек посложнее и мой руководитель, Дмитрий Волков, CTO Group-IB, предложил сделать исследование про одну из китайских APT. С этого все и началось.



В моей работе нужно быстро шевелить мозгами, руками да вообще шевелиться. За один день у нас может быть исследование атак прогосударственных группировок из Китая, потом ты видишь, как прилетела сработка на правило детекта по нигерийцам (недавно была совместная операция с Interpol), а к вечеру вообще окажется, что кто-то DDOS-ит клиента от имени российских хакеров

Девушка в инфобезе? Ну да, и что? Терпеть не могу такие вопросы. Как говорится, talent has no gender. Не важно какого ты пола, ты можешь быть отличным аналитиком, рессерчером, а можешь и не быть им)).

Работа как она есть: немножко внутрянки



Мой обычный день начинается с чашки кофе и твиттера. У меня неплохая база подписок там и исследователи, и журналисты, на кого я подписана, и кто подписан на меня. В этой соцсети инфобез обменивается данными о различных атаках, отчётами вендоров. Например, очень интересные расследования делает сейчас корейская компания ESRC. Еще я подписана на парочку профильных телеграм-каналов по APT. Здесь комьюнити работает очень четко: если один исследователь нашел управляющий сервер хакерской группы и сбросил данные в телеграм-канал, ему помогают доисследовать и скидывают информацию по этому кейсу. Любая вброшенная тема про APT обычно очень быстро обрастает интересными подробностями, а вот к киберкрайму и фишингу интерес не такой повышенный. Ну может быть за исключением популярного ransomware.

Работа над любым кейсом начинается с аналитики. Как правило, перед тем, как я начну ресерч, у меня уже есть пул информации: как нашей, так и чужой (от других вендоров или аналитиков). Я начинаю раскручивать обнаруженные идикаторы: хеши троянов, вредоносных документов, домены, ссылки и так далее, которые использовались, и тестирую все это на возможность дополнения этих индикаторов нашими данными, которые ещё никто не видел, такое часто бывает. Мои рабочие инструменты наши разработки Threat Intelligence & Attribution, сетевой граф Group-IB с их помощью я довольно быстро нахожу дополнительные индикаторы компрометации и отправляю их в виде оповещения для клиента. Благодаря этому у клиентов есть возможность предотвратить атаку и заблокировать нежелательную активность.


На фото: пример исследования инфраструктуры группы с использованием сетевого графа Group-IB


У нас есть исторические связи групп и хакеров в комьюнити, данные киберпреступников за несколько лет. Это ценные данные почта, телефоны, мессенджеры, база доменов и IP, данные, связанные с рассылками вредоносных программ. Например, в базе Group-IB TI&A, все домены, когда-либо используемые злоумышленниками с историей их изменений за 17 лет. Мы можем говорить о специфике, почерке каждой отдельной преступной группы. Мы знаем, что одна группа использует одни и те же сервера, или регистрирует доменные имена у двух любимых провайдеров. Все эти данные мы загружаем в External Threat Hunting системы Group-IB и получаем на выходе то, что сейчас можно называть эффективный threat hunting.

Все, даже очень умные киберпреступники, совершают ошибки. Бывает так, что ты долго сидишь, мониторишь персонажа, пытаешься найти какие-то дополнительные аккаунты и так далее, и не можешь найти. А потом вдруг видишь, что он на выложенном в интернет скриншоте или старом фотоснимке указал свою личную почту. Приходится копать глубже, deeper analysis. Ты уже начинаешь искать дополнительные аккаунты, людей, которые могли с ним взаимодействовать, если вычисляешь конкретный город, получаешь уже больше информации, иногда бывает, что ты уже знаешь улицу. Что может быть подсказкой? Это может быть фотография из соцсетей, или фотография в инсте его девушки, нет девушки ищи в тиндере и так далее проще говоря OSINT, разведка на основе открытых источников. Этим инструментом обладают все технические подразделения Group-IB, но у каждого свой OSINT.

Нас исследуют тоже. Вы думаете нас, Group-IB, не пытались атаковать? Мы противостоим самой настоящей киберпреступности, нам пытаются угрожать, приветы присылали. Не как Кребсу, конечно, другие приветы, чаще с ВПО.

В конечном итоге вся моя аналитика нужна для того, чтобы предотвращать киберпреступления. Это кажется научной фантастикой, но мы можем предсказывать атаки еще до того, как хакеры и APT совершают их. Еще на этапе подготовки инфраструктуры мы выявляем атаки и предупреждаем клиентов. Кроме того, данные Threat Intelligence & Attribution обогащаются информацией из darkweb, с подпольных хакерских форумов и используются в других наших решениях, позволяя аналитикам увидеть наиболее полную картину угроз и атрибутировать преступную деятельность с предельной точностью.



От Кореи до Карелии: ландшафт APT


Если сравнивать разные APT, то инженерный оргазм по меткому выражению нашего босса Ильи Сачкова я испытываю от северокорейских групп. Мне нравится их подход они вдумчиво и нестандартно подходят к своей работе. Например, на этапе разведки и пробива проводят супер-реальные собеседования с кандидатами, играют вдолгую, не вызывая подозрений. Плюс у них, действительно есть интересные инструменты, которые они постоянно развивают. Изначально они начинали с классического кибершпионажа против Южной Кореи и США, со временем стали универсальными солдатами, способными похитить деньги, ценную информацию или устроить диверсию. Из года в год такие северокорейские группировки как Lazarus и Kimsuky показывают стабильное развитие методов атак и своих инструментов. В прошлом году большое количество атак северокорейских хакеров были направлены на военных подрядчиков по всему миру. Об этом писал Коммерсант, может вы читаете такую прессу:)

В Северной Корее, по моему мнению, есть крупная корневая группировка Lazarus, у которой, в подчинении есть разные команды, например, Андариэль, для решения различных непрофильных задач. Кстати, оба названия этих северокорейских APT взяты исследователями из популярной компьютерной игры Diablo.

В Иране вербовка сотрудников в APT-группы происходит прямо со студенческой скамьи. Как-то раз мы опубликовали на Хабре статью про иранских хакеров, где в документах оказалась написаны имя и фамилия одного из фигурантов. Мы сначала сомневались мало ли, чье имя вписано. Однако, оказалось, что когда-то давно была засвечена его почта на хакерских ресурсах, что нас довольно сильно заинтересовало. Распутав всё это мы нашли очень много различных аккаунтов на форумах, которые посвящены обучению использования уязвимостей, что еще больше нас убедило в том, что именно этот человек блэчер, занимается хакингом. Когда мы опубликовали свои находки, он отписался в твиттере в таком духе Почему вы так просто обвиняете людей, мало ли, человека могли подставить, либо он оступился?. Через какое-то время он сам удалил это сообщение: оно обличало его с головой.

Мы не слышим про американские APT, но это не значит, что их нет. Американские группы есть, просто о них почти ничего нет. Зачем тебе много мелких APT-групп, если у тебя есть одна хорошо организованная, которая работает по задачам и шпионит за другими? Риторический вопрос. В США всё тесно связано с АНБ, то есть вот у них, я бы сказала, довольно большая сеть с вот этими 0-day и прочими уязвимостями, инструментами. То, что выложил WikiLeaks это малая часть того, что есть у АНБ.

Русские хакеры, которые работают на государство, это сейчас очень модная и хайповая на западе тема. Хакерские атаки в прессе часто привязывают к той или иной стране, исходя из напряженной политической ситуации Россия vs США, Израиль vs Иран, Северная Корея vs Южная Корея, а не на основе реальных технических данных, однозначно указывающие на ту или иную группировку. Не будем забывать о том, что группы часто используют ложные флаги, и пытаются запутать следы. Например, так делал Lazarus. Вообще русский хакер это что-то уже из конца 90-х. Нет никаких русских, есть русскоязычные выходцы из стран постсветского пространства. Да и русские хакеры самые крутые тоже уже не так: группы перемешаны и состоят из людей разных национальностей.



Не надо думать, что все просто. APT часто пытаются запутать следы, выбрасывают ложные флаги и переводят стрелки друг на друга. Те же иранские MuddyWater начинали с того, что пытались подделаться под Fin7. Если, как в случае с Lazarus, выйти на конкретные айпишники, которые принадлежат Северной Корее, то после этого можно делать заявление о том, что это Северная Корея. И так делают некоторые вендоры. А так ты можешь смотреть только на цели, которые атаковались, смотреть на инфраструктуру, откуда она была взята, и на манеру каких-нибудь комментариев в написании кода, и так далее. Если была атака в Южно-Китайском море, ты можешь предположить, что замешаны страны, интересы которых связаны с этим регионом. И дальше уже начинаешь разбираться, что за инструменты использовались: раз это троян PlugX, то скорее всего, это точно Китай. И дальше мы доходим до инфраструктуры, оказывается, что это, действительно, китайские айпишники.

Секреты мастерства и список книг для прокачки


В собственном саморазвитии потолка нет. Я бы хотела поработать в Европе и Азии, потому что там было бы больше шансов обмена опытом с другими специалистами инфобеза, начинаешь понимать менталитет и лучше представлять как бы APT могли работать конкретно в этом регионе. Думаю, что это будет несложно сделать. В позапрошлом году Group-IB открыла глобальную штаб-квартиру в Сингапуре, а в прошлом европейскую штаб-квартру в Амстердаме. Поскольку инструменты развиваются, а APT-группы не исчезнут никогда работа у меня будет всегда. Тем более будет востребована моя профессия.

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

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

  1. Нестареющая классика от ветерана ЦРУ Ричардса Хойера ( Richards Heuer) Psychology of Intelligence Analysis, которая описывает особенности нашего мышления, ошибки и ограничения (когнитивные предубеждения), которые генерирует наш мозг. Например, для распознавания неожиданного явления требуется больше однозначной информации, чем для ожидаемого: We tend to perceive what we expect to perceive.
  2. О базовых принципах и концепциях Cyber Threat Intelligence можно узнать из издания Threat Intelligence: Collecting, Analysing, Evaluating by David Chismon, Martyn Ruks from MWR InfoSecurity.
  3. Для тех, кто хочет не только в Cyber Threat Intelligence, но и более конкретно разбираться в теме с APT, есть хорошая книга Attribution of Advanced Persistent Threats: How to Identify the Actors Behind Cyber-Espionage by Timo Steffens. В ней изложен предметный анализ того, как действуют хакеры, какие ошибки они совершают и какие следы оставляют.
  4. Kill Chain, Diamond Model и MITRE ATT&CK три кита, на которых должны базироваться знания любого аналитика Cyber Threat Intelligence, в связи этим рекомендую три книги: MITRE ATT&CK: Design and Philosophy с подробным объяснением того, для чего вообще создавался и служит ATT&CK, как происходит его обновление и как его использует сообщество. Обязательно загляните и на сайт MITRE ATT&CK, где уже можно ознакомиться с описанием некоторых групп и их возможностей.
  5. Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains by Eric Hutchins, Michael Cloppert, and Rohan Amin кроме описания самой модели Kill Chain, тут можно встретить примеры, которые также будут полезны для начинающих аналитиков.
  6. The Diamond Model of Intrusion Analysis by Sergio Caltagirone, Andrew Pendergast, and Chris Betz довольно простая, но полезная книга для понимания основ CTI.
  7. Большой репозиторий с разными исследованиями, которые выпускались вендорами ИБ, можно найти в APTNotes. Обновляется, к сожалению, нечасто, но там можно обнаружить большие интересные кейсы с описанием, как проводился анализ того, как делали атрибуцию, как действуют злоумышленники.
  8. Ну и конечно загляните к нам в блог, и почитайте исследования наших специалистов на русском языке и на английском


Как стать Threat Intelligence & Attribution Analyst?





Для тех, кто заинтересовался профессией Threat Intelligence & Attribution Analyst наша компания готова предложить практический курс по сбору информации о киберугрозах и обогащению процессов кибербезопасности данными TI для эффективного реагирования на инциденты и мониторинга угроз.


Цель курса Group-IB Threat Intelligence & Attribution Analyst научить вас собирать значимую информацию из разных типов источников как открытых, так и закрытых, толковать эту информацию и выявлять признаки подготовки к атаке. Занятия по программе включают в себя практические упражнения на основе примеров из рабочей практики Департамента киберразведки Group-IB. Такой подход важен для того, чтобы слушатели могли сразу применять полученные знания в своей ежедневной практике.

Работа, которая имеет смысл!


И еще одно важное объявление. Group-IB усиливает команду технических специалистов: стань частью команды и меняй мир вместе с нами! Сейчас открыто 120+ вакансий, в том числе 60 для технических специалистов. Подробности тут. Group-IB это новое поколение инженеров. Мы воплощаем смелые идеи, создавая инновационные технологии для расследования киберпреступлений, предотвращения кибератак, слежения за атакующими, их тактикой, инструментами и инфраструктурой. Присоединяйся!
Подробнее..

Threat Intelligence по полочкам разбираемся в стандартах обмена данными

21.04.2021 12:06:56 | Автор: admin

Подходы к обмену данными об угрозах находятся в активной фазе формирования и стандартизации. Сегодня есть пара значимых стандартов MISP и STIX и целая плеяда менее значимых, которые реже используются или считаются legacy/deprecated: MAEC, IODEF, OpenIOC (Cybox), CAPEC, IODEF, VERIS и множество иных. При этом порядочное количество community-фидов до сих пор распространяется в виде txt или csv, а также в виде человекочитаемых аналитических сводок, бюллетеней и отчетов.

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

Формат STIX

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

  • Выразительность

  • Гибкость

  • Расширяемость

  • Автоматизируемость

  • Читаемость

Над STIX идет активная работа, регулярно выпускаются новые редакции. Стандарт поддерживает организация OASIS, её комитет по cyber threat intelligence объединяет более 50 компаний, собаку съевших на работе с TI. Поэтому развитие стандарта это путь обобщения лучших практик, ошибок и выводов, которые были сделаны опытными специалистами в этой области.

STIX является языком описания для обмена данными TI и вводит набор сущностей, а также определяет возможные типы взаимосвязей между ними. Стандарт довольно объемный, поэтому в этой статье я не буду погружаться во все его детали.

Согласно спецификации, STIX заявлен как serialize-agnostic, однако на практике чаще всего используется формат JSON, схемы находятся в публичном репозитории на GitHub. Транспорт для STIX тоже может быть любым, но OASIS позаботился и об этом: параллельно со STIX развивается стандарт для транспорта TAXII, который использует HTTPS как фундамент.

STIX описывает данные об угрозах как связный граф, где узлами являются SDO (STIX Domain Objects), а ребрами SRO (STIX Relationship objects).

В качестве SDO STIX определяет следующие сущности:

  1. Схема атаки (Attack pattern) описывает подход (TTP), который использовал злоумышленник для взлома своей цели. Эта сущность используется для классификации атак, обобщения конкретных атак в соответствии со схемами, которым они следуют, и предоставления подробной информации о том, как атаки выполняются.

  2. Вредоносная кампания (Campaign) описывает последовательность вредоносных поведенческих признаков, которые возникают на протяжении определенных промежутков времени.

  3. План действий (Course of action) описывает меры, которые нужно принять, чтобы избежать или противостоять атаке.

  4. Личность (Identity) описывает персоны, организации либо их группы.

  5. Индикатор (Indicator) описывает технические вредоносные артефакты, которые могут быть использованы для обнаружения вредоносной активности (например, IP-адреса, домены, хеши, ключи реестра).

  6. Intrusion set описывает набор поведенческих признаков и ресурсов с общими свойствами, которые, вероятней всего, подконтрольны одной организации. Ключевое отличие от Campaign в том, что последняя обычно представляет собой вредоносную активность, направленную на конкретную цель и длится в течение ограниченного промежутка времени, тогда как Intrusion set длится продолжительное время, может участвовать в нескольких Campaigns и иметь несколько целей.

  7. Вредоносное ПО (Malware) описывает экземпляры вредоносного ПО.

  8. Объект наблюдения (Observed data) описывает не вредоносные технические артефакты.

  9. Отчет (Report) описывает в понятном виде какую-либо угрозу, вредоносную группировку, их TTP, жертв. Своего рода аналитическая сводка, позволяющая понять суть угрозы, ее опасность, вредоносное ПО, используемые техники, тактики и процедуры, применяемые атакующей стороной.

  10. Злоумышленник (Threat actor) описывает персон, группы или организации, которые действуют со злым умыслом. Если коротко, злоумышленники и хакеры. Именно злой умысел в мотивации этой сущности отличает ее от Identity.

  11. Инструмент (Tool) описывает легитимное ПО, которое может быть использовано для осуществления атак. Отличие этой сущности от Malware именно в том, что это легитимный софт, например, nmap или RDP, VNC.

  12. Уязвимость (Vulnerability) описывает недостатки/дырки в требованиях, логике, дизайне, реализации ПО или железа, которые могут быть проэксплуатированы и негативно повлиять на конфиденциальность, целостность или доступность системы.

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

Пример 1

Здесь описывается индикатор компрометации http://x4z9arb.cn/4712/ типа URL и его связь (атрибуция) с вредоносным ПО x4z9arb backdoor. При этом явно видно, что индикатор это сайт, на котором располагается вредоносный загрузчик (downloader), в данном случае вредонос x4z9arb backdoor.

Что это значит для аналитика? Все довольно просто: если мы обнаружим следы присутствия (индикатор компрометации http://x4z9arb.cn/4712/) в инфраструктуре компании, то можем сделать вывод, что имеем дело с вредоносным ПО x4z9arb backdoor. Дальнейшие шаги обычно зависят от вредоносности ПО, попавшего внутрь инфраструктуры. Для его анализа существует множество баз, например, Malpedia.

Пример STIX 2.1
{"type": "bundle","id": "bundle--56be2a3b-1534-4bef-8fe9-602926274089","objects": [{"type": "indicator","spec_version": "2.1","id": "indicator--d81f86b9-975b-4c0b-875e-810c5ad45a4f","created": "2014-06-29T13:49:37.079Z","modified": "2014-06-29T13:49:37.079Z","name": "Malicious site hosting downloader","description": "This organized threat actor group operates to create profit from all types of crime.","indicator_types": ["malicious-activity"],"pattern": "[url:value = 'http://x4z9arb.cn/4712/']","pattern_type": "stix","valid_from": "2014-06-29T13:49:37.079Z"},{"type": "malware","spec_version": "2.1","id": "malware--162d917e-766f-4611-b5d6-652791454fca","created": "2014-06-30T09:15:17.182Z","modified": "2014-06-30T09:15:17.182Z","name": "x4z9arb backdoor","description": "This malware attempts to download remote files after establishing a foothold as a backdoor.","malware_types": ["backdoor","remote-access-trojan"],"is_family": false,"kill_chain_phases": [{"kill_chain_name": "mandiant-attack-lifecycle-model","phase_name": "establish-foothold"}]},{"type": "relationship","spec_version": "2.1","id": "relationship--864af2ea-46f9-4d23-b3a2-1c2adf81c265","created": "2020-02-29T18:03:58.029Z","modified": "2020-02-29T18:03:58.029Z","relationship_type": "indicates","source_ref": "indicator--d81f86b9-975b-4c0b-875e-810c5ad45a4f","target_ref": "malware--162d917e-766f-4611-b5d6-652791454fca"}]}

Пример 2

Тут явно описаны связи между злоумышленником Adversary Bravo, используемой им техникой атаки фишингом и вредоносным ПО Poison Ivy Variant d1c6.

В этом случае при обнаружении в инфраструктуре вредоносного ПО PoisonIvy вариант d1с6 такая структура фида с взаимосвязями поможет понять, что подобным вредоносным ПО пользуется злоумышленник.

Пример STIX 2.1
{"type": "bundle","id": "bundle--0ecd8123-90d5-46e0-9cd4-65d4999b3a2e","objects": [{"type": "threat-actor","spec_version": "2.1","id": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","created": "2015-05-07T14:22:14.760Z","modified": "2015-05-07T14:22:14.760Z","name": "Adversary Bravo","description": "Adversary Bravo is known to use phishing attacks to deliver remote access malware to the targets.","threat_actor_types": ["spy","criminal"]},{"type": "malware","spec_version": "2.1","id": "malware--d1c612bc-146f-4b65-b7b0-9a54a14150a4","created": "2015-04-23T11:12:34.760Z","modified": "2015-04-23T11:12:34.760Z","name": "Poison Ivy Variant d1c6","malware_types": ["remote-access-trojan"],"is_family": false,"kill_chain_phases": [{"kill_chain_name": "mandiant-attack-lifecycle-model","phase_name": "initial-compromise"}]},{"type": "attack-pattern","spec_version": "2.1","id": "attack-pattern--8ac90ff3-ecf8-4835-95b8-6aea6a623df5","created": "2015-05-07T14:22:14.760Z","modified": "2015-05-07T14:22:14.760Z","name": "Phishing","description": "Spear phishing used as a delivery mechanism for malware.","kill_chain_phases": [{"kill_chain_name": "mandiant-attack-lifecycle-model","phase_name": "initial-compromise"}],"external_references": [{"source_name": "capec","description": "phishing","url": "https://capec.mitre.org/data/definitions/98.html","external_id": "CAPEC-98"}]},{"type": "identity","spec_version": "2.1","id": "identity--1621d4d4-b67d-41e3-9670-f01faf20d111","created": "2015-05-10T16:27:17.760Z","modified": "2015-05-10T16:27:17.760Z","name": "Adversary Bravo","description": "Adversary Bravo is a threat actor that utilizes phishing attacks.","identity_class": "unknown"},{"type": "relationship","spec_version": "2.1","id": "relationship--d44019b6-b8f7-4cb3-837e-7fd3c5724b87","created": "2020-02-29T18:18:08.661Z","modified": "2020-02-29T18:18:08.661Z","relationship_type": "uses","source_ref": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","target_ref": "malware--d1c612bc-146f-4b65-b7b0-9a54a14150a4"},{"type": "relationship","spec_version": "2.1","id": "relationship--3cd2d6f9-0ded-486b-8dca-606283a8997f","created": "2020-02-29T18:18:08.661Z","modified": "2020-02-29T18:18:08.661Z","relationship_type": "uses","source_ref": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","target_ref": "attack-pattern--8ac90ff3-ecf8-4835-95b8-6aea6a623df5"},{"type": "relationship","spec_version": "2.1","id": "relationship--56e5f1c8-08f3-4e24-9e8e-f87d844672ec","created": "2020-02-29T18:18:08.661Z","modified": "2020-02-29T18:18:08.661Z","relationship_type": "attributed-to","source_ref": "threat-actor--9a8a0d25-7636-429b-a99e-b2a73cd0f11f","target_ref": "identity--1621d4d4-b67d-41e3-9670-f01faf20d111"}]}

Приведенные примеры довольно тривиальны, но просты для понимания. Разбор сложных примеров может стать темой отдельной статьи. Однако для наглядности покажу, как можно упаковать в STIX результаты объемного исследования отчета о деятельности вредоносной группировки APT1 (ссылка на json):

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

Формат MISP

MISP популярная open-source платформа Threat Intelligence, она обросла довольно большим и активным сообществом за годы существования. Формат обмена данными с 2016 внесен в IETF в статусе internet draft, то есть метит в RFC, но пока им не стал.

Концепция платформы MISP сосредоточена в первую очередь на создании и p2p-обмене данными threat intelligence, то есть основная цель это создание и распространение знаний между различными участниками сообществ. Глубину и ширину такого распространения можно довольно гибко регулировать настройками.

Формат обмена данными MISP пошел несколько иным путем, нежели STIX. В отличие от последнего, MISP свою модель данных не делит на большое количество детерминированных объектов разных типов, тут их сравнительно немного:

  1. Событие (Event) какое-либо событие, инцидент, аналитический отчет, который повествует о чем-либо. По сути, Event это контейнер.

  2. Атрибуты события (Event attributes) чаще всего это индикаторы компрометации, разные технические артефакты. То есть Events, как в контейнерах, собирают внутри себя разные индикаторы компрометации, которые рассказывают о какой-либо одной угрозе или вредоносной кампании (либо нескольких, но семантически близких).

  3. Объект (Object) нужен для обобщения атрибутов по какому-либо признаку общности. Например, чтобы связать несколько хешей (md5, sha1. sha256) с именем файла, с которого они были сняты. Объекты можно связывать друг с другом с помощью прокси-объекта Object References.

  4. Тег (Tag) метки для классификации, могут быть как представлены в виде пользовательских строк, так и взяты из справочника MISP Taxonomies.

  5. Обнаружения (Sighting) факты о том, где, когда, при каких условиях и кем встречался конкретный атрибут.

  6. Галактика (Galaxy) связь объектов или атрибутов с контекстом, который дает более детальное описание объектов/атрибутов. По сути, это расширение функциональности тегов. Galaxies декомпозируются на Clusters (Кластеры) и Elements (Элементы). На примере это может выглядеть так: атрибут привязывается к Threat Actor (Galaxy), MuddyWater (Element) из этой связи наглядно понятна атрибуция.

Пример

Из этого примера видно, что фид рассказывает нам о двух индикаторах компрометации adfs.senate.group и adfs-senate.email, которые связаны с вредоносной кампанией Pawn Storm, есть ссылка на первоисточник исследования пост в блоге Trend Micro.

MISP Event
"Event": {"info": "Update on Pawn Storm: New Targets and Politically Motivated Campaigns","publish_timestamp": "1515851051","timestamp": "1515850537","analysis": "2","Attribute": [{"comment": "","category": "Network activity","uuid": "5a5a0b04-198c-4190-9f1a-8d1cc0a8ab16","timestamp": "1515850500","to_ids": true,"value": "adfs.senate.group","object_relation": null,"type": "hostname"},{"comment": "","category": "Network activity","uuid": "5a5a0b04-4d44-463f-81a9-8d1cc0a8ab16","timestamp": "1515850500","to_ids": true,"value": "adfs-senate.email","object_relation": null,"type": "domain"},{"comment": "","category": "External analysis","uuid": "5a5a0b22-86a4-4d66-90e4-9282c0a8ab16","timestamp": "1515850530","to_ids": false,"value": "http://blog.trendmicro.com/trendlabs-security-intelligence/update-pawn-storm-new-targets-politically-motivated-campaigns/","object_relation": null,"type": "link"}],"Tag": [{"colour": "#00d622","exportable": true,"name": "tlp:white"}],"published": true,"date": "2018-01-12","Orgc": {"uuid": "56c42374-fdb8-4544-a218-41ffc0a8ab16","name": "CUDESO"},"threat_level_id": "3","uuid": "5a5a0acb-a374-415e-b88f-8d1ec0a8ab16"}}

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

Иные форматы

Помимо STIX и MISP, больших китов в мире стандартизации обмена данными threat intelligence, есть немало иных форматов. И надо сказать, что наибольшее количество опенсорных фидов в форматах txt и csv. Редко, когда можно найти их в STIX или MISP, которые я бы назвал, скорее, уделом коммерческих, отмодерированных, обогащенных, хорошо структурированных фидов. Иные форматы (MAEC, IODEF, CAPEC, IODEF, VERIS) редкость.

Почему же стали настолько популярны txt и csv? Ответ один из-за простоты. Большинство опенсорсных фидов это либо фиды с минимальным контекстом (временные метки, именования вредоносного ПО, теги), либо просто голые индикаторы компрометации без какого-либо контекста (только значения индикаторов). Наиболее простой способ упаковки таких индикаторов plain text или csv, так как любые иные форматы имеют более высокий порог входа.

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

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

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

Примеры

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

Вот другой пример фида с однозначным и хорошим описанием понятно, какие есть атрибуты и какие между ними имеются взаимосвязи:

А вот в этом примере не понятно, к чему относится дата: к третьей колонке (URL) или к пятой (хеш)?

Еще один пример: есть две колонки с индикатором компрометации (url, ip), есть колонка с датой и непонятно, к какому из индикаторов компрометации эта дата относится, а также, что она означает. Время первого обнаружения индикатора? Время последнего обнаружения индикатора? Что-то иное?

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

За бортом обсуждения также остаются немногочисленные практики публикации фидов в устаревших форматах, например, STIX 1.*, OpenIOC и иных они действительно либо безнадежно устарели и более не используются, либо слились с другими стандартами, либо эволюционировали в более новые версии, отвечающие нынешним запросам.

Выводы

В мире threat intelligence не все так однозначно, как видится на первый взгляд. С одной стороны, сформировалось достаточно активное сообщество, которое развивает открытые стандарты, решающие вполне понятные проблемы и задачи большинства пользователей (потребителей и производителей) TI. В то же время различные производители средств защиты информации зачастую разрабатывают и используют собственные форматы, наиболее выгодные в их конкретных сценариях использования. Помимо этого, есть практика использования форматов общего назначения вроде txt, csv, rss, pdf.

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

Само по себе отсутствие стандарта отрасли это не хорошо и не плохо, просто факт. Порой он приносит определенные неудобства производителям продуктов, поставщикам и потребителям TI. Я вижу это лишь следствием того, что threat intelligence все еще сравнительно молодая область, которая представляет собой большой плавильный котел. Здесь множество требований с различных сторон еще на нашли 100% устраивающих всех реализаций, поэтому преобладает некий хаос, постепенно кристаллизующийся в лучшие практики. Полагаю, стандартизация это вопрос времени.

С точки зрения платформы TI, такая гетерогенность форматов настоящий челлендж, так как нужно собрать из многообразия источников все данные, переложить их в собственную модель, не потерять смысл и по возможности потерять минимум данных тех, что семантически не получается разместить в полях модели данных платформы. Как раз в следующей статье вместе с Колей Арефьевым из RST Cloud мы рассмотрим более подробно конкретные фиды, расскажем, какие сложности поджидают на пути их сбора, обработки и интерпретации. Stay tuned!

Другие статьи по теме

Подробнее..

Разбираемся в источниках Threat Intelligence

29.04.2021 16:13:12 | Автор: admin

Согласно отчету 2021 SANS Cyber Threat Intelligence (CTI) Survey, 66,3% компаний используют открытые источники для сбора индикаторов компрометации и стараются работать одновременно с несколькими источниками. Казалось бы, сбор индикаторов из открытых источников достаточно простая задача: надо просто скачать с какого-то сайта файлик txt или csv, и всё. В действительности на этом пути можно столкнуться с большим количеством проблем. В статье мы расскажем, что это могут быть за сложности, от чего зависят структура и формат фида, какие метрики помогают оценить полезность фидов, а также покажем на реальном примере, что можно узнать из фида. Для большей объективности эту статью мы подготовили вместе с Колей Арефьевым из компании RST Cloud, занимающейся агрегацией, обогащением, очисткой и ранжированием индикаторов, публикуемых независимыми ИБ-исследователями.

Какие подводные камни таят в себе открытые источники TI

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

Попробуем описать основные проблемы, которые необходимо будет разрешить при сборе индикаторов из открытых источников:

  1. Подбор источников.

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

  1. Понимание структуры фида.

Важно понимать, что за индикаторы компрометации приносит источник. Но зачастую еще важнее собирать не только сами индикаторы, но и связанный с ними контекст, если он есть: временные метки, атрибуцию (кто, кого, когда, зачем, почему и какими инструментами атакует?). Например, контекстом может быть информация о том, почему определенный IP, домен, url или hash попал в фид. Если это С2C, то от какого вредоносного ПО, если фишинговый url, то под какую компанию он сделан.

  1. Агрегация и дедупликация.

А что, если несколько источников данных предоставляют одну и ту же информацию об индикаторе компрометации? Дубль? А что, если противоречивую? Кому верить?

  1. Понимание изменений в источнике и актуальность данных.

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

  1. Понимание расписания обновления источников.

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

  1. Очистка индикаторов.

Встретить в открытых индикаторах 127.0.0.1, microsoft.com или SHA256 обычного calc.exe вполне нормальная ситуация. Чтобы избежать ложных срабатываний, необходимо очищать индикаторы с помощью разнообразных списков исключений.

  1. Обогащение индикаторов.

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

  1. Хранение индикаторов в средствах защиты.

Было бы просто чудесно, если бы можно было загрузить все собранные за год индикаторы в средства защиты и использовать их для проверки на потоке. К сожалению, чудеса в IT и ИБ случаются очень редко, и хранить в средствах защиты придется лишь столько индикаторов, сколько они способны обеспечить без существенной деградации производительности. Для наглядности приведем статистику RST Cloud по уникальным сетевым IoC, собранным за 365 дней.

От чего зависят структура и формат фида: ищем ответ в Пирамиде боли

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

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

Давайте вспомним Пирамиду боли, предложенную впервые в 2013 году David J Bianco.

В нижней части пирамиды лежат атомарные сетевые и хостовые индикаторы. Как правило, для их описания в фиде можно использовать плоские структуры данных, сформировав txt- или csv-фид. Для таких структур характерно отсутствие каких-либо вложенностей.

Например, фид такой структуры может выглядеть вот так:

812 | ROGERS-COMMUNICATIONS | 99.250.237.110 | 2021-04-05 04:46:22

852 | ASN852 | 66.183.170.4 | 2021-04-05 02:50:15

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.13 | 2021-03-31 19:52:48

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.14 | 2021-04-03 14:50:55

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.16 | 2021-04-05 09:45:03

1101 | IP-EEND-AS Surfnet B.V. | 192.42.116.17 | 2021-04-04 18:13:59

Или даже вот так:

Family,URL,IP,FirstSeen

Pony,http[:]//officeman[.]tk/admin.php,207[.]180.230.128,01-06-2020

Pony,http[:]//learn[.]cloudience[.]com/admin.php,192[.]145.234.108,01-06-2020

Pony,http://vman23[.]com/admin.php,95.213.204.53,01-06-2020

По мере продвижения вверх по пирамиде необходимо описывать всё более и более сложные модели данных. Такое усложнение обусловлено тем, что на более высоких уровнях недостаточно просто описать атомарный индикатор и его атрибуты. В фиде необходимо уже отражать как связки индикаторов, так и целые поведенческие паттерны вредоносных программ, техники и тактики (TTP) хакерских группировок или этапы APT.

Для описания подобных моделей становится недостаточно обычных плоских структур, и здесь уже задействуются такие форматы, как json, yaml, xml или что-то более экзотическое, построенное на их основе. Пример фида, описывающего несколько взаимосвязанных объектов в формате STIX 2, можно посмотреть в этой статье.

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

Пример: о чем можно узнать из фида

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

Сам фид состоит из json следующего вида:

{

"id": "572f891c-dd92-31d3-a2e7-c448a4b72b22",

"title": "RST Threat feed. IOC: defender5.coachwithak.com",

"description": "IOC with tags: c2. Related threats: silverfish_group",

"threat": ["silverfish_group"],

"domain": "defender5.coachwithak.com",

"fseen": 1616630400,

"lseen": 1617408000,

"collect": 1617494400,

"tags": ["c2"],

"resolved": {

"ip": {

"a": ["37.48.84.156"],

"cname": []

},

"whois": {

"created": "2019-07-31 20:36:52",

"updated": "2020-08-01 10:58:42",

"expires": "2021-07-31 20:36:52",

"age": 608,

"registrar": "GoDaddycom LLC",

"registrant": "unknown",

"havedata": "true"

}

},

"score": {

"total": 55,

"src": 73.75,

"tags": 0.89,

"frequency": 0.85

},

"fp": {

"alarm": "false",

"descr": ""

}

}

Выделим ключевую информацию об индикаторе, которую можно узнать из этого фида:

  1. GUID индикатора.

  2. Краткое описание индикатора помогает TI-аналитику быстро понять, чем опасен этот индикатор.

  3. Время первого и последнего появления индикатора.

  4. Информация об угрозе, которую несет индикатор. В данном случае домен атрибутирован с APT-группировкой SilverFish (подробнее можно ознакомиться в публичном отчете исследователей).

  5. Теги дают дополнительный контекст. В данном случае вредоносный домен используется как командный управляющий сервер (C2C).

  6. IP-адреса, в которые резолвится домен, полезны при анализе логов с сетевых устройств, где присутствуют только IP и нет информации о DNS-резолве.

  7. Whois-информация помогает TI-аналитику лучше понять, кто и когда зарегистрировал домен. Зачастую для атак регистрируют домены-однодневки, поэтому важно обращать внимание на то, когда домен зарегистрирован. В нашем примере APT-группировка подошла к вопросу выбора домена для C2C-сервера более основательно и использовала домен с более чем двухгодичным временем жизни.

  8. Вес индикатора позволяет количественно оценить опасность индикатора. К примеру, индикатор с весом 70 опаснее индикатора с весом 50, и реагировать на появление первого необходимо в первую очередь.

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

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

На какие метрики смотреть?

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

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

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

Например, можно оценить фид по динамике поступления новых данных, то есть тех индикаторов компрометации, которые фид не присылал ранее:

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

Как можно интерпретировать такую метрику? Факт постоянного получения новых данных позитивный, однако изолированная метрика достаточно неоднозначна, и следует рассматривать ее вкупе с иными метриками, чтобы увидеть картину более широко.

Давайте снова взглянем на опенсорсный фид от CIRCL.lu. Как видно из предыдущего графика, фид достаточно регулярно обновляется. Что же он собой представляет, если посмотреть более обобщенно?

За период в 3 месяца в фиде 157 852 индикатора. Видно, что фид предоставляет разные типы индикаторов компрометации.

Если посмотреть на фид CIRCL в сравнении с несколькими другими фидами, можно также оценить распределение типов индикаторов компрометации по фидам. Что может дать эта информация пользователю? Например, понимание того, как можно будет использовать такой фид. Ведь обилие хешей обычно требует интеграции с EDR-решениями, хеши довольно бессмысленно искать в потоке трафика или netflow с сетевых устройств:

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

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

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

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

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

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

Ниже приведем пару примеров. В первом примере хорошо видно, что фид CIRCL пересекается всего на 1% и 2% c digitalside и botvrj соответственно, а botvrj на 30% и 1% c CIRCL и digitalside соответственно (тут все верно, разный процент пересечения между botvrj и CIRCL получился из-за их разных размеров по количеству объектов внутри относительно друг друга).

Во втором примере справедливо видно тотальное пересечение между фидами OTX - Project TajMahal и IBM X-Force Project TajMahal. Это объясняется тем, что фиды рассказывают об одной и той же угрозе.

Вместо выводов

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

Авторы: Антон Соловей, менеджер продукта R-Vision Threat Intelligence Platform,

Николай Арефьев, сооснователь RST Cloud

Другие статьи по теме

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru