OSINT по email-адресу: какие данные можно найти легально и где проходят границы приватности

Что даёт сам формат адреса​

Email-адрес состоит из локальной части и домена, разделённых символом @. Домен сразу указывает на провайдера или организацию. Это первый и самый очевидный источник информации:

• Корпоративный домен ([email protected]) — подтверждает принадлежность к организации. По домену можно определить сайт, технологический стек, размер компании.
  
• Публичный провайдер ([email protected], [email protected]) — не привязывает адрес к конкретной организации, но указывает на экосистему сервисов.
  
• Собственный домен ([email protected]) — часто означает, что человек сам администрирует инфраструктуру.
  

Локальная часть иногда содержит имя, фамилию, должность или год рождения, но полагаться на это как на факт нельзя: формат a.petrov2019@ может означать что угодно.

RDAP и WHOIS: данные о регистрации домена​

Если домен из email-адреса зарегистрирован на организацию или частное лицо, данные регистрации могут быть публичными. Протокол RDAP (Registration Data Access Protocol) пришёл на смену WHOIS и предоставляет структурированный доступ к регистрационным данным через стандартизированные HTTP-запросы.

По состоянию на январь 2025 года все реестры и регистраторы gTLD обязаны предоставлять RDAP-сервисы, а WHOIS-доступ для большинства зон (кроме .com, .name, .post) больше не требуется.

Практический запрос к RDAP выглядит так:

curl -s "https://rdap.org/domain/example.com" | jq '.entities[] | select(.roles[] == "registrant") | .vcardArray'

Ответ содержит vCard-массив с полями: имя, организация, адрес, телефон, email. Однако с введением GDPR и политик конфиденциальности регистраторов большинство записей для физических лиц закрыты или заменены данными прокси-сервиса.

Что реально можно получить через RDAP:

Поле	Доступность
Имя регистранта	Часто скрыто (privacy/proxy)
Организация	Доступна для юрлиц
Даты регистрации и истечения	Почти всегда открыты
NS-серверы	Открыты
Контактный email регистранта	Часто скрыт

Для доменов в зоне .ru и .рф данные предоставляет сервис whois.tcinet.ru. Политика конфиденциальности Координационного центра скрывает данные физических лиц по умолчанию.

Проверка утечек данных​

Сервис Have I Been Pwned (HIBP) позволяет проверить, встречался ли email в известных базах утечек. Это легальный инструмент, который помогает оценить компрометацию аккаунтов.

curl -s -H "hibp-api-key: YOUR_KEY" \
  "https://haveibeenpwned.com/api/v3/breachedaccount/[email protected]"

API возвращает список утечек с датами и типами скомпрометированных данных. Бесплатный доступ к API закрыт, но веб-интерфейс на сайте остаётся открытым для ручной проверки.

Что это даёт в контексте OSINT:

• Подтверждение, что адрес реально используется (а не сгенерирован).
  
• Перечень сервисов, где человек регистрировался.
  
• Типы данных в утечке: пароли, телефоны, адреса, даты рождения.
  

Важно: сам факт наличия адреса в утечке не раскрывает содержимое данных. Для детального анализа нужны доступы к самим дампами, что уже выходит за рамки легального OSINT.

Gravatar и аватары​

Gravatar (Globally Recognized Avatar) привязывает изображение к MD5-хешу email-адреса. Если пользователь зарегистрировал аватар, его можно получить по хешу:

echo -n "[email protected]" | md5sum | awk '{print $1}'
## Результат: хеш, который подставляется в URL
## https://www.gravatar.com/avatar/<hash>

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

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

Анализ заголовков email​

Если у вас есть входящее письмо от исследуемого адреса, заголовки (headers) содержат технические метаданные:

• Received — цепочка серверов, через которые прошло письмо. Может раскрыть IP-адрес отправителя, если письмо отправлено напрямую без промежуточных relay.
  
• Message-ID — уникальный идентификатор, иногда содержит доменное имя сервера отправки.
  
• X-Mailer / User-Agent — почтовый клиент (Thunderbird, Outlook, Gmail Web).
  
• DKIM / SPF / DMARC — результаты аутентификации, подтверждают или опровергают подлинность домена.
  

Крупные провайдеры (Gmail, Outlook.com, Yahoo) подставляют свои relay-серверы в цепочку Received, поэтому реальный IP отправителя в заголовках не виден. Для корпоративных и self-hosted серверов IP может быть доступен.

Received: from mail.example.com (mail.example.com. [203.0.113.42])
        by mx.google.com with ESMTPS id abc123...

Здесь 203.0.113.42 — IP сервера отправки. По нему можно определить хостинг-провайдера и географическое расположение через GeoIP-базы.

Социальные сети и публичные профили​

Некоторые платформы позволяют искать пользователей по email или показывают привязанный email в профиле:

• LinkedIn — корпоративный email иногда виден в разделе «Контактная информация» для соединений первого уровня.
  
• GitHub — email может быть указан в профиле или в commit-истории (git log --format='%ae').
  
• Telegram — поиск по email не работает, но если человек указал email в bio, это можно найти вручную.
  
• Форумы и CMS — многие движки (WordPress, phpBB) показывают email автора в RSS-ленте или API.
  

Для GitHub есть отдельный приём: даже если email скрыт в настройках профиля, он может оставаться в commit-метаданных публичных репозиториев.

git clone --bare https://github.com/user/repo.git
cd repo.git
git log --format='%ae' | sort -u

Корпоративные email: дополнительные векторы​

Если адрес принадлежит организации, круг легальных источников расширяется:

• Сайт компании — раздел «Команда», «Контакты», пресс-релизы.
  
• LinkedIn компании — список сотрудников.
  
• SPF/DKIM-записи домена — раскрывают используемые почтовые сервисы (Google Workspace, Microsoft 365, собственный MX).
  
• Certificate Transparency — логи SSL-сертификатов могут показать субдомены (mail.company.com, owa.company.com), указывающие на инфраструктуру.
  

Проверка MX-записей:

dig MX company.com +short

Результат вроде 10 company-com.mail.protection.outlook.com. сразу говорит об использовании Microsoft 365.

Где проходят границы приватности​

Легальный OSINT работает с данными, которые человек или организация сделали публичными добровольно или в силу технических протоколов. Граница проходит там, где начинается:

Действие	Статус
Проверка домена через RDAP	Легально
Поиск в публичных утечках через HIBP	Легально
Анализ заголовков полученного письма	Легально
Поиск публичных профилей в соцсетях	Легально
Отправка фишингового письма для получения данных	Незаконно
Перебор паролей от почтового ящика	Незаконно
Социальная инженерия с целью раскрытия личных данных	Незаконно
Поиск домашнего адреса частного лица	Нарушение приватности
Скрытое наблюдение за перемещениями	Незаконно

Ключевой принцип: OSINT — это анализ уже опубликованной информации, а не добыча закрытой. Если данные доступны только через взлом, обман или нарушение условий сервиса, это не OSINT.

Правовые ограничения по юрисдикциям​

• GDPR (ЕС) — обработка персональных данных требует правового основания. Сбор и хранение email-адресов и связанных с ними данных для профилирования без согласия может нарушать Regulation.
  
• 152-ФЗ (Россия) — оператор персональных данных обязан иметь цель и основание обработки. Систематический сбор данных о частных лицах без их согласия создаёт правовые риски.
  
• CFAA (США) — несанкционированный доступ к компьютерным системам уголовно наказуем, даже если цель — «исследование».
  

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

Практический чек-лист​

1. Определите тип домена: корпоративный, публичный провайдер, собственный.
   
2. Проверьте RDAP/WHOIS для домена — даты регистрации, NS, организация.
   
3. Проверьте MX-записи для определения почтовой инфраструктуры.
   
4. Поищите адрес в Have I Been Pwned для оценки компрометации.
   
5. Проверьте Gravatar по MD5-хешу адреса.
   
6. Если есть входящее письмо — проанализируйте заголовки Received.
   
7. Поищите адрес в публичных commit-историях GitHub.
   
8. Проверьте публичные профили в соцсетях и на форумах.
   
9. Для корпоративных адресов — осмотрите сайт компании и LinkedIn.
   
10. Зафиксируйте, какие данные получены из публичных источников, и не пересекайте границу в сторону закрытой информации.
    

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

Источники​

• Resources - bellingcat
  
• Registration Data Access Protocol (RDAP)