Что делать после утечки пароля или почты

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

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

Классифицируйте событие до смены секретов

Выберите ветку по наблюдаемым фактам, а не по уровню тревоги. Сохраните безопасную заметку: время, канал, название сервиса и увиденные признаки. Не копируйте пароль, recovery-код, полный номер карты, личную переписку или содержимое breach dump. Для рабочего инцидента сразу используйте внутренний канал и не удаляйте evidence, которое может понадобиться владельцу системы.

В ветке A прочитайте, какие данные действительно затронуты. Утечка адреса email не доказывает утечку пароля. Если раскрыт пароль или хэш, смените этот секрет и все места его reuse. Если пароль уникален и нет evidence of compromise, не начинайте произвольную ротацию остальных уникальных паролей: это отнимает время у более важных проверок.

В ветке B отклоните неизвестный push и не называйте код. Самостоятельно откройте сервис, проверьте список входов и recovery methods, затем укрепите доступ. В ветке C восстановление приоритетно: атакующий может менять настройки одновременно с вами. В ветке D не меняйте credentials на подозрительном устройстве. Отключите удалённую сессию, прекратите платежи и используйте доверенный компьютер или официальную поддержку. Один антивирусный scan не является доказательством полной очистки.

План восстановления по приоритетам

Используйте очередь P0–P4. У каждого действия должны быть владелец, время, статус и краткое evidence выполнения, но не сам секрет. Статусы: NOT_STARTED, IN_PROGRESS, VERIFIED или ESCALATED. Не перескакивайте к социальным сетям, если основная почта всё ещё пересылает сообщения на неизвестный адрес или номер восстановления уже изменён.

P0. Остановите текущий ущерб

Если видите неизвестный платёж, сами откройте приложение банка или используйте официальный номер с его сайта или карты. Не звоните по контакту из сообщения об «утечке» и не используйте предложенный leak checker. Процедуры блокировки и оспаривания зависят от банка и юрисдикции; действуйте по инструкции поставщика. Для рабочего платежа одновременно уведомите утверждённого владельца процесса.

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

P1. Восстановите телефон и основную почту

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

• Удалите неизвестные адреса и номера восстановления, не трогая подтверждённые резервные пути до теста.

• Проверьте forwarding, filters, delegates и правила удаления: атакующий может скрывать ответы или получать копии.

• Посмотрите sent, trash и security events, но не пересылайте чувствительные письма в личный канал без разрешения.

• Завершите неизвестные сессии и отзовите устройства по официальным возможностям сервиса.

• Выполните контрольный вход со второго доверенного устройства и получите уведомление.

Не предполагайте, что смена пароля автоматически закрыла каждую сессию и token: это зависит от провайдера. Некоторые connected apps, app passwords и delegated access продолжают работать отдельно. Используйте текущую официальную страницу безопасности конкретного сервиса. Если recovery flow просит данные, которых у вас нет, не отдавайте секреты случайному «помощнику»; переходите к официальной поддержке и фиксируйте номер обращения.

P2. Верните менеджер, SSO и аккаунты высокого ущерба

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

Для каждого критичного аккаунта меняйте раскрытый или повторно используемый пароль, проверяйте recovery, устройства, сессии и connected apps. Зарегистрируйте сильный фактор и независимый резерв. Не удаляйте старый подтверждённый способ входа до проверки нового. После стабилизации полезно пересобрать систему входа после восстановления волнами, а не возвращайтесь к одному общему паролю.

P3. Закройте повторное использование и побочные пути

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

Проверьте app passwords, API tokens, OAuth connected apps, sessions, delegates, резервные адреса и автоматическую пересылку. Не выполняйте массовое удаление вслепую: рабочий token может поддерживать интеграцию. Сначала определите владельца и назначение, затем отзовите неизвестное или ненужное по официальной инструкции. Для корпоративного аккаунта передайте список администратору и соблюдайте incident procedure.

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

P4. Предупредите людей и разберите причину

Если с захваченного аккаунта ушли сообщения, предупредите контакты независимым каналом. Кратко укажите период и попросите не открывать недавние ссылки и не переводить деньги. Не распространяйте breach dump, персональные данные и скриншоты recovery. Для команды сообщение согласует владелец инцидента, чтобы не разрушить evidence и не нарушить договорные обязанности.

Наблюдайте security events, платежи и recovery notifications в принятом окне, но не превращайте это в бессрочную тревогу. Запишите root cause как подтверждённый факт или гипотезу: reuse, фишинг, захваченная сессия, вредоносное устройство, слабый recovery. Для каждой причины назначьте одно изменение процесса. Если доказательств недостаточно, так и напишите; не приписывайте инцидент конкретному человеку или группе.

Как отличить настоящее уведомление от второй атаки

После публичной утечки часто появляются сообщения, которые используют её название и обещают проверить данные или компенсировать ущерб. Не переходите к recovery по ссылке из такого письма. Самостоятельно откройте официальный сайт провайдера, найдите его security notice и сравните, какие поля затронуты. Если уведомление требует пароль, одноразовый код, удалённый доступ или платёж за «защиту», остановитесь.

Разберите отдельно, отличить настоящее уведомление от второй волны фишинга: знакомый логотип, HTTPS и грамотный текст не подтверждают отправителя. При финансовом вопросе официальный канал банка приоритетнее любого «сервиса проверки». Зарубежные FTC и NCSC дают полезную техническую модель, но их reporting routes и remedies не переносятся автоматически в Россию.

Журнал восстановления без новых секретов

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

Практический следующий шаг

Откройте пустой лист и создайте пять строк P0–P4. В P1 впишите только названия вашей основной почты, номера и доверенного устройства; в P2 — менеджер или SSO и три аккаунта с наибольшим ущербом; в P3 — способ найти reuse; в P4 — двух людей или каналы, которых нужно предупредить. Не записывайте secrets. Сохраните официальные recovery-адреса из independently opened pages.

Если инцидента сейчас нет, проведите настольную репетицию: представьте потерю телефона и проверьте, можете ли найти инструкцию и войти в почту со второго устройства. Если инцидент идёт, не репетируйте и не откладывайте P0 ради идеального журнала. Остановите деньги или доступ, перейдите на доверенное устройство, восстановите корень и только после этого последовательно закрывайте длинный хвост.

Что читать дальше

• пересобрать систему входа после восстановления

• вернуть данные из проверенной копии при повреждении устройства

• отличить настоящее уведомление от второй волны фишинга