What's wrong with namecheckers?

Недавно мой пристальный взгляд упал на инструменты для поиска аккаунтов на сайтах по никнейму. Самые известные, к примеру -- namechk.com, whatsmyname.app, sherlock, snoop.

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

Я пошёл дальше и перебрал все известные инструменты: как скрипты, так и сайты. Поспрашивал коллег и собрал статистику кейсов использования. И сделал неутешительный вывод -- сейчас нет ни одного нормального инструмента для поиска по никнейму.

Почему? Что я вкладываю в понятие "нормальный"? И что с этим делать? Попробую изложить это далее.

Branding tools

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

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

Прежде всего, поиск по доменам. Это интересный подход, и наверняка он иногда даёт результаты по нику человека. Но назначение этого поиска -- найти доступные домены, чтобы купить их и раскрутить свой бренд.

Теперь взгляните на их поиск по сайтам. Такие инструменты как Namechk, InstantUsername, Checkusernames предлагают не найти профили человека, а проверить, что имя не занято. Мало того, что кейс их применения прямо противоположен, он ещё и не требует высокой точности.

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

Количество и качество

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

Поэтому чем больше будет список проверяемых сайтов у нормального инструмента, тем лучше. Но это накладывает определённые обязательства:

Качество

Нам нужны только правильные результаты, с минимумом ложных срабатываний. Обсудим это подробнее в следующем разделе.

Ранжирование

Нам важно понимать, какие сайты важнее, чтобы быстрее получить результат при анализе. Sherlock умеет ранжировать сайты перед проверкой по топу Alexa, что кажется очень разумным. Это объективная оценка, показывается "вес" сайта, его важность для людей. Но, к сожалению, в отчёте это никак не отражается.

Разработчики  snoop хорошо уловили эту потребность: у них сайты делятся по регионам, причём есть регион worldwide для всемирно используемых. И в html-отчёте есть возможность сортировать по этому признаку. Но внутреннего ранжирования по группам нет, так что будет сложно разобраться в том, какой из десятка всемирных сервисов важнее.

Категории

Здесь нельзя не отметить WhatsMyName -- их разбиение сайтов по категориям очень удобно, позволяет быстро отфильтровать нужное и однозначно must have.

Чем больше становится данных, тем больше разрезов нам нужно для аналитики.

Кастомизация

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

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

Ложные срабатывания

Здесь стоит выделить 3 категории:

1) Ложноотрицательные

Аккаунт на сайте не нашёлся, но он там есть.

Мы не получили полного ожидаемого результата, и либо не узнаем об этом сайте вовсе, либо потратим лишние силы, запуская другую утилиту и объединяя результаты (или проверяя вручную в Google).

И хорошо, если не нашёлся один маловажный ресурс, а если их десяток, и на каждом из них была полезная информация?

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

2) Ложноположительные технические

Аккаунт на сайте нашёлся, но его там нет.

Казалось бы, мы в любом случае пройдёмся по каждому сайту и проверим. Но не везде отсутствие аккаунта столь очевидно, и у вас может уйти пара минут на самостоятельную проверку.

Так или иначе мы потратим лишнее время. А если мы запускаем несколько утилит, и каждая "сбоит" на разных ресурсах? А если нам нужно сделать отчёт без анализа?

3) Ложноположительные фактические

Аккаунт на сайте нашёлся, никнейм тот, но он явно принадлежит другому человеку.

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

Что делать, чтобы избежать ложных срабатываний? Часто они происходят из-за наивных методов проверки (по коду ответа или редиректу). Это значит, что от разработчиков требуется больше усилий по поиску хорошего метода.

Дальше всех в этом направлении пошли socialscan, проверяющие доступность имени через официальный API -- никаких сбоев и внезапных изменений, а также возможность проверять email. Но поддерживают они до сих пор лишь 12 сайтов.

Также много ложных срабатываний происходит из-за непредвиденного ответа -- заглушек, капч и подобного. Разберём это ниже.

Цензура и Cloudflare

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

С первым в целом всё понятно -- если провайдер закрыл доступ к сайту, то проще всего использовать прокси/VPN. Но цензура есть в разных странах, и совсем не хочется грузить себя сведениями о том, какие прокси мне нужны для какой страны.

Сами сервисы тоже часто ограничивают доступ. Например, Spotify и CashMe недоступны в России. Разработчики sherlock даже не пытаются это проверить, и расценивают заглушку как подтверждение наличия аккаунта. В Snoop сделано предупреждение о цензуре при ошибках и рекомендация использовать VPN. Здраво, но проблемы не решает -- у snoop даже в платной базе Spotify и CashMe отсутствуют. Такое чувство, что разработчик сам не смог воспользоваться прокси, чтобы "снизить" ложные срабатывания по таким сайтам.

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

Up-to-date sites database

Теперь немного о своевременном обновлении данных.

Современные веб-сайты очень быстро меняются, подстраиваясь под требования бизнеса. И даже усиление приватности может быть таким требованием, что приводит к невозможности проверить наличие аккаунта на сайте (впрочем, чаще к этому приводят ошибки).

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

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

Snoop пошёл дальше и сделал параметры запуска для обновления базы и скрипта прямо из репозитория. Этот вектор развития мне нравится. Более того, я считаю, что надо сделать возможность отмечать ложные срабатывания и проблемы прямо в самом инструменте, давая оперативную информацию разработчикам.

Таким образом, петля обратной связи сужается до минимума, и вы быстрее получаете актуальные способы проверить аккаунты => получаете меньше ошибок.

Да, и всё это при условии прямых рук мейнтейнеров -- когда не происходит случайного возвращения неподдерживаемых сайтов как в sherlock (удалили, вернули).

Идентификаторы и перекрестные ссылки

Уже некоторое время я занимаюсь исследованием ID аккаунтов разных платформ и их использованием в OSINT. Например, у Google это GAIA ID, у Yandex свой Public ID. Как их можно использовать?

Имея всего лишь одну ссылку на расшаренный файл в Яндекс.Диске, можно получить никнейм, публичный ID и ссылки на профили в других сервисах Яндекса (даже там где никнейм не используется). Разумеется, это также можно и нужно автоматизировать.

Некоторое время назад в DC7495 я презентовал это исследование как теоретическое, потом из этого вырос инструмент socid_extractor -- он позволяет вытаскивать из страниц не только ID, но и ссылки на указанные самим человеком аккаунты на других сайтах.

Чем это может быть полезно? На основе одного только ника инструмент может и найти профили человека на других сайтах с другими никами, и сделать поиск по новым никам, и определить учётки, связанные лишь внутренними ID платформ.

Я уже предложил разработчикам sherlock использовать это, но дело с мёртвой точки пока не сдвинулось.

So what?

Подытожим и сформируем список требований к нормальному инструменту для поиска по никнейму.

• максимум сайтов для проверки: планка в 1000 уже пробита, целиться в меньшее количество нет смысла;
• ложных результатов нет: существующий профиль должен быть найден либо должна быть явная ошибка;
• база сайтов оперативно обновляется: например, при каждом запуске инструмента подтягиваются апдейты из облака;
• читаемый отчёт с ранжированием и категориями: как минимум csv или html + разделение по странам и назначению сайтов;
• кастомизация базы данных: простое добавление своих категорий и сайтов;
• надёжность методов проверок: инструмент должен не сбоить и уметь определять заглушки с защитой, авторизацией, капчей, так и специфические редиректы с цензурой провайдера или самого сайта;
• возможность массовых проверок по списку ников: мы это не обсуждали, но тут всё очевидно.

И дополнительные хотелки, которые в 2020 давно доступны, но упрямо игнорируются в OSINT:

• автоматическое использование подходящих прокси для обхода ограничений: есть готовые собирающие и фильтрующие инструменты;
• извлечение из страницы ссылок на другие профили и поиск по ним: инструмент может распутать сложный клубок из связанных имён и найти все остальные ники;
• скриншоты страниц или сохранение в веб-архив: очень актуально для оперативных поисков, когда уже через пару часов аккаунт может закрыться / удалиться.

Именно такой инструмент мне бы хотелось реализовать в ближайшее время.

Согласны ли вы с выводами? Считаете, что я что-то упустил? Для обсуждения предлагаю присоединиться к чату OSINT mindset.