Как понять, что данные действительно утекли, а не просто напугали

MAATRIX

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

Кто вам пишет и почему это меняет всё дальше

Формулировка письма примерно одинаковая в трёх принципиально разных сценариях, и их стоит различать сразу, потому что дальнейшие шаги для каждого свои.

Независимый исследователь безопасности. Нашёл открытую базу, незащищённый S3-бакет, дыру в API — и сообщает об этом до того, как это нашёл кто-то менее доброжелательный. Обычно пишет спокойно, по делу, без угроз и таймеров, часто указывает точный технический адрес проблемы (URL, эндпоинт, IP) и готов подождать, пока вы исправите. Многие такие исследователи работают в рамках программ bug bounty или просто по этике responsible disclosure — координированного раскрытия, когда информация не публикуется, пока уязвимость не закрыта.

Новость о стороннем сервисе. В СМИ или соцсетях появилось сообщение, что утекла база какого-то сервиса, которым вы или ваши сотрудники пользуетесь (или пользовались) — почтовый рассыльщик, CRM, форум, платёжный агрегатор. Здесь вопрос не «правда ли была утечка» (это обычно уже подтверждённый факт со стороны того сервиса), а «действительно ли там были именно ваши данные и в каком объёме», потому что новости часто масштабируют цифры и не всегда точно называют, какие поля затронуты.

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

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

Не платите и не отвечайте сгоряча

Первая инстинктивная реакция — либо заплатить, чтобы проблема исчезла, либо начать оправдываться и объяснять в ответном письме детали своей инфраструктуры. Оба варианта — ошибка.

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

Ответ с подробностями («у нас PostgreSQL 15, база называется prod_users») тоже вреден: если отправитель блефует и ничего не знает о вашей системе, вы сами дали ему материал, которым можно пугать убедительнее в следующий раз. Достаточно нейтрального ответа («рассматриваем сообщение, пришлите подтверждающие данные») или его отсутствия, пока не собрана техническая картина.

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

Попросите конкретные доказательства, а не общие фразы

Главный водораздел между реальной утечкой и блефом — готовность показать конкретный, проверяемый фрагмент данных. Фразы вида «у нас 500 000 записей ваших пользователей» или «вся ваша база продаётся на форуме» — это утверждение, а не доказательство: такую фразу может написать кто угодно про кого угодно, не имея ни единой реальной строки.

Просите образец — небольшой, но конкретный набор записей, который можно свести к вашей реальной системе. Разумный запрос выглядит так: «пришлите 5–10 полных строк из датасета, включая поля, которых нет в открытых источниках о нашей компании» — например, внутренние идентификаторы, хеши паролей в вашем формате, значения, которые не публикуются на сайте и не гуглятся. Именно уникальные, непубличные поля отличают реальный слепок вашей базы от списка, собранного из открытых источников или чужих утечек.

Признаки того, что перед вами не доказательство, а имитация:

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

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

Сопоставьте образец с реальными системами

Получив образец, не верьте ему на слово — проверьте его напрямую против того, что у вас реально есть или было.

Существуют ли эти записи вообще. Если в образце есть email-адреса или логины, проверьте их прямо в базе:

SELECT id, email, created_at, updated_at
FROM users
WHERE email IN ('sample1@example.com', 'sample2@example.com');

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

Совпадает ли формат хешей паролей. Если вы храните пароли как bcrypt с определённой стоимостью ($2b$12$...), а в образце пароли в открытом виде или в формате MD5 — либо это очень старая утечка (до перехода на текущую схему хеширования), либо данные вообще не ваши. Проверить формат своей текущей схемы легко:

grep -m1 'password_hash' backup_schema_dump.sql

Соответствует ли дата окну, когда эти данные вообще существовали. Если в образце есть пользователь, зарегистрированный позже даты, которую вымогатель называет как момент кражи, — датировка ложная. Сверяйте created_at/updated_at полей с заявленным временем инцидента.

Не пересекается ли это с уже известной утечкой у стороннего сервиса. Частый трюк — взять давно скомпрометированный публичный список email+пароль (собранный из десятков разных старых утечек за прошлые годы) и продать или использовать для шантажа под видом «свежего взлома именно вашей компании». Если пароли в образце совпадают с паролями, которые пользователи явно меняли годы назад, или структура полей не похожа на вашу собственную схему данных — вероятно, вам показывают чужой рециклированный список.

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

Публичные базы утечек: проверка по email и домену

Если утечка похожа на реальную, следующий шаг — понять, не является ли она давно известной и просто заново всплывшей, а не свежим инцидентом именно у вас.

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

• историческую базу для сравнения. Если письмо утверждает, что данные утекли «на прошлой неделе», а точно такой же набор полей и записей уже фигурирует в публичной базе с датой три года назад — вам показывают старую утечку под видом новой;
• список сторонних сервисов, где действительно стоит проверить статус. Если ваш корпоративный домен всплывает в утечке форума или SaaS-сервиса, которым реально пользовались сотрудники, — это повод разобраться, что именно там утекло и требует ли это действий у вас (смена паролей, если они переиспользовались, проверка, не было ли той же комбинации логин-пароль в вашей системе).

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

Типичные признаки мошеннической «утечки»

По совокупности признаков разница между блефом и реальным инцидентом видна довольно быстро. Сведём в таблицу, на что смотреть.

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

Отдельно стоит сказать про схему, которая формально не врёт про факт утечки, но врёт про масштаб: вымогатель раздобыл небольшой фрагмент реальных данных (например, из старой утечки стороннего сервиса, где были и ваши сотрудники) и предъявляет его как доказательство владения «всей вашей базой», хотя реального доступа к вашим системам у него никогда не было. Поэтому важно не просто убедиться, что образец реальный, а сопоставить его объём и происхождение с тем, что технически могло утечь именно у вас.

Если утечка подтвердилась: что дальше

Если проверка показала, что данные реальны, актуальны и совпадают по структуре с вашей системой — дальше это уже не вопрос «правда ли это», а полноценное реагирование на инцидент. Последовательность первых действий — от изоляции скомпрометированного узла до сбора логов до того, как они перезапишутся, — разобрана в материале про план реагирования на инцидент; начинайте с него, а не с того, платить вымогателю или нет.

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

Если утечка подтверждена, но следов фактического использования скомпрометированного доступа пока не видно (например, исследователь сообщил раньше, чем данные попали в публичный доступ), стоит отдельно проверить именно использование, а не только факт существования утечки — это разные вопросы, и подмена одного другим создаёт ложное чувство «пронесло».

Частые вопросы