Проблема; Решение

Отсутствие поставщика с разными коллекциями данных: доменами, passive DNS, passive SSL, DNS-записями, открытыми портами, запущенными сервисами на портах, файлами, взаимодействующими с доменными именами и IP-адресами. Пояснение. Обычно поставщики предоставляют отдельные типы данных, и, чтобы собрать полную картину, нужно покупать подписки у всех. Но и при этом не всегда удается получить все данные: некоторые поставщики passive SSL предоставляют данные только о сертификатах, выпущенных доверенными CA, а покрытие самоподписанных сертификатов у них крайне плохое. Другие предоставляют данные и по самоподписанным сертификатам, но собирают их только со стандартных портов.;Мы собрали все вышеуказанные коллекции сами. Например, для сбора данных о SSL-сертификатах мы писали собственный сервис, который собирает их и от доверенных CA, и с помощью сканирования всего IPv4-пространства. Сертификаты собирались не только с IP, но и со всех доменов и поддоменов из нашей базы: если у вас есть домен example.com и его поддомен www.example.com и все они резолвятся в IP 1.1.1.1, то при попытке получения SSL-сертификата с порта 443 по IP, домену и его поддомену вы можете получить три разных результата. Для сбора данных по открытым портам и запущенным сервисам пришлось делать свою распределенную систему сканирования, потому что у других сервисов IP-адреса сканирующих серверов часто находились в «черных списках». Наши сканирующие серверы тоже попадают в «черные списки», но результат обнаружения нужных нам сервисов выше, чем у тех, кто просто сканирует как можно больше портов и продает доступ к этим данным. Отсутствие доступа ко всей базе исторических записей. Пояснение. Каждый нормальный поставщик имеет хорошую накопленную историю, но по естественным причинам доступ ко всем историческим данным мы как клиент получить не могли. Т.е. можно получить всю историю по отдельной записи, например, по домену или IP-адресу, но нельзя увидеть историю всего — а без этого нельзя увидеть полную картину.;Чтобы собрать как можно больше исторических записей по доменам, мы скупали различные базы, парсили множество открытых ресурсов, которые обладали этой историей (хорошо, что таких было много), договаривались с регистраторами доменных имен. Все обновления в наших собственных коллекциях, конечно же, хранятся с полной историей изменений. Все существующие решения позволяют строить граф в ручном режиме. Пояснение. Допустим, вы купили множество подписок от всех возможных поставщиков данных (как правило, их называют «обогатители»). Когда вам нужно построить граф, вы «руками» даете команду достроить от нужного элемента связи, далее из появившихся элементов выбираете нужные и даете команду достроить связи от них и так далее. В этом случае ответственность за то, насколько качественно будет построен граф, полностью лежит на человеке.;Мы сделали автоматическое построение графов. Т.е. если вам нужно построить граф, то связи от первого элемента строятся автоматически, далее от всех последующих — тоже. Специалист лишь указывает глубину, с которой нужно строить граф. Сам процесс автоматической достройки графов простой, но другие вендоры не реализуют его потому, что он дает огромное количество нерелевантных результатов и этот недостаток нам тоже пришлось учитывать (см. ниже). Множество нерелевантных результатов — это проблема всех графов по сетевым элементам. Пояснение. Например, «плохой домен» (участвовал в атаке) связан с сервером, с которым за последние 10 лет связано 500 других доменов. При ручном добавлении или автоматическом построении графа все эти 500 доменов тоже должны вылезти на граф, хотя не имеют отношения к атаке. Или, например, вы проверяете IP-индикатор из отчета вендора по безопасности. Как правило, такие отчеты выходят со значительной задержкой и часто охватывают год и более. Скорее всего, в момент, когда вы читаете отчет, сервер с этим IP-адресом уже сдан в аренду другим людям с другими связями, и построение графа приведет к тому, что вы опять получили нерелевантные результаты.;Мы обучили систему выявлять нерелевантные элементы по той же логике, как это делали наши эксперты руками. Например, вы проверяете плохой домен example.com, который сейчас резолвится в IP 11.11.11.11, а месяц назад — в IP 22.22.22.22. С IP 11.11.11.11, кроме домена example.com, связан еще example.ru, а с IP 22.22.22.22 связано 25 тысяч других доменов. Система, как и человек, понимает, что 11.11.11.11 — это, скорее всего, выделенный сервер, а поскольку домен example.ru схож по написанию с example.com, то, с большой вероятностью, они связаны и должны быть на графе, а вот IP 22.22.22.22 принадлежит shared hosting, поэтому все его домены выносить на граф не нужно, если нет других связей, показывающих, что какой-то из этих 25 тысяч доменов тоже нужно вынести (например, example.net). Прежде чем система поймет, что связи нужно разорвать и не выносить часть элементов на граф, она учитывает множество свойств элементов и кластеров, в которые эти элементы объединены, а также прочность текущих связей. Не учитывается интервал владения сервером, доменом. Пояснение. Срок регистрации «плохих доменов» рано или поздно истекает, и их снова покупают для вредоносных или легитимных целей. Даже у bulletproof-хостингов серверы сдаются в аренду разным хакерам, поэтому критично знать и учитывать интервал, когда тот или иной домен/сервер находились под управлением одного владельца. Мы часто сталкиваемся с ситуацией, когда сервер с IP 11.11.11.11 сейчас используется как C&C для банковской бота, а еще 2 месяца назад с него управляли Ransomeware. Если строить связь, не учитывая интервалы владения, то будет похоже, что между владельцами банковской бот-сети и вымогателями есть связь, хотя на самом деле ее нет. В нашей работе такая ошибка является критичной.; Мы научили систему определять интервалы владения. Для доменов это относительно просто, ведь в whois часто указаны даты начала и истечения регистрации и, когда есть полная история изменений whois, определить интервалы легко. Когда у домена срок регистрации не истек, но его управление было передано другим владельцам, тоже можно отследить. Для SSL-сертификатов такой проблемы нет, ведь он выпускается один раз, не продляется и не передается. Но у самоподписанных сертификатов нельзя доверять датам, указанным в сроках действия сертификата, потому что можно сгенерировать SSL-сертификат сегодня, а дату начала действия сертификата указать с 2010 года. Сложнее всего определять интервалы владения для серверов, ведь даты и сроки аренды есть только у хостинг-провайдеров. Чтобы определять период владения сервером, мы начали использовать результаты сканирования портов и создания отпечатков запущенных служб на портах. По этой информации мы достаточно точно можем сказать, когда у сервера менялся владелец. Мало связей. Пояснение. Сейчас не проблема даже бесплатно получить список доменов, в whois которых указан определенный адрес электронной почты, или узнать все домены, которые были связаны с определенным IP-адресом. Но, когда речь идет о хакерах, которые делают все возможное, чтобы их было тяжело отслеживать, нужны дополнительные «трюки», которые позволят найти новые свойства и построить новые связи.;Мы потратили много времени на исследование того, как можно извлекать данные, которые недоступны, обычным способом. Описывать тут, как это работает, мы не можем по понятным причинам, но при определенных обстоятельствах хакеры при регистрации доменов или аренде и настройке серверов допускают ошибки, которые позволяют узнать адреса электронной почты, псевдонимы хакеров, адреса бэкендов. Чем больше связей вы извлекаете, тем точнее можно строить графы.

Связаны с криптовалютой; Связан с сервисами пробива телефонов

coinkeeper[.]cc;caller-record[.]site. mcxwallet[.]co; phone-records[.]space btcnoise[.]com; fone-uncover[.]xyz cryptominer[.]watch; number-uncover[.]info