Мониторинг утечек данных в Telegram: как обнаружить пробитую базу до публичного слива

67 новых баз данных российских компаний за один квартал — 99,7 миллионов строк с ФИО, паспортами, паролями и телефонами. По данным F6 (отчёт за Q1 2025), столько утечек попало на теневые форумы и в Telegram-каналы с января по март 2025 года. На Telegram приходится порядка 72% всех случаев распространения утекших данных. Основная часть архивов появляется в закрытых чатах за дни или недели до перепродажи на публичных площадках — и именно в этом окне OSINT-мониторинг (разведка по открытым источникам) позволяет обнаружить слив раньше, чем он нанесёт ущерб. Ниже — пошаговый пайплайн, который я использую для мониторинга киберугроз в мессенджерах. Повторить его может любой начинающий аналитик.

Почему Telegram стал главной площадкой для слитых баз данных

Три-четыре года назад основным каналом сбыта слитых данных были даркнет-форумы — площадки в сети Tor с регистрацией по инвайтам и системой репутации продавцов. Сейчас всё иначе. По данным F6, блокировки закрытых Telegram-чатов в 2025 году снизили число публичных утечек на 29% по сравнению с Q1 2024 (95 баз тогда против 67 сейчас), но мессенджер по-прежнему остаётся основной площадкой.

Почему злоумышленники мигрировали из даркнета в Telegram:

• Создать канал или закрытый чат — дело минуты. Не нужен .onion-домен, хостинг, защита от DDoS. Порог входа — ноль.
• Архив, выложенный в канал на 5 000 подписчиков, за часы расползается по десяткам реплик и перепостов. Скорость распространения несопоставима с форумами.
• Закрытые чаты с инвайт-ссылками, которые можно менять, дают минимальную анонимность при максимальном удобстве.
• Боты для «пробива» (поиска данных по номеру телефона, email, ФИО) монетизируют слитые базы прямо внутри мессенджера — покупатель даже не скачивает файл, а получает ответ в чате.

Если смотреть через призму MITRE ATT&CK — это открытая база тактик и техник, которые злоумышленники применяют на разных этапах атаки (каждой технике присвоён T-код, например T1593) — мониторинг утечек в Telegram позволяет наблюдать сразу несколько техник из тактики Reconnaissance (разведка). Атакующий ищет открытые источники данных (T1593 — Search Open Websites/Domains), сканирует базы (T1596.005 — Scan Databases), собирает учётные данные будущих жертв (T1589.001 — Credentials). Всё это — сбор информации о целевой организации до начала атаки: для credential stuffing (подстановки украденных паролей к другим сервисам), фишинга, социальной инженерии. Покупка готовых дампов на теневых площадках описывается техникой T1597.002 (Purchase Technical Data) — она применима, когда атакующий целенаправленно приобретает технические данные о конкретной организации-жертве.

Зачем это знать? Когда вы мониторите Telegram-каналы со сливами, вы буквально наблюдаете фазу разведки противника в реальном времени. Это не абстракция — это рабочий контекст для аналитика.

Анатомия Telegram-архива с пробитыми базами

Combolist, SQL-дамп, скам-репак — три типа архивов

Когда в Telegram-канале появляется пост «Слив базы [компания X] — 2M строк, свежак 2026», за ним обычно стоит один из трёх форматов.

Combolist (от combination list) — текстовый файл, где каждая строка содержит пару email:password или login:password. Иногда через разделитель добавляется URL сервиса-источника. Это основной формат для credential stuffing: такие списки легко прогонять через инструменты автоматизированного перебора.

SQL-дамп — экспорт таблиц реляционной базы данных, обычно MySQL или PostgreSQL. Содержит больше полей: ФИО, даты рождения, телефоны, адреса, хеши паролей, внутренние идентификаторы. SQL-дампы ценнее для злоумышленника — они позволяют строить цепочки идентификации конкретного человека (в ATT&CK это T1589 — Gather Victim Identity Information).

Скам-репак — переупакованный или частично сфабрикованный архив, выдаваемый за свежую утечку. Содержит данные из старых публичных сливов, перемешанные или дополненные мусором. По моим наблюдениям, доля скам-репаков в Telegram-каналах — от 30% до 50%, и процент растёт.

Отличить реальный слив от скам-репака можно по нескольким маркерам:

Дедупликация — первый фильтр подлинности

Дедупликация (удаление повторяющихся строк) — простейший способ оценить «свежесть» архива. Если после удаления дублей из файла в 2 миллиона строк осталось 800 тысяч — перед вами с высокой вероятностью компиляция из нескольких старых баз.

Для быстрой проверки хватит стандартных утилит Linux (нужен терминал: Kali, Ubuntu, WSL на Windows):

sort input.txt | uniq -d | wc -l

sort упорядочивает строки, uniq -d выводит только дублирующиеся, wc -l считает их количество. На выходе — одно число. Если оно больше 30% от общего числа строк (wc -l input.txt), архив подозрителен. Утилита breach-parse (доступна на GitHub) делает то же самое, но дополнительно разбивает combolist по доменам — удобно, когда нужно вычленить записи конкретной организации.

OSINT мониторинг утечек: пошаговый пайплайн обнаружения

Цель — выстроить автоматизированную цепочку, которая сообщит о появлении нового архива в закрытом Telegram-чате раньше, чем слив попадёт на публичные площадки. Весь пайплайн состоит из трёх этапов: сбор каналов, парсинг с алертами, фильтрация.

Сбор и ранжирование каналов для мониторинга

Первый шаг — составить watchlist каналов и чатов. Где искать:

1. Репозиторий deepdarkCTI на GitHub содержит курируемый список Telegram-каналов и ботов, связанных с утечками. Отправная точка, но далеко не полная картина.
2. В постах о сливах часто упоминаются «дружественные» каналы. Каждое такое упоминание — потенциальный новый источник для watchlist. Не ленитесь проходить по цепочке.
3. Боты-индексаторы утечек (встречаются в тематических OSINT-подборках) индексируют утечки с BreachForums и позволяют искать по email или паролям. Они полезны как индикатор: если бот уже знает о конкретном сливе — архив стал публичным и окно раннего обнаружения закрылось.

Ранжируйте каналы по приоритету: — Высокий — закрытые чаты с подтверждённой историей первичных публикаций (каналы, где сливы появляются впервые) — Средний — каналы-реселлеры, перепубликующие из первичных источников в течение часов — Низкий — публичные агрегаторы-новостники, описывающие утечки постфактум

Парсинг через Telethon: делай раз, делай два, делай три

Telethon — Python-библиотека для работы с Telegram API. Позволяет подписаться на каналы и получать сообщения программно, без ручного мониторинга. Альтернатива — Pyrogram с похожими возможностями.

Что понадобится: Python 3.8+, установленный пакет (pip install telethon), API-ключи Telegram (получаются бесплатно на my.telegram.org после регистрации приложения — потребуется номер телефона).

Делай раз — создаём слушатель, который отлавливает сообщения с ключевыми словами:

from telethon import TelegramClient, events

api_id = 12345          # ← замените на свой API ID с my.telegram.org
api_hash = 'your_hash'  # ← замените на свой API Hash
channel_list = ['channel1', 'channel2']  # ← юзернеймы или ID каналов

client = TelegramClient('session', api_id, api_hash)
keywords = ['слив', 'база', 'дамп', 'leak', 'combo', 'breach']

@client.on(events.NewMessage(chats=channel_list))
async def handler(event):
    text = event.raw_text.lower()
    if any(kw in text for kw in keywords):
        print(f"[ALERT] {event.chat.title}: {text[:200]}")

client.start()
client.run_until_disconnected()

Что произойдёт: скрипт подключится к Telegram от имени вашего аккаунта, подпишется на каналы из channel_list и при каждом новом сообщении проверит, содержит ли текст одно из ключевых слов. Если да — выведет алерт с названием канала и первыми 200 символами. В терминале вы увидите строки вида [ALERT] ChannelName: новый слив базы ....

Делай два — заполните channel_list юзернеймами каналов из вашего watchlist. Для закрытых чатов нужно сначала вступить вручную (через инвайт-ссылку) — Telethon работает от имени вашего аккаунта, а не отдельного бота.

Делай три — добавьте персистентность. Замените print на отправку в приватный Telegram-канал или webhook (Slack, Mattermost). Для полноценного поиска по истории сообщений подключите запись в Elasticsearch или простой SQLite. Это критично: Telegram позволяет удалять сообщения, и парсер, работающий 24/7, перехватывает их до удаления. Без постоянного парсинга эти данные теряются безвозвратно — поэтому, например, в описании F6 Threat Intelligence отдельно подчёркивается доступ к удалённым и изменённым сообщениям.

Фильтрация: отделяем шум от сигнала

В активном мониторинге из 100 сработок 70-80 — ложные: реклама каналов, обсуждения старых сливов, скам-предложения. Что реально работает:

• Размер вложения. Реальные дампы — файлы от десятков мегабайт. Пост без вложения или со ссылкой «скачать за $50» — чаще продажа или фейк.
• Домен организации. Фильтруйте по конкретным доменам (@company.ru), если мониторите утечки определённых компаний.
• Формат файла. .sql, .csv, .txt — типичные форматы дампов. .exe и .rar с паролем — почти гарантированно вредонос или скам.

Инструменты OSINT для валидации утечек

Обнаружили подозрительный архив — как подтвердить, что это реальный слив, а не перепакованный мусор? Вот цепочка проверок, которую я провожу на каждом обнаруженном дампе.

Выборочный breach-check. Берёте 10-20 email-адресов из архива и проверяете через публичные сервисы:

• Have I Been Pwned (haveibeenpwned.com) — бесплатная проверка по email, покрывает крупные публичные утечки. Если все проверенные адреса уже фигурируют в старых сливах (например, Twitter 2022 на ~6,68 млн записей или START на ~7,46 млн записей из российского стримингового сервиса) — перед вами, вероятно, компиляция.
• DeHashed (dehashed.com) — платный сервис с поиском по email, телефону, хешу пароля, IP-адресу. Показывает, в каких конкретно утечках фигурировал адрес — помогает определить первоисточник.
• Intelligence X (intelx.io) — архив данных с поиском по селекторам (email, домен, Bitcoin-адрес). Полезен для отслеживания, когда и где конкретный набор данных впервые появился в открытом доступе.

Hash-сверка паролей. Если в дампе пароли хранятся в виде хешей — проверьте консистентность алгоритма. В реальной утечке из одного сервиса все хеши будут одного типа (например, bcrypt с одинаковой cost-настройкой или SHA-256). Перемешанные MD5, SHA-1 и bcrypt в одном файле — верный признак компиляции из разных источников. Для определения типа хеша подойдёт hashid (ставится через pip install hashid, в Kali есть из коробки) или более активно поддерживаемая name-that-hash (pip install name-that-hash).

Раннее обнаружение дата-ликов: окно до публичного слива

Threat Intelligence (разведка угроз) в контексте утечек работает с концепцией «окна обнаружения» — промежутка между моментом, когда архив впервые появляется в закрытом канале, и моментом публичной доступности. Типичный путь архива:

1. Первичный канал (закрытый чат на 50-500 участников) — предпродажа или «тестовый» слив: выкладывается часть базы для подтверждения подлинности.
2. Реселлеры — каналы-перекупщики, покупающие архив и перепродающие его шире.
3. Публичная площадка (BreachForums, Doxbin и подобные) — архив становится общедоступным.
4. Новостные каналы (Telegram-каналы типа «Утечки информации», профильные СМИ) — описывают слив как новость.

Задача OSINT-мониторинга — обнаруживать на первом или втором этапе. Для понимания масштаба: по данным HIBP, в январе 2025-го из Doxbin были извлечены 435 тысяч email-адресов — информация сначала появлялась в ограниченных кругах и лишь потом попадала в публичные базы.

Как это ложится в рамку NIST CSF (фреймворк управления кибербезопасностью от NIST — Национального института стандартов и технологий США): функция Detect → DE.AE-01 предполагает установление базовых ожиданий и обнаружение отклонений, а Respond → RS.AN-01 требует расследования уведомлений от систем обнаружения. Мониторинг Telegram — внешний слой детекции, дополняющий внутренние SIEM (системы сбора и корреляции событий безопасности) и DLP (системы предотвращения утечек данных). OWASP в категории A09:2021 (Security Logging and Monitoring Failures) прямо указывает: без логирования и мониторинга утечки невозможно обнаружить. Внешний мониторинг через OSINT закрывает тот слой, который внутренние системы не видят по определению — то, что о вас говорят и продают снаружи.

Правовые рамки OSINT-мониторинга в России

Мониторинг Telegram-каналов — работа с открытыми источниками, но границы нужно понимать чётко, чтобы не перейти из аналитика в фигуранта.

Допустимо: — Подписываться на публичные каналы и читать сообщения — это открытая информация — Автоматизировать сбор сообщений из каналов, в которых вы состоите — Проверять отдельные email-адреса через HIBP и аналогичные сервисы

Рискованно или запрещено: — Скачивать и хранить полные базы с персональными данными — нарушение ФЗ-152 «О персональных данных» (обработка ПДн без согласия субъекта и без законного основания; ст. 10 устанавливает особый режим для специальных категорий — здоровье, убеждения, судимости) — Использовать данные из утечек для идентификации конкретных лиц вне рамок расследования — могут применяться статьи УК РФ, включая ст. 137 и 272 (для точной квалификации нужна консультация юриста) — Покупать утекшие базы — участие в незаконном обороте персональных данных

На практике: обнаружили утечку, затрагивающую конкретную организацию — передайте информацию в службу ИБ этой организации или в НКЦКИ (национальный координационный центр по компьютерным инцидентам). Не храните дамп «на всякий случай» — даже с благими намерениями это создаёт правовые риски.

Последние полтора года я наблюдаю одну и ту же картину: компании тратят миллионы на внутренние DLP-системы, но узнают о сливе собственных данных из новостного Telegram-канала — спустя дни после того, как архив разошёлся по закрытым чатам. Проблема не в технологиях. DeHashed, HIBP, Telethon-скрипт на десять строк — всё это доступно бесплатно или за символические деньги. Проблема в том, что мониторинг внешнего периметра — того, что о вас говорят и продают в теневом сегменте — до сих пор не считается обязательной практикой. Это как ставить сигнализацию внутри дома, но не проверять, продаётся ли ваш адрес в списке «свободных» квартир у скупщиков.

По данным отчёта F6 за 2024 год, было зафиксировано 455 ранее неопубликованных баз данных российских и белорусских компаний — свыше 457 миллионов строк. Это только обнаруженные. Мой прогноз: через год-два внешний threat intelligence по утечкам станет обязательным элементом ИБ-процесса наравне с vulnerability management. Организации, которые этого не сделают, продолжат узнавать о проблемах из прессы. Если хочешь разобраться в мониторинге и threat intelligence системно, а не собирать знания по кускам из статей — на codeby.school есть IB Basics, который закрывает базу от терминологии до первых рабочих задач за пару месяцев.