OSINT методология расследования: учебный кейс по чек-листу и пропущенные зацепки

На тренировочном кейсе — разбор одного ника из учебного CTF-сценария — без чек-листа я нашёл 5 артефактов из 12 доступных. Семь зацепок просто не пришли в голову: не проверил репозитории кода, не прогнал email через базы утечек, пропустил метаданные фотографий. Разница между хаотичным поиском и OSINT методологией расследования — не в инструментах, а в последовательности шагов, которую невозможно перескочить. Ниже — один и тот же учебный кейс OSINT дважды: сначала «по наитию», потом по чек-листу. С цифрами, чтобы разница была видна.

Почему хаотичный поиск теряет зацепки

OSINT (Open Source Intelligence) — разведка по открытым источникам. Сбор и анализ цифровых следов из публично доступных данных: соцсетей, поисковых систем, форумов, доменных реестров, баз утечек. Задача — не взлом, а умение находить и связывать то, что уже лежит в открытом доступе.

Типичный сценарий у новичка: открыть браузер, вбить ник в Google, перейти на первый найденный профиль, начать «копать вглубь». Через 20 минут — уже третий пост в VK про кота, а начинали с поиска места работы. Это не лень. Это когнитивное туннелирование: мозг цепляется за первый результат и углубляется в него, игнорируя параллельные направления. Знакомо? У меня так было на каждом из первых кейсов.

MITRE ATT&CK — открытая база тактик и техник, которые реальные атакующие используют на практике. Каждая техника имеет T-код (уникальный идентификатор, например T1593). Для OSINT нас интересует тактика Reconnaissance (подготовка к атаке) и её конкретные категории:

• T1593 — Search Open Websites/Domains (поиск по открытым сайтам и доменам)
• T1593.001 — Social Media (социальные сети)
• T1593.002 — Search Engines (поисковые системы)
• T1593.003 — Code Repositories (репозитории кода: GitHub, GitLab)
• T1589 — Gather Victim Identity Information (сбор идентификационных данных)
• T1589.002 — Email Addresses (email-адреса)
• T1594 — Search Victim-Owned Websites (сайты, принадлежащие цели)
• T1591 — Gather Victim Org Information (информация об организации цели)

Зачем это знать на старте: T-коды — готовая основа для чек-листа OSINT разведки. Если при хаотичном поиске вы проверили T1593.001 (Social Media) и T1593.002 (Search Engines), но пропустили T1593.003 (репозитории кода) и T1589.002 (email через утечки) — потеряли минимум два направления целиком. И скорее всего даже не заметили пропуск.

Три ловушки бесструктурного поиска

1. Туннельное зрение. Первый результат кажется самым важным. Тратите 30 минут на разбор VK-профиля, хотя GitHub-аккаунт дал бы больше технической информации за 5 минут.
2. Отсутствие фиксации. Без записи проверенных источников через час не помните, что уже смотрели. Начинаете повторять шаги.
3. Нет точки остановки. Без структуры неясно, когда перейти от сбора к анализу. Расследование превращается в бесконечный сёрфинг.

Чек-лист решает все три: задаёт направления, предотвращает повторы, даёт понятную точку остановки.

Учебный кейс OSINT: 40 минут «по наитию»

Вводные данные

Тренировочная задача: установить максимум информации о владельце ника d3v_mark. Ник вымышленный — используется для демонстрации методики проведения OSINT анализа. В реальных расследованиях исходной точкой (pivot — зацепка, от которой строится дальнейший поиск) может быть ник, email, телефон или фотография.

Ограничения: только открытые источники, без взлома, без обращения к закрытым базам, без взаимодействия с объектом. Время — 40 минут. Инструменты — браузер и командная строка.

Результат и типичные пропуски в расследовании

Мой хаотичный подход выглядел так:

1. Google: запрос "d3v_mark" — нашёл упоминание на форуме, профиль VK с совпадающим ником.
2. VK: открытый профиль, фото с IT-конференции, в подписках — Python-каналы.
3. Telegram: поиск по юзернейму — нашёл канал с заметками про бэкенд-разработку.
4. LinkedIn: нашёл профиль «Mark S., Backend Developer» с частично закрытой информацией.
5. Instagram: ничего не нашёл — решил, что аккаунта нет, двинулся дальше.

Итого: 5 проверок, 4 положительных результата и 1 отрицательный. На первый взгляд — нормально.

Через неделю я прогнал тот же ник по чек-листу и обнаружил семь пропущенных направлений:

Результат без чек-листа: 5 из 12 направлений = 42% покрытия. Больше половины данных осталось за бортом — и без структуры это незаметно. Ощущение «я всё проверил» при 42% покрытия — вот что по-настоящему опасно.

Тот же кейс по чек-листу: инструменты OSINT разведки в деле

Тот же ник, те же инструменты. Разница — работа по структуре. Каждый шаг фиксируется с результатом: найдено, не найдено, требует проверки.

План сбора разведданных

Перед открытием браузера записываю пять строк:

• Цель: установить цифровой профиль владельца ника d3v_mark
• Гипотеза: ник используется одним человеком на нескольких платформах
• Типы данных: профили, email, домены, код, метаданные
• Временной диапазон: последние 3 года
• Ограничения: пассивный сбор, без взаимодействия с объектом

Зачем это нужно: без записанной цели расследование расползается. Профессиональные аналитики (по рекомендациям OSINT Handbook, The OSINT Vault) начинают каждый кейс с формулировки гипотезы, которую будут подтверждать или опровергать. Гипотеза фокусирует поиск: если «один человек на нескольких платформах» — ищем перекрёстные совпадения, а не просто коллекционируем профили.

Пошаговый обход по категориям

Шаг 1. Username — автоматический перебор платформ

Инструмент maigret (ставится в Kali Linux через pip install maigret; альтернатива — sherlock) проверяет ник по сотням платформ за минуты. Ручной перебор VK → Telegram → LinkedIn покрывает 5-6 платформ за час. Автоматический — сотни сайтов за несколько минут (точное время зависит от сети и значения --timeout).

maigret d3v_mark --timeout 10 --top-sites 500

В выводе рядом с каждым URL будет статус Claimed (профиль найден) или Available (ник свободен). В моём случае — кроме уже известных VK и Telegram нашлись GitHub, Stack Overflow и Reddit. Три платформы, которые при ручном поиске просто не пришли в голову.

Каждый найденный профиль — новый pivot. Из GitHub вытаскиваем email через коммиты. Из Stack Overflow — текущие рабочие задачи по вопросам. Из Reddit — неформальное общение, где человек расслаблен и пишет больше, чем стоило бы.

Шаг 2. Google Dorks — точечный поиск

Google Dorks — операторы расширенного поиска, специальные команды для Google, которые сужают результаты до конкретных сайтов или типов файлов:

"d3v_mark" site:github.com
"d3v_mark" site:stackoverflow.com
"d3v_mark" filetype:pdf

Первая строка ищет ник только на GitHub. Вторая — на Stack Overflow. Третья — в PDF-документах (резюме, списки участников хакатонов, конференций). Если на выходе — PDF со списком участников события, где рядом имя и ник, это сильный артефакт.

Обычный запрос "d3v_mark" в Google даёт шум. Операторы site: и filetype: отсекают нерелевантное. Это техника T1593.002 (Search Engines) в терминах MITRE.

Шаг 3. Email → базы утечек

Email, найденный в Git-коммитах на GitHub, прогоняем через Have I Been Pwned (HIBP) — сервис, который проверяет, попал ли email в публичные утечки данных. Масштаб утечек для понимания: утечка Facebook содержит, по данным HIBP, более 509 миллионов записей с email, геолокацией, местом работы и датами рождения. LinkedIn — 164 миллиона записей с email и паролями (2012) плюс 125 миллионов скрейпнутых профилей (2021). Российский стриминговый сервис START — 7,4 миллиона записей (2021).

Если email объекта попал хотя бы в одну утечку, мы получаем контекст: в какие сервисы он регистрировался, какие данные были раскрыты (имя, телефон, геолокация). Проверка email в HIBP легальна — сервис показывает название утечки, но не сами данные.

Шаг 4. Домены и инфраструктура

Проверяем, зарегистрированы ли домены на найденный email — через WHOIS (публичная база регистрации доменов). Разработчики часто регистрируют персональные домены для портфолио или пет-проектов.

Команда whois d3vmark.dev покажет имя регистранта, дату создания и контактный email. Совпадение email — сильная связь ника с реальной личностью. Если WHOIS скрыт через privacy-сервис — фиксируем «данные недоступны» и идём дальше. Не пропускаем пункт — отрицательный результат тоже результат.

Дополнительно: проверяем домен через Wayback Machine (web.archive.org) — архив интернета, который сохраняет снимки старых версий страниц. Удалённая страница «О себе» с именем и фото — одна из самых частых находок на учебных кейсах. Люди удаляют страницы, но забывают про кэш.

Шаг 5. Метаданные фотографий

Фотографии с конференций, загруженные в соцсети, могут содержать EXIF-данные — метаданные, которые камера или телефон автоматически встраивает в файл: модель устройства, дата съёмки, GPS-координаты. Не все платформы удаляют их при загрузке (VK, например, удаляет; Telegram при отправке без сжатия — нет).

Запускаем exiftool photo.jpg на скачанном файле (утилита предустановлена в Kali, доступна для Windows и macOS). В выводе ищем поля GPS Position, Date/Time Original, Camera Model Name. GPS-координаты подтверждают, что человек реально был в конкретном месте в конкретное время.

Верификация источников OSINT

Самый игнорируемый пункт у начинающих — и самый важный. Один и тот же ник на двух платформах ещё не доказательство, что за ними стоит один человек. Я однажды на учебном кейсе приписал два аккаунта одному человеку по совпадению ника. Оказалось — разные люди.

Методика verification matrix (OSINT Handbook) строится на уровнях confidence scoring — оценке уверенности в связи между находками:

• Одно совпадение (ник на двух платформах): низкая уверенность. Ник d3v_mark может использовать кто угодно.
• Два независимых совпадения (ник + тот же email): средняя уверенность. Связь есть, но не доказательство.
• Три и более (ник + email + совпадающий аватар + согласованная временнáя линия активности): высокая уверенность.

Каждый артефакт фиксируется с URL-источником, датой доступа и уровнем уверенности. Без этого расследование — набор догадок, а не результат, который можно проверить повторно или передать другому аналитику.

Сравнение: структурированный подход OSINT vs хаос

Разница: 5 → 11 артефактов. Инструменты те же — maigret, exiftool, Google Dorks доступны в обоих случаях. Результат определяет не набор утилит, а наличие плана сбора разведданных.

Единственное, что не удалось найти даже по чек-листу — связь ника с WhatsApp. Телефон из утечки оказался деактивирован. Чек-лист не гарантирует 100% покрытия, но гарантирует, что вы проверите каждое направление и будете знать, где именно упёрлись в стену.

Чек-лист OSINT разведки: шаблон для обучения с нуля

20 пунктов аналитического чек-листа исследователя

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

Блок 1. Подготовка

1. Цель расследования записана конкретно (что ищем, зачем)
2. Гипотеза сформулирована (что проверяем)
3. Временной диапазон определён
4. Ограничения зафиксированы (пассивный сбор, юрисдикция)

Блок 2. Идентификаторы — от исходного pivot

5. Username → автоматический перебор (maigret / sherlock)
6. Email → извлечение из профилей, Git-коммитов, WHOIS
7. Телефон → reverse lookup, проверка в мессенджерах
8. Фото → reverse image search (Google Images, Yandex, TinEye)

Блок 3. Платформы и источники

9. Социальные сети (VK, Telegram, LinkedIn, Facebook, X, Reddit)
10. Репозитории кода (GitHub, GitLab, Bitbucket)
11. Профессиональные форумы (Stack Overflow, Habr, нишевые)
12. Поисковые системы — Google Dorks + Yandex + DuckDuckGo
13. Базы утечек (HIBP; Intelligence X и DeHashed — платные, дают больший объём данных)
14. Доменные реестры (WHOIS, crt.sh для SSL-сертификатов)
15. Архив (Wayback Machine — удалённые и изменённые страницы)

Блок 4. Анализ артефактов

16. Метаданные файлов — EXIF фотографий, свойства документов
17. Геолокация — GPS из фото, геотеги в соцсетях
18. Временнáя линия — хронология активности по платформам

Блок 5. Верификация и документирование

19. Перекрёстная верификация: каждый вывод подтверждён минимум двумя независимыми источниками
20. Документирование: URL + дата доступа + уровень уверенности для каждого артефакта

Почему именно эти 20 пунктов? Пункт 10 (репозитории кода) — потому что на первом кейсе я его пропустил, а именно там лежал email в коммитах. Пункт 15 (Wayback Machine) — потому что на другом кейсе удалённая страница «О себе» содержала полное имя, недоступное нигде больше. Пункт 19 (верификация) — потому что однажды я приписал два аккаунта одному человеку по совпадению ника, а оказалось — разные люди.

Ошибки новичков в OSINT

Пять ошибок, которые встречаются чаще всего у тех, кто начинает обучение OSINT с нуля:

1. Пропуск репозиториев кода. GitHub — один из самых информативных источников по техническим специалистам. Email в коммитах, коллаборации, starred-репозитории — данных, которых в соцсетях просто нет.

2. Игнорирование баз утечек. По данным HIBP, утечка LinkedIn (2012) содержит 164 миллиона записей. Twitter (утечка опубликована в 2022) — около 6,7 миллиона. Факт присутствия email в утечке даёт связь аккаунта с конкретным сервисом и временным периодом.

3. Отсутствие верификации. Совпадение ника на двух платформах — не доказательство. Без перекрёстной проверки (email + аватар + хронология) есть риск приписать действия одного человека другому. Я на этом обжёгся — см. выше.

4. Забытые метаданные. EXIF-данные фотографий — один из наименее проверяемых источников, при этом содержат GPS-координаты, модель устройства и точное время съёмки.

5. Процесс не фиксируется. Без записи того, что проверено, невозможно понять покрытие. Невозможно и воспроизвести расследование для проверки другим аналитиком. Если через месяц попросят повторить — начнёте с нуля.

Правовое замечание: ФЗ-152 «О персональных данных» (ст. 7) устанавливает конфиденциальность ПДн — то, что данные найдены в открытом доступе, не даёт автоматического права на их распространение. Чек-лист помогает собирать данные структурно, но использование результатов должно оставаться в рамках закона. Для тренировочных кейсов используйте вымышленные ники или специальные CTF-площадки.

Большинство гайдов по OSINT учат инструментам: вот Maltego, вот Shodan, вот пятьдесят ссылок на сервисы. Через неделю новичок знает десять утилит и не может провести одно расследование от начала до конца. Проблема не в незнании maigret или exiftool — проблема в отсутствии дисциплины процесса. На трёх учебных кейсах подряд я проверял одно: результат определяется не количеством инструментов, а наличием списка шагов, по которому идёшь без пропусков. 5 из 12 при хаотичном поиске — типичный результат, не исключение. Чек-лист из 20 пунктов поднимает покрытие до 90%+ при тех же инструментах и том же времени. Попробуйте: возьмите любой учебный ник, пройдите по нему сначала «как обычно», потом по чек-листу — и сравните количество найденных артефактов. Спорим, разница будет не меньше двукратной? Если хотите отработать это на реальных задачах с обратной связью — на курсе IB Basics эту методику разбирают от первых шагов до полноценного кейса.