Множества данных

Корпорация Майкрософт центрирует множество наборов данных на одной платформе, Аналитика угроз Microsoft Defender (Defender TI), что упрощает для сообщества и клиентов Майкрософт проведение анализа инфраструктуры. Корпорация Майкрософт уделяет основное внимание предоставлению максимально возможного объема данных об инфраструктуре Интернета для поддержки многих вариантов использования безопасности.

Корпорация Майкрософт собирает, анализирует и индексирует интернет-данные, чтобы помочь пользователям в выполнении следующих задач:

• Обнаружение угроз и реагирование на них
• Определение приоритетов инцидентов.
• Упреждающее определение инфраструктуры, связанной с группами субъектов, нацеленными на их организацию.

Корпорация Майкрософт собирает данные в Интернете через свою сеть датчиков PDNS, глобальную прокси-сеть виртуальных пользователей, сканирует порты и использует сторонние источники для вредоносных программ и добавленных данных системы доменных имен (DNS).

Эти интернет-данные подразделяются на две отдельные группы: традиционные и расширенные. Традиционные наборы данных включают Resolutions, Whois, СЕРТИФИКАТЫ TLS, поддомены, DNS, Обратный DNS и Службы. Расширенные наборы данных включают средства отслеживания, компоненты, пары узлов и файлы cookie. Средства отслеживания, компоненты, пары узлов и наборы данных cookie собираются путем наблюдения за объектной моделью документа (DOM) просканированных веб-страниц. Кроме того, компоненты и средства отслеживания также отслеживаются из правил обнаружения, которые активируются на основе ответов баннера от сканирования портов или сведений о сертификате TLS.

Решения

Пассивный DNS (PDNS) — это система записей, которая хранит данные разрешения DNS для заданного расположения, записи и периода времени. Этот набор данных для исторического разрешения позволяет пользователям просматривать домены, разрешенные в IP-адрес, и наоборот. Этот набор данных обеспечивает корреляцию на основе времени на основе перекрытия доменов или IP-адресов. PDNS может обеспечить идентификацию ранее неизвестной или недавно созданной инфраструктуры субъекта угроз. Упреждающее добавление индикаторов в списки блокировок может отрезать коммуникационные пути до проведения кампаний. Данные разрешения записей доступны на вкладке Набор данных разрешения. На вкладке Набор данных DNS доступны дополнительные типы записей DNS.

Наши данные о разрешении PDNS содержат следующие сведения:

• Разрешение: имя разрешающей сущности (IP-адрес или домен).
• Расположение: расположение, в котором размещен IP-адрес.
• Сеть: netblock или подсеть, связанная с IP-адресом.
• ASN: номер автономной системы и название организации.
• First Seen: метка времени, отображающая дату, в которую мы впервые наблюдали это разрешение.
• Last Seen: метка времени, отображающая дату последнего наблюдения за этим разрешением.
• Источник: источник, который включил обнаружение связи.
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Вопросы, ответы на которые может помочь этот набор данных

Домены

• Когда домен впервые обнаружил разрешение на IP-адрес в Defender TI?

  

• Когда в последний раз было замечено активное разрешение на IP-адрес в Defender TI?

  

• На какой IP-адрес или адреса в данный момент разрешается?

  

IP-адреса

• Можно ли маршрутизируемый IP-адрес?

  

• В какую подсеть она входит?

  

• Связан ли владелец с подсетью?

  

• В какую часть входит AS?

  

• Какое географическое расположение?

  

Whois

Тысячи раз в день домены покупаются и /или передаются между отдельными лицами и организациями. Процесс прост, занимает всего несколько минут и может быть не более 7 долл. США, в зависимости от поставщика регистратора. Помимо сведений об оплате, необходимо предоставить дополнительные сведения о себе. Некоторые из этих сведений хранятся в записи Whois, в которую был настроен домен. Это действие будет считаться регистрацией общественного домена. Однако существуют частные службы регистрации доменов, где вы можете скрыть личную информацию из записи Whois вашего домена. В таких ситуациях сведения владельца домена являются безопасными и заменяются сведениями регистратора домена. Все больше групп субъектов выполняют регистрацию частных доменов, чтобы аналитикам было труднее найти другие домены, которыми они владеют. Defender TI предоставляет различные наборы данных для поиска общей инфраструктуры субъектов, если записи Whois не предоставляют потенциальных клиентов.

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

Каждая запись Whois содержит несколько разных разделов, каждый из которых может содержать разные сведения. Часто встречаются разделы "регистратор", "регистратор", "администратор" и "технический", каждый из которых может соответствовать другому контакту для записи. Часто эти данные дублируются по разделам, но в некоторых случаях могут быть незначительные расхождения, особенно если субъект совершил ошибку. При просмотре сведений Whois в Defender TI вы увидите сокращенную запись, которая дедупликирует любые данные и указывает, из какой части записи она была получена. Мы обнаружили, что этот процесс значительно ускоряет рабочий процесс аналитика и позволяет избежать упущения данных. Информация Whois в Defender TI работает на базе базы данных WhoisIQ™.

Наши данные Whois содержат следующие сведения:

• Обновленная запись: метка времени, указывающая день последнего обновления записи Whois.
• Последняя проверка: дата последнего сканирования записи системой Defender TI.
• Срок действия: дата окончания срока действия регистрации, если она доступна.
• Создано: возраст текущей записи Whois.
• Сервер Whois. Сервер настраивается аккредитованным регистратором, зарегистрированным в ПРОГРАММЕ РЕГИСТРАЦИИ, для получения актуальной информации о зарегистрированных в нем доменах.
• Регистратор: служба регистратора, используемая для регистрации артефакта.
• Состояние домена: текущее состояние домена. "Активный" домен работает в Интернете.
• Email: все адреса электронной почты, найденные в записи Whois, и тип контакта, с которыми связан каждый из них (например, администратор, специалист).
• Имя: имя всех контактов в записи и тип контакта, с которым связан каждый из них.
• Организация. Название любых организаций в записи и тип контакта, с которыми связана каждая из них.
• Улица: любые адреса улиц, связанные с записью, и тип соответствующего контакта.
• Город: любой город, указанный в адресе, связанном с записью, и тип соответствующего контакта.
• Состояние: все состояния, перечисленные в адресе, связанном с записью, и тип соответствующего контакта.
• Почтовый индекс: все почтовые индексы, указанные в адресе, связанном с записью, и тип соответствующего контакта.
• Страна: все страны, перечисленные в адресе, связанном с записью, и тип соответствующего контакта.
• Телефон: любые номера телефонов, перечисленные в записи, и тип соответствующего контакта.
• Серверы имен. Все серверы имен, связанные с зарегистрированной сущностью.

Текущие подстановки Whois

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

Исторические поиски Whois

Репозиторий Журнала Whois в Defender TI предоставляет пользователям доступ ко всем известным историческим связям доменов с атрибутами Whois на основе наблюдений системы. Этот набор данных выделяет все домены, связанные с атрибутом, который пользователь сводит после отображения первого и последнего времени, когда мы наблюдали связь между доменом и атрибутом, запрошенным. Эти данные отображаются на отдельной вкладке рядом с текущей вкладкой Whois Поиск.

Ответы на вопросы, которые может помочь этот набор данных:

• Сколько лет домену?

  

• Защищена ли информация?

  

• Какие-либо данные кажутся уникальными?

  

• Какие серверы имен используются?

  

• Является ли этот домен доменом-воронкой?

  

• Является ли этот домен припаркованным доменом?

  

• Является ли этот домен доменом honeypot?

  

• Есть ли какая-нибудь история?

  

• Существуют ли поддельные электронные письма о защите конфиденциальности?

  

• Есть ли в записи Whois какие-либо поддельные имена?

• Вы определили другие связанные операции ввода-вывода из поиска потенциально общих значений Whois в разных доменах?

  

Сертификаты

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

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

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

Чтобы проиллюстрировать эту концепцию, представьте, что субъект настраивает сервер с самозаверяющий сертификат TLS. Через несколько дней защитники станут мудрее в своей инфраструктуре и блокируют веб-сервер, на котором размещено вредоносное содержимое. Вместо того чтобы уничтожить всю свою тяжелую работу, субъект просто копирует все содержимое (включая сертификат TLS) и помещает его на новый сервер. Как пользователь, теперь можно установить подключение с помощью уникального значения SHA-1 сертификата, чтобы сказать, что оба веб-сервера (один заблокирован, один неизвестный) подключены каким-то образом.

Что делает сертификаты TLS более ценными, так это то, что они могут устанавливать подключения, которые могут пропустить пассивные данные DNS или Whois. Это означает больше способов корреляции потенциальной вредоносной инфраструктуры и выявления потенциальных сбоев операционной безопасности субъектов. Defender TI собрал более 30 миллионов сертификатов с 2013 года по сегодняшний день и предоставляет пользователям инструменты для корреляции содержимого и журнала сертификатов.

Сертификаты TLS — это файлы, которые цифрово привязывают криптографический ключ к набору предоставленных пользователем сведений. Defender TI использует методы интернет-сканирования для сбора сопоставлений сертификатов TLS с IP-адресов на различных портах. Эти сертификаты хранятся в локальной базе данных и позволяют нам создать временная шкала, где в Интернете появился данный TLS-сертификат.

Наши данные сертификата включают следующие сведения:

• Sha1: хэш алгоритма SHA1 для ресурса tls Cert.
• First Seen: метка времени, отображающая дату, в которую мы впервые наблюдали этот сертификат на артефакте.
• Last Seen : метка времени, отображающая дату последнего наблюдения за этим сертификатом в артефакте.
• Инфраструктура: любая связанная инфраструктура, связанная с сертификатом.

Когда пользователь расширяет хэш SHA1, он видит следующие сведения**:

• Серийный номер: серийный номер, связанный с сертификатом TLS.
• Выдано: дата выдачи сертификата.
• Срок действия: дата истечения срока действия сертификата.
• Общее имя субъекта: общее имя субъекта для всех связанных сертификатов TLS.
• Общее имя издателя: общее имя издателя для всех связанных сертификатов TLS.
• Альтернативные имена субъекта: любые альтернативные общие имена для сертификата TLS.
• Альтернативные имена издателя: любые дополнительные имена издателя.
• Название организации субъекта: организация, связанная с регистрацией сертификата TLS.
• Название организации издателя: имя организации, которая организовала выдачу сертификата.
• Версия SSL: версия SSL/TLS, в которую был зарегистрирован сертификат.
• Подразделение организации субъекта. Необязательные метаданные, указывающие отдел в организации, ответственной за сертификат.
• Подразделение организации издателя. Дополнительные сведения об организации, выдавляющем сертификат.
• Адрес улицы субъекта: адрес улицы, где расположена организация.
• Адрес издателя: адрес улицы, где расположена организация издателя.
• Locality subject( Locality) — город, в котором расположена организация.
• Расположение издателя: город, в котором расположена организация издателя.
• Область субъекта: штат или провинция, в которой расположена организация.
• Штат или провинция издателя: штат или провинция, в которой расположена организация издателя.
• Страна субъекта: страна, в которой расположена организация.
• Страна издателя: страна, в которой расположена организация-издатель.
• Связанная инфраструктура: любая связанная инфраструктура, связанная с сертификатом.

Ответы на вопросы, которые может помочь этот набор данных:

• С какой другой инфраструктурой связан этот сертификат?

  

• Есть ли в сертификате уникальные точки данных, которые будут служить хорошими точками сводных данных?

  

• Самозаверяющий сертификат?

  

• Сертификат от бесплатного поставщика?

  

• В течение какого периода времени использовался сертификат?

  

Поддомены

Поддомен — это интернет-домен, который является частью основного домена. Поддомены также называются узлами. Например,learn.microsoft.com является поддоменом microsoft.com. Для каждого поддомена может быть новый набор IP-адресов, по которым домен разрешается, и это может быть отличным источником данных для поиска связанной инфраструктуры.

Наши данные поддомена включают следующие сведения:

• Hostname: поддомен, связанный с доменом, в котором был выполнен поиск.
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Ответы на вопросы, которые может помочь этот набор данных:

• Есть ли больше поддоменов, связанных с доменом более высокого уровня?

  

• Связаны ли какие-либо поддомены с вредоносными действиями?

  

• Если вы являетесь владельцем этого домена, какие-либо поддомены выглядят незнакомыми?

• Существует ли какой-либо шаблон для поддоменов, которые перечислены с другими вредоносными доменами?

• Отображает ли свертывание каждого поддомена новое пространство IP- адресов, ранее не связанное с целевым объектом?

• Какая другая несвязанная инфраструктура не соответствует корневому домену?

Трекеров

Средства отслеживания — это уникальные коды или значения, найденные на веб-страницах и часто используемые для отслеживания взаимодействия с пользователем. Эти коды можно использовать для сопоставления разрозненных групп веб-сайтов с центральной сущностью. Часто субъекты копируют исходный код веб-сайта жертвы, который они хотят олицетворять для фишинговой кампании. Субъекты редко занимают время, чтобы удалить эти идентификаторы, которые позволяют пользователям идентифицировать эти мошеннические сайты с помощью набора данных Отслеживания Майкрософт. Субъекты могут также развернуть идентификаторы трекера, чтобы увидеть, насколько успешными являются их кампании кибератак. Это действие похоже на маркетологов, когда они используют идентификаторы SEO, такие как Google Analytics Tracker ID, для отслеживания успеха своей маркетинговой кампании.

Набор данных Tracker корпорации Майкрософт включает идентификаторы таких поставщиков, как Google, Чикаго, Mixpanel, New Relic, Clicky и продолжает расти.

Наши данные средства отслеживания содержат следующие сведения:

• Hostname: имя узла, в котором размещается инфраструктура, в которой был обнаружен трекер.
• First Seen: метка времени, отображающая дату, которую мы впервые наблюдали этим трекером на артефакте.
• Last Seen: метка времени, отображающая дату последнего наблюдения этого средства отслеживания артефакта.
• Тип: тип обнаруженного средства отслеживания (например, GoogleAnalyticsID, JarmHash).
• Значение: значение идентификации для средства отслеживания.
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Ответы на вопросы, которые может помочь этот набор данных:

• Существуют ли другие ресурсы, использующие те же идентификаторы аналитики?

  

• Связаны ли эти ресурсы с организацией или они пытаются провести атаку с нарушением прав?

• Существует ли какое-либо перекрытие между средствами отслеживания — они предоставляются другим веб-сайтам?

• Какие типы трекеров можно найти на веб-странице?

  

• Сколько времени для трекеров?

  

• Какова частота изменений для значений средства отслеживания: они приходят, уходят или остаются?

• Есть ли какие-либо трекеры, ссылающиеся на программное обеспечение клонирования веб-сайта (MarkOfTheWeb или HTTrack)?

  

• Существуют ли какие-либо средства отслеживания, связывающие вредоносные программы сервера C2 (JARM)?

  

Компоненты

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

Наши данные компонентов включают в себя следующие сведения:

• Hostname: имя узла, в котором размещается инфраструктура, в которой был обнаружен компонент.
• First Seen: метка времени даты, которую мы впервые наблюдали за этим компонентом артефакта.
• Last Seen: метка времени даты, которую мы в последний раз наблюдали за этим компонентом артефакта.
• Категория: тип обнаруженного компонента (например, операционная система, платформа, удаленный доступ, сервер).
• Имя + версия: имя компонента и версия, запущенная в артефакте (например, Microsoft IIS (версия 8.5).
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Ответы на вопросы, которые может помочь этот набор данных:

• Какую уязвимую инфраструктуру вы используете?

  

  

  Magento версии 1.9 настолько устарел, что корпорация Майкрософт не смогла найти надежную документацию для этой конкретной версии.

• Какие уникальные веб-компоненты используют субъект угроз, который может отслеживать их в других доменах?

• Помечены ли какие-либо компоненты как вредоносные?

• Каково количество выявленных веб-компонентов?

  

• Есть ли какие-нибудь уникальные или странные технологии, которые не часто встречаются?

  

• Существуют ли поддельные версии конкретных технологий?

• Какова частота изменений в веб-компонентах, которые часто или редко выполняются?

• Есть ли подозрительные библиотеки, которые, как известно, злоупотребляют?

• Существуют ли какие-либо технологии с уязвимостями, связанными с ними?

Пары узлов

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

Данные пары узлов включают в себя следующее:

• Родительское имя узла: узел, который ссылается на ресурс или "обращается" к дочернему узлу.
• Имя дочернего узла: узел, вызываемый родительским узлом.
• First Seen: метка времени даты, в которую мы впервые наблюдали связь с узлом.
• Last Seen: метка времени даты, в которую мы в последний раз наблюдали связь с узлом.
• Причина: тип соединения между родительским и дочерним именем узла. Возможные причины включают script.src, link.href, redirect, img.src, unknown, xmlhttprequest, a.href, finalRedirect, css.import или parentPage connections.
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Ответы на вопросы, которые может помочь этот набор данных:

• Были ли заблокированы какие-либо подключенные артефакты?

• Помечены ли какие-либо подключенные артефакты (фишинг, APT, вредоносный, подозрительный, имя субъекта угроз)?

• Перенаправляет ли этот узел пользователей на вредоносное содержимое?

  

• Используются ли ресурсы в CSS или изображения для настройки атак с нарушением прав?

  

• Используются ли ресурсы в скрипте или ссылаются на link.href для настройки атаки Magecart или skimming?

  

• Куда перенаправляются пользователи?

• Какой тип перенаправления выполняется?

Файлы cookie

Файлы cookie — это небольшие фрагменты данных, отправляемые с сервера клиенту, когда пользователь просматривает Интернет. Иногда эти значения содержат состояние приложения или небольшие биты данных отслеживания. Defender TI выделяет и индексирует имена файлов cookie, наблюдаемые при обходе веб-сайта, и позволяет пользователям копаться везде, где мы наблюдали конкретные имена файлов cookie по его обходу и сбору данных. Файлы cookie также используются злоумышленниками для отслеживания инфицированных жертв или хранения данных, которые будут использоваться позже.

Наши данные cookie включают в себя следующие сведения:

• Hostname: инфраструктура узла, связанная с файлом cookie.
• First Seen: метка времени даты, в которую мы впервые наблюдали этот файл cookie в артефакте.
• Last Seen : метка времени даты, в которую мы в последний раз наблюдали этот файл cookie в артефакте.
• Имя: имя файла cookie (например, JSESSIONID, SEARCH_NAMESITE).
• Домен: домен, связанный с файлом cookie.
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Ответы на вопросы, которые может помочь этот набор данных:

• Какие другие веб-сайты выдают те же файлы cookie?

  

• Какие другие веб-сайты отслеживают те же файлы cookie?

  

• Соответствует ли домен cookie вашему запросу?

• Каково количество файлов cookie, связанных с артефактом?

  

• Существуют ли уникальные имена файлов cookie или домены?

• Какие периоды времени связаны с файлами cookie?

• Какова частота новых наблюдаемых файлов cookie или изменений, связанных с файлами cookie?

Службы

Имена служб и номера портов используются для различия между различными службами, работающими по транспортным протоколам, таким как TCP, UDP, DCCP и SCTP. Номера портов могут подсказать, какой тип приложения выполняется на определенном порту. Но приложения или службы можно изменить, чтобы использовать другой порт для маскировки или скрытия службы или приложения на IP-адресе. Зная сведения о порте и заголовке или баннере, можно определить истинное приложение или службу и сочетание используемых портов. Defender TI отображает 14 дней истории на вкладке Службы, где отображается последний ответ баннера, связанный с наблюдаемыми портами.

Данные наших служб включают следующую информацию:

• Открытые порты
• Номера портов
• Компоненты
• Количество наблюдений за службой
• Время последней проверки порта
• Подключение по протоколу
• Состояние порта
  • Открыть
  • Фильтруется
  • Закрыто
• Ответ баннера

Ответы на вопросы, которые может помочь этот набор данных:

• Какие приложения выполняются на определенном порту для заданного IP-адреса?

  

• Какая версия приложений используется?

  

• Произошли ли последние изменения в состоянии открытия, фильтрации или закрытия для данного порта?

  

• Связан ли сертификат с подключением?

  

• Используются ли в данном ресурсе уязвимые или нерекомендуемые технологии?

  

  

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

• Соблюдаются ли рекомендации по обеспечению безопасности?

DNS

Корпорация Майкрософт собирает записи DNS на протяжении многих лет, предоставляя пользователям аналитические сведения о записях обмена почтой (MX), записях серверов имен (NS), текстовых записях (TXT), записях начала центра (SOA), записях канонических имен (CNAME) и записях указателей (PTR). Просмотр записей DNS может быть полезен для определения общей инфраструктуры, используемой субъектами в доменах, которыми они владеют. Например, группы субъектов, как правило, используют одни и те же серверы имен для сегментирования своей инфраструктуры или одни и те же серверы обмена почтой для администрирования своих команд и управления.

Наши данные DNS содержат следующие сведения:

• Значение: запись DNS, связанная с узлом.
• First Seen: метка времени, отображающая дату, в которую мы впервые наблюдали эту запись на артефакте.
• Last Seen : метка времени, отображающая дату последнего наблюдения этой записи в артефакте.
• Тип: тип инфраструктуры, связанной с записью. Возможные варианты включают почтовые серверы (MX), текстовые файлы (TXT), серверы имен (NS), CNAMES и записи запуска центра (SOA).
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Ответы на вопросы, которые может помочь этот набор данных:

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

Обратный DNS

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

Наши обратные данные DNS содержат следующие сведения:

• Значение: значение обратной записи DNS.
• First Seen: метка времени даты, в которую мы впервые наблюдали эту запись на артефакте.
• Last Seen : метка времени даты, которую мы впервые наблюдали за этой записью артефакта.
• Тип: тип инфраструктуры, связанной с записью. Возможные варианты включают почтовые серверы (MX), текстовые файлы (TXT), серверы имен (NS), CNAMES и записи запуска центра (SOA).
• Теги: любые теги, примененные к этому артефакту в системе TI Defender.

Вопросы, ответы на которые может помочь этот набор данных:

• Какие записи DNS наблюдались на этом узле?
• Как инфраструктура, наблюдающая за этим узлом, изменилась с течением времени?

Дальнейшие действия

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

• Поиск и сведение
• Сортировка, фильтрация и скачивание данных
• Цепочки инфраструктуры
• Руководство по сбору аналитики угроз и связывания инфраструктуры