Если домен украли и перевели к другому регистратору, действуйте как при инциденте доступа и одновременно как при споре о трансфере. Сначала зафиксируйте текущее состояние реестра: точное имя, зону, registrar of record, даты регистрации и изменения, статусы, name servers, DNSSEC, контактные сведения или факт их сокрытия. Затем сохраните прежние счета, договор, уведомления, исторические WHOIS/RDAP, письма о выдаче AuthInfo или transfer authorization и журналы кабинета. Не смешивайте четыре события: смену регистратора, смену администратора или registrant, изменение DNS и простую потерю доступа к хостингу. Для .RU/.РФ применяются российские правила и процедуры аккредитованных регистраторов; ICANN и TDRP относятся к gTLD вроде .com и не возвращают российское имя. Срочно откройте кейс у прежнего регистратора, уведомите принимающего, попросите сохранить transfer-логи и запретить дальнейшие изменения, если это возможно. Параллельно защитите независимую почту, телефон и учётные записи, но не удаляйте письма и сессии до выгрузки следов. Не сообщайте AuthInfo, пароль, одноразовый код или recovery-фразу посреднику, обещающему мгновенный возврат. Ниже — маршрут для пострадавшего в РФ без гарантии результата: от снимка реестра до регламентного спора, заявления и расчёта ущерба.
Коротко
Первые часы нужны для фиксации реестра, блокирования следующего изменения и открытия одного согласованного кейса у всех участников трансфера.
- Сохраните текущий и прежний RDAP/WHOIS, registrar of record, статусы, DNS, уведомления, счета и точное время обнаружения.
- Защитите независимую почту, телефон и кабинет, завершите чужие сессии после выгрузки журналов и не раскрывайте AuthInfo или коды.
- Немедленно обратитесь к прежнему регистратору, уведомите принимающего и попросите сохранить авторизацию, историю изменений и платёжные следы.
- Разделите маршрут .RU/.РФ и gTLD, затем выберите регламентный спор, заявление об инциденте, судебные меры и расчёт ущерба.
Не начинайте с покупки имени обратно у неизвестного лица. Сначала выясните, действительно ли произошёл transfer, кто сейчас поддерживает запись и какие действия ещё можно остановить.
Угон домена отличается от сбоя DNS
Прямой ответ: похищение регистрации устанавливают по смене контролирующего лица или registrar of record, а не по недоступности сайта.
Сайт может исчезнуть из-за хостинга, сертификата, DNS-зоны или ошибки приложения, хотя домен остаётся в прежнем кабинете. При смене name servers атакующий способен направить трафик на другой сервер без межрегистраторного переноса. При замене MX он перехватывает почту. И лишь изменение регистратора или администратора затрагивает реестровую поддержку и право управления записью.
Сделайте четыре строки: регистрация, DNS, хостинг, почта. В каждой укажите прежнего провайдера, текущий статус, время изменения и доказательство. Если украденный домен всё ещё числится у старого регистратора, TDRP не нужен; срочность остаётся, но это account takeover. Если registrar of record уже другой, добавляется transfer-ветка. Такая классификация экономит часы и не даёт провайдерам пересылать пострадавшего по кругу.
Таблица инцидента определяет первого адресата
Прямой ответ: наблюдаемый симптом нужно связать с уровнем инфраструктуры, иначе требование попадёт не той организации.
| Что изменилось | Что это может означать | Кому писать сначала | Что сохранить |
|---|---|---|---|
| Registrar of record | Межрегистраторный transfer | Прежнему и принимающему регистраторам | RDAP/WHOIS, уведомления, authorization |
| Registrant или администратор | Смена правообладателя записи или данных | Текущему регистратору | Исторические данные, договор, идентификация |
| Name servers, A или MX | Захват DNS без transfer | Регистратору и DNS-провайдеру | Зону до и после, TTL, время изменения |
| Файлы сайта | Компрометация хостинга | Хостеру | Логи, резервные копии, учетные записи |
| Только дата окончания | Просрочка или lifecycle | Регистратору по договору продления | Счета, напоминания, статусы и платежи |
Один инцидент может затронуть несколько строк. Например, сначала похищают почту, затем получают transfer-код и меняют MX. Доменная хронология должна сохранять порядок, а не только финальный экран.
Для пострадавших по всей РФ доступен бесплатный дистанционный разбор первичной карты; он проводится без гарантий возврата имени или срока реакции регистратора. Получить консультацию
Зона верхнего уровня задаёт процедуру
Прямой ответ: перед первым обращением установите, относится имя к .RU/.РФ, другому ccTLD или gTLD под политиками ICANN.
Окончание .RU и .РФ указывает на российскую систему регистрации и её аккредитованных регистраторов. Для национальной зоны другой страны действуют правила соответствующего реестра. Адреса .com, .net, .org и многие новые зоны обычно находятся в gTLD-контуре, где важны ICANN Transfer Policy и действия аккредитованных registrars. Нельзя подавать TDRP для .RU только потому, что интерфейс нового провайдера зарубежный.
Запишите полное имя вместе с точкой и зоной. Для портфеля сделайте отдельную строку на каждое имя: атака могла перенести один адрес и лишь изменить DNS у остальных. Если украденный домен находится у реселлера, всё равно определите реестр и аккредитованного registrar of record. Коммерческий бренд в счёте не всегда совпадает с участником реестровой процедуры.
Первые тридцать минут посвящают фиксации
Прямой ответ: до исправлений нужен снимок состояния, который не исчезнет после блокировки аккаунта или отката записи.
Откройте реестровый сервис для соответствующей зоны и сохраните полный ответ с датой и часовым поясом. Зафиксируйте страницы кабинета, но закройте секреты на копии для передачи. Скачайте письма о входе, смене контактов, запросе ключа и завершении transfer в исходном формате с техническими заголовками. Запишите номер телефона, с которого пришло сообщение, не отвечая на него.
После этого открывайте срочный тикет об угоне домена. Не тратьте время на идеальное юридическое письмо: первая задача — сообщить точное имя, прежнего администратора, время обнаружения и запрет дальнейших операций. Подробный пакет можно дослать по номеру кейса. Если домен уже оказался у третьего регистратора после ещё одного переноса, сохраните каждый промежуточный след и укажите, что последующие действия оспариваются вместе с первым.
RDAP и WHOIS сохраняют как полный ответ
Прямой ответ: строка с названием регистратора полезна только вместе со статусами, датами, name servers и источником выдачи.
Экспортируйте текст или PDF, оставив видимыми URL запроса и время. Для gTLD отметьте registry domain ID, registrar IANA ID, даты creation, updated и expiry, EPP statuses, DNSSEC и nameservers. Для российской зоны сохраняйте доступные поля администратора, регистратора, состояние и срок. Если публичные персональные данные скрыты, так и напишите; не подставляйте имя предполагаемого злоумышленника.
Сделайте контрольную копию на независимом носителе. Скрин может обрезать длинный статус, а поздний онлайн-запрос уже покажет откат. Украденный домен часто меняется несколько раз за день, поэтому повторяйте снимок после каждого уведомления регистратора. Разница между двумя ответами формирует журнал реестровых событий, но не объясняет авторизацию без внутренних логов.
Историческое состояние собирают из собственных документов
Прямой ответ: прежняя запись убедительнее, когда её подтверждают не один архивный сервис, а счета, договор и уведомления регистратора.
Найдите первоначальный заказ, счета за продление, акты, банковские платежи, договор с реселлером, анкеты идентификации и письма с прежними контактами. В корпоративном деле добавьте решение о назначении ответственного, доверенность и внутренний реестр цифровых активов. Сохраните прежние DNS-зоны и сертификаты, но не выдавайте их за самостоятельное право администрирования.
Если домен оплачивал сотрудник личной картой, установите, от чьего имени заключался договор и чьи данные находились в реестре. Платёж доказывает финансирование, но не всегда статус администратора. Если имя когда-то переоформляли, приложите документ передачи. Пробел в цепочке нужно обозначить честно, иначе регистратор увидит конфликт личности там, где пострадавший описывает простой угон.
Хронология ведётся в одном часовом поясе
Прямой ответ: минуты между сменой почты, выдачей кода и завершением transfer могут показать способ атаки.
Выберите UTC или явно указанное местное время и приведите все события к нему, сохранив исходное значение. Внесите последний собственный вход, первое неизвестное уведомление, изменение recovery email, запрос AuthInfo, письмо подтверждения, смену регистратора, name servers, MX и обращение в поддержку. Рядом укажите источник: заголовок письма, лог, реестровый ответ или банковская операция.
Не исправляйте старые строки без истории версий. Если время письма отличается от события в реестре, оставьте обе отметки и объясните возможную задержку доставки. Украденный домен восстанавливают по последовательности действий разных систем; единая шкала позволяет прежнему регистратору искать точный лог, а следователю — связать доступ к почте с последующим переносом.
Registrar of record отличается от реселлера
Прямой ответ: пользовательский кабинет может принадлежать продавцу услуги, тогда как реестровую запись поддерживает другая аккредитованная компания.
Определите registrar of record по текущему и прежнему RDAP/WHOIS. Затем свяжите его с реселлером из счёта: укажите номер договора, customer ID и ticket ID. Реселлер может располагать логами входа и общения, но только участники реестрового контура способны выполнять предусмотренные transfer-действия. Письмо одному бренду без выяснения роли иногда теряется между линиями поддержки.
В обращении не обвиняйте каждого участника одинаково. У реселлера просите кабинетные логи и сведения о запросе. У прежнего регистратора — review авторизации и сохранение transfer evidence. У нового — блокировку последующих изменений, если его правила позволяют, и сохранение своей части документов. Реестр получает запрос в пределах собственной процедуры. Доменное имя одно, но обязанности распределены.
Смена администратора отличается от смены регистратора
Прямой ответ: transfer может сохранить registrant, а переоформление права способно произойти без смены registrar of record.
Сравните оба поля на контрольных датах. Если регистратор прежний, но данные администратора стали чужими, основной вопрос — кто и на каком основании изменил registrant или сведения в реестре. Если администратор прежний, а registrar новый, исследуется межрегистраторная авторизация. Если изменились оба, потребуйте разложить операции по времени и документам: одновременная карточка не показывает последовательность.
Публичное скрытие контактов privacy-сервисом не равно смене лица. Также обновление email может быть обычной верификацией. Нужны внутренние сведения регистратора и прежние документы. Украденный домен нельзя доказать только тем, что WHOIS перестал показывать фамилию: зафиксируйте фактическую потерю кабинета, неизвестную заявку и отсутствие согласия на конкретное действие.
Изменение name servers может предшествовать transfer
Прямой ответ: DNS-захват способен украсть трафик и почту ещё до завершения реестрового переноса.
Сохраните прежние и текущие NS, A/AAAA, CNAME, MX, TXT и DS, время наблюдения и TTL. Попросите DNS-провайдера выгрузить историю изменений и пользователя, выполнившего операцию. Не начинайте массово менять записи до снимка: откат нужен, но он не должен уничтожить единственный след. Работы проводит уполномоченный администратор через известный кабинет.
Если name servers уже у злоумышленника, предупредите команду, что сайт и письма с привычного адреса недостоверны. После возврата управления проверьте всю зону, а не только главную A-запись. Домен мог вернуться к прежнему регистратору, но MX или TXT остались изменёнными. Восстановление registration и восстановление DNS завершаются разными контрольными проверками.
Подмена MX создаёт риск ложных счетов
Прямой ответ: при перехвате корпоративной почты нужно защищать не только запись, но и клиентов, банк и внутренние процессы согласования.
Зафиксируйте текущие MX и почтовые TXT-записи, затем сохраните примеры подозрительных писем в исходном формате. Уведомите сотрудников и контрагентов через заранее подтверждённые независимые каналы: телефон из договора, официальную соцсеть или резервный адрес, который существовал до атаки. Не просите клиентов переходить по новой ссылке из скомпрометированного ящика.
Если деньги ушли по поддельным реквизитам, банковская ветка начинается немедленно и не ждёт возврата домена. Сохраните счёт, заголовки, переписку, платёж и данные получателя. В расчёте не смешивайте такую потерю с ценой сайта: у неё собственная причинная цепочка. Реестровый спор помогает объяснить инструмент атаки, но не отменяет срочного обращения в банк.
Хостинг проверяют отдельно от регистрации
Прямой ответ: возвращённая реестровая запись не восстанавливает удалённые файлы, базы, сертификаты и ключи приложения.
Установите, использовал ли хостинг тот же пароль или почту, что registrar. Сохраните журналы доступа, список пользователей, резервные копии, время изменения файлов и уведомления панели. После фиксации отзовите неизвестные сессии и токены, смените ключи через штатные интерфейсы и восстановите сайт из проверенной копии. Не выполняйте команды, присланные неизвестным «администратором».
При статичной подмене главной страницы домен может быть невиновен. При полном transfer старый хостинг, напротив, иногда остаётся под контролем владельца и служит источником доказательств. В итоговой папке держите две ветки: реестровую и серверную. Это помогает сформулировать точные требования и не приписывать регистратору удаление данных, которого его система не выполняла.
Для .RU и .РФ доменный трансфер использует AuthInfo
Прямой ответ: секретный ключ и способ его получения становятся центральными доказательствами несанкционированного переноса в российской зоне.
Официальная инструкция REG.RU по переносу .RU/.РФ описывает AuthInfo как секретный ключ, который получают у текущего регистратора и передают принимающему. Заявка может обрабатываться до трёх рабочих дней, ключ действует 20 календарных дней и по умолчанию направляется на email администратора; контакты должны совпадать с данными записи.
В деле спросите: кто запросил ключ, из какого аккаунта, куда его отправили, когда он был создан и использован, проверялись ли регистрационные данные. Не прикладывайте сам действующий AuthInfo к общему письму и не публикуйте его. Если административная почта находилась на похищенном домене, обозначьте замкнутый риск: атакующий мог контролировать канал доставки ещё до transfer.
Ограничения переноса помогают проверить аномалию
Прямой ответ: даты и registry restrictions показывают, мог ли обычный transfer пройти по опубликованной процедуре.
REG.RU перечисляет случаи невозможности переноса .RU/.РФ: истечение регистрации, первые 30 дней после получения права администрирования, первые 30 дней после предыдущей смены регистратора, семь дней до окончания срока, неисполненный запрос документов и ограничения в реестре. Сопоставьте каждое условие с фактическими датами. Если transfer завершён вопреки видимому ограничению, включите это как отдельный вопрос, не объявляя заранее причину.
Эти интервалы не являются универсальной блокировкой на любой инцидент и не заменяют актуальные правила. Они также не доказывают добровольность операции, если формально срок соблюдён. Украденный домен мог быть перенесён с корректным ключом, полученным через скомпрометированную почту. Поэтому календарь дополняет, но не подменяет журналы выдачи AuthInfo и идентификацию заявителя.
Прежний регистратор получает первое срочное обращение
Прямой ответ: именно у него находились исходные учётные данные и информация о том, как началась передача поддержки.
В теме письма укажите UNAUTHORIZED TRANSFER, точное имя и дату обнаружения. В первых строках сообщите прежнего администратора, customer ID, последний законный вход и отсутствие согласия. Попросите присвоить incident number, провести review, сохранить записи кабинета, обращения, выдачу AuthInfo или authorization, IP, user agent, время, способ MFA и историю контактов. Отдельно попросите сообщить, может ли registrar установить ограничение на дальнейшее перемещение.
Не прикладывайте хаотичный архив. Дайте краткую хронологию и индекс файлов. Если поддержка требует идентификацию, уточните официальный защищённый канал и перечень документов. Для gTLD прямо спросите, готов ли losing registrar связаться с gaining registrar и оценить TDRP. Для .RU/.РФ попросите назвать применимый российский регламент. Домен возвращает не эмоциональная формулировка, а проверяемая связь аккаунта, авторизации и реестрового события.
Принимающего регистратора уведомляют параллельно
Прямой ответ: новый участник должен узнать об оспаривании до следующей смены данных или ещё одного transfer.
Отправьте номер кейса прежнего регистратора, текущий RDAP/WHOIS, прежние сведения и краткое заявление об отсутствии согласия. Попросите сохранить поступившую авторизацию, платёж, данные аккаунта, коммуникации и дальнейшие изменения; уточните, доступен ли временный lock в рамках его правил и закона. Не требуйте раскрыть персональные данные неизвестного клиента по обычной почте — запросите сохранение и передачу по надлежащей процедуре.
Если новый registrar отвечает, что общается только с losing registrar, перенаправьте ответ в основной кейс. Не создавайте разные версии хронологии. Украденный домен может находиться в privacy-профиле, но внутренние доказательства всё равно существуют. Параллельное уведомление нужно не для самовольного доступа пострадавшего к чужому кабинету, а для остановки дальнейшей цепочки и сохранения материала.
Для gTLD ICANN направляет к прежнему registrar
Прямой ответ: ICANN объясняет маршрут, но не имеет полномочий самостоятельно переписать запись на заявителя.
На странице ICANN About Lost Domain Names прямо сказано: если имя без разрешения перешло к другому registrar и больше не управляется прежним registrant, следует немедленно обратиться к предыдущему registrar и попросить review unauthorized transfer. Регистраторы в отдельных случаях могут отменить transfer с учётом обстоятельств и применимого права, но ICANN не приказывает им сделать это напрямую.
Та же страница отличает изменение WHOIS без разрешения, истечение регистрации, удаление и новый registrant. Используйте её как карту вопросов, а не форму возврата. Если украденный домен относится к .RU/.РФ, рекомендация ICANN не меняет национальную процедуру. Если это .com, сохраните ответ ICANN и приложите его к просьбе прежнему registrar инициировать межрегистраторную проверку.
TDRP является спором между регистраторами
Прямой ответ: registrant передаёт факты losing registrar, а complaint подаёт один из регистраторов, не сам владелец кабинета.
Действующая страница Registrar Transfer Dispute Resolution Policy определяет complainant как losing registrar при предполагаемом мошенническом transfer либо gaining registrar при improper NACK. Политика предлагает сначала попытаться урегулировать вопрос между registrars, а затем обращаться к провайдеру разрешения спора. Результат может включать возврат записи к registrar, который поддерживал её до invalid transfer.
Поэтому письмо пользователя должно быть пригодно для чужой complaint: точное имя, события, основание нарушения, требуемый результат, известные производства и индекс доказательств. Попросите losing registrar письменно сообщить решение о запуске или отказе. TDRP не решает спор о товарном знаке и не устанавливает уголовную ответственность; его предмет — соответствие межрегистраторного transfer применимой политике.
Актуальная оговорка TDRP меняет оценку FOA
Прямой ответ: отсутствие стандартной формы авторизации нельзя автоматически выдавать за основание возврата без проверки текущего policy notice.
Страница TDRP сообщает, что enforcement требования gaining registrar получать express authorization через Standardized Form of Authorization отложен, а одно отсутствие FOA не должно само по себе приводить к reversal по указанному разделу. Там же отмечена публикация обновлённой версии 21 февраля 2024 года для Registration Data Policy. В деле фиксируйте версию, действующую на дату complaint, и просите registrar объяснить применённую норму.
Это не означает, что любая передача законна. Остаются другие доказательства: реестровые данные на момент запроса, история изменений, личность, коммуникации, lock и последовательность transfer. Украденный домен нельзя возвращать по устаревшему чек-листу из форума. Юридически значима совокупность фактов и действующая политика, а не название одного отсутствующего файла.
Предельный срок TDRP не заменяет срочность
Прямой ответ: двенадцать месяцев — крайняя граница подачи inter-registrar dispute, а не рекомендованный срок ожидания.
TDRP указывает, что спор подаётся не позднее 12 месяцев после предполагаемого нарушения Transfer Policy; для жалобы losing registrar точкой отсчёта считается завершение transfer. Запишите эту дату отдельно и попросите registrar подтвердить её. Но логи поддержки, почты и security events могут храниться гораздо меньше, а злоумышленник способен инициировать последующие перемещения.
Открывайте кейс в день обнаружения. Если прошло несколько месяцев, не отказывайтесь от обращения: объясните, когда и как узнали об изменении, и предоставьте доступные документы. Если срок TDRP истёк, остаются договорные и судебные варианты, которые оцениваются отдельно. Доменное имя не возвращается автоматически из-за соблюдения календаря; срок лишь сохраняет один из процессуальных маршрутов.
Пакет для межрегистраторной проверки индексируют
Прямой ответ: registrar быстрее оценит transfer, если каждый файл отвечает на конкретный элемент policy.
Сформируйте оглавление: текущий и прежний RDAP/WHOIS; история registrant и contacts; письма transfer; данные AuthInfo или authorization без раскрытия действующего секрета; подтверждение личности; договор и счета; логи доступа; переписка двух registrars; сведения о lock; параллельные судебные или административные дела. В отдельной таблице свяжите файл, дату и утверждение, которое он подтверждает.
TDRP перечисляет среди материалов WHOIS на дату инициирования, историю изменений, authorization, доказательство личности и коммуникации. Конкретный набор формирует registrar с учётом актуальной версии. Не редактируйте исходники; для передачи создавайте копии с маскированием избыточных данных. Если украденный домен переходил несколько раз, индексируйте каждый transfer отдельно, показывая общий первичный инцидент.
Право администрирования доказывает цепочка
Прямой ответ: один платёж за продление полезен, но сильнее связка договора, реестровых данных, идентификации и длительного управления.
Для физического лица соберите договор, прежние контакты, документы, которыми подтверждались данные, счета и сообщения регистратора. Для компании добавьте карточку организации, полномочия сотрудника, внутреннее назначение администратора и бухгалтерские документы. Для приобретённого имени приложите соглашение о передаче и подтверждение переоформления. Если платил подрядчик, объясните его роль.
Контент сайта, реклама и бренд показывают использование, но не заменяют статус registrant. Товарный знак может поддерживать отдельное требование к злоумышленнику, однако сам по себе не доказывает unauthorized transfer. Украденный домен возвращают тому, чья цепочка соответствует правилам и фактам, а не обязательно самому известному пользователю адреса. Не скрывайте корпоративный конфликт за формулировкой о хакере: регистратор всё равно проверит полномочия.
Для .РФ сохраняют Unicode и ASCII-представление
Прямой ответ: два технических написания должны указывать на одну запись, чтобы в заявлении и приложениях не возник другой объект.
Запишите привычное кириллическое имя и его ASCII-форму, которую показывает реестр или registrar. Скопируйте значение из официального интерфейса, не набирая вручную похожие символы. В названии файлов используйте оба представления и дату. Если в письме фигурирует только короткий бренд, добавьте полную строку с зоной.
Проверьте визуальные омографы: латинская и кириллическая буква могут выглядеть одинаково, хотя это разные имена. Иногда пользователь считает украденным домен, а злоумышленник зарегистрировал похожий адрес и разослал фишинг. Тогда реестровый transfer отсутствует, а маршрут меняется. Точное техническое имя защищает от этой ошибки и помогает registrar искать нужную запись без догадок.
Связанные аккаунты защищают без уничтожения следов
Прямой ответ: сначала выгружают доступные события, затем отзывают чужие сессии и меняют секреты через официальные настройки.
Начните с независимой почты и телефона восстановления, особенно если административный ящик находился на похищенном адресе. Сохраните security alerts, список сессий, изменения MFA, правила пересылки и recovery contacts. После фиксации завершите неизвестные сессии, задайте уникальные пароли, включите устойчивую многофакторную защиту и отзовите лишние API-токены. Проверьте компьютер уполномоченным специалистом.
Не удаляйте почтовый ящик, аккаунт registrar или переписку. Не устанавливайте утилиту удалённого доступа по ссылке из чата. AuthInfo храните как секрет и запрашивайте новый только через подтверждённый процесс, если это требуется. Украденный домен часто является следствием компрометации почты; возврат записи без устранения первичного доступа оставляет путь для повторной атаки.
Аварийная страница должна быть подтверждена заранее известным каналом
Прямой ответ: временный адрес помогает клиентам только тогда, когда его подлинность можно проверить независимо от захваченной почты.
Используйте корпоративный профиль в социальной сети, номер телефона из договора, приложение или другой канал, существовавший до инцидента. Сообщите кратко: старый сайт и письма временно недостоверны, платежные реквизиты не менялись либо будут подтверждаться отдельно, новые инструкции публикуются здесь. Не раскрывайте детали расследования, которые помогут атакующему.
Приобретение запасного имени не является возвратом украденного домена и не должно задерживать обращения registrars. Сохраните расходы на аварийный адрес и перенос как возможный ущерб. После восстановления не выключайте предупреждение мгновенно: проверьте DNS-кэш, сертификат, MX и поисковые ссылки. Клиенты должны получить понятную контрольную дату, с которой старый адрес снова считается доверенным.
Платежи по поддельным письмам выделяют в отдельную ветку
Прямой ответ: возврат реестровой записи не отзывает уже исполненный банковский перевод злоумышленнику.
Если клиент или бухгалтер оплатил фальшивый счёт, немедленно сообщите банкам отправителя и получателя, сохраните распоряжение, реквизиты, назначение и время. Приложите исходное письмо с заголовками и снимок MX на тот момент. Укажите, кто обычно согласовывал изменение реквизитов и какой контроль был обойдён. Не ждите ответа registrar, поскольку банковские действия чувствительны ко времени.
В общей хронологии свяжите события, но в требованиях не смешивайте их. К registrar обращаются о transfer и логах; к банку — о конкретной операции; в заявлении описывают несанкционированный доступ и ущерб. Украденный домен объясняет канал обмана, однако размер потери доказывают платёжные документы и коммуникация с потерпевшим плательщиком.
Требование о возврате домена содержит точное действие
Прямой ответ: просьбу «верните всё как было» заменяют перечнем реестровых, доказательственных и коммуникационных мер.
Укажите полное имя, зону, прежнего и текущего registrar, registrant до события, даты, номер основного кейса и отсутствие согласия. Попросите: признать transfer оспариваемым; провести review применимой авторизации; сохранить логи и документы; установить допустимый lock против последующих действий; связаться со вторым registrar; сообщить выбранный регламент и контрольный срок. Для .RU/.РФ добавьте запрос о выдаче и использовании AuthInfo; для gTLD — вопрос о TDRP.
В денежной части [ФИО] или организация может отдельно заявить подтверждённые [сумма] расходов и попросить сохранить сведения для дальнейшего требования, но первичное письмо не следует перегружать спорной упущенной выгодой. Главная цель — остановить движение записи и получить доказательства. Подписант указывает полномочия, безопасный независимый email и телефон, которые не зависят от захваченного адреса.
Запрос о сохранении данных перечисляет системы
Прямой ответ: общая фраза «сохраните логи» оставляет неясным, какие записи могут быть перезаписаны.
Перечислите журналы входа в кабинет, смены email и телефона, MFA, запросов AuthInfo, authorization, transfer status, contacts, registrant, name servers, DNSSEC, платежей, тикетов и действий сотрудников. Укажите интервал с запасом до первого подозрительного события и после завершения переноса. Попросите подтвердить получение запроса и политику хранения, не требуя немедленно раскрыть чужие персональные данные.
Отдельно направьте preservation request почтовому и DNS-провайдеру. Если начато официальное производство, номер и документы передаются по предусмотренному каналу. Украденный домен оставляет следы в нескольких системах, и одна компания не хранит всю цепочку. Чем точнее период и событие, тем меньше риск получить бесполезную общую выгрузку.
Бесплатно и дистанционно по РФ можно проверить адресатов и структуру preservation request; консультация идёт без гарантии возврата записи или полноты логов. Получить консультацию
Заявление об инциденте не подменяет registrar review
Прямой ответ: правоохранительный и реестровый маршруты идут параллельно, потому что решают разные задачи.
В заявлении изложите способ обнаружения, несанкционированный доступ, transfer, изменения DNS или почты, подозрительные сообщения, платёжный ущерб и список цифровых идентификаторов. Приложите хронологию и копии, сохранив оригиналы. Не называйте конкретного человека преступником без фактической базы; укажите известные аккаунты, адреса, номера и получателей.
Registrar review нужен для срочного анализа записи и возможного межрегистраторного действия. Заявление помогает расследовать доступ и получить сведения процессуальным путём, но само по себе не переписывает реестр. Если требуется судебный запрет на последующие операции или обеспечительная мера, оцените юрисдикцию, ответчиков, срочность и исполнимость с профильным специалистом. Домен может перемещаться быстрее обычного иска, поэтому документы готовят одновременно.
TDRP, UDRP и суд решают разные споры
Прямой ответ: выбор процедуры зависит от нарушения transfer policy, товарного знака или незаконного приобретения права.
TDRP предназначен для inter-registrar transfer и запускается registrar. UDRP и URS в ограниченных обстоятельствах относятся к регистрации и использованию имени, конфликтующему с товарным знаком; ICANN указывает их как возможные варианты, когда адрес уже зарегистрирован на другом лице. Они не являются стандартной заменой unauthorized-transfer review. Суд может рассматривать договор, право на запись, незаконный доступ, убытки и обеспечительные меры в пределах своей компетенции.
Не подавайте дорогую процедуру только из-за знакомой аббревиатуры. Сначала определите фактическую операцию и желаемый результат: вернуть поддержку прежнему registrar, восстановить registrant, запретить изменения или взыскать ущерб. Украденный домен иногда требует нескольких средств, но каждый документ должен соответствовать своему предмету и адресату.
Ущерб считают по проверяемым категориям
Прямой ответ: прямые аварийные расходы доказать проще, чем всю ожидаемую прибыль сайта за неопределённый срок.
Соберите счета за incident response, восстановление почты и хостинга, временный адрес, уведомление клиентов, перевыпуск сертификатов и вынужденную рекламу. Для простоя используйте точные заказы, обращения и платежи, которые сорвались в установленный период; сравнение со средним оборотом оставьте как вспомогательный расчёт. Для SEO сохраните данные до и после, но не объявляйте любое падение следствием transfer без исключения других причин.
Отдельно учитывайте мошеннические банковские переводы, потому что их получатель и маршрут возврата отличаются. Фиксируйте действия по уменьшению потерь: резервный канал, предупреждение клиентов, восстановление DNS. Украденный домен может причинить серьёзный вред, однако требование становится убедительнее, когда каждая строка имеет дату, документ, причинную связь и разумное объяснение.
Связанные разборы не меняют реестровую процедуру
Прямой ответ: соседние инциденты помогают организовать безопасность и доказательства, но не определяют registrar или политику зоны.
Если злоумышленник сначала получил облачную учётную запись, используйте отдельную статью о взломе облачного аккаунта. При неизвестной подписи или доверенности пригодится разбор о мошенничестве с электронной подписью, а общий индекс файлов дан в комплекте доказательств.
Материалы серии о невыплаченном кешбэке и о выросшей смете ремонта принадлежат другим отношениям и включены для навигации. Сроки претензий из них нельзя переносить сюда. В текущем деле домен проверяется через зону, registrar of record, registrant, transfer evidence и актуальную процедуру.
История российского интернет-магазина
Прямой ответ: первая составная учебная история показывает, как перехват административной почты превращается в AuthInfo-transfer, хотя сайт ещё несколько часов работает нормально.
У магазина в зоне .RU злоумышленник получил доступ к ящику администратора, запросил секретный ключ и перенёс запись. Владелец заметил проблему только после смены MX: registrar of record уже был другим, а сайт продолжал открываться со старого хостинга. Команда сохранила письма с заголовками, два реестровых снимка, счета, анкету администратора и время запроса AuthInfo. Прежний registrar открыл incident review, новый получил уведомление о споре, почтовый провайдер сохранил сессии.
После проверки участники восстановили поддержку записи и контакты, а компания отдельно расследовала два поддельных счёта. Все лица, суммы и последовательность придуманы для обучения. Пример не означает, что российский transfer всегда отменяется добровольно. Он показывает, почему украденный домен, работающий сайт и скомпрометированная почта могут существовать одновременно, а AuthInfo нужно исследовать как отдельное событие.
История проекта в зоне .com
Прямой ответ: вторая составная учебная история показывает роль losing registrar, когда privacy скрывает текущего registrant и пользователь не может подать TDRP сам.
Основатель SaaS увидел новый registrar и name servers у адреса .com. Публичный RDAP не раскрывал клиента, но старые счета, уведомление о transfer, журнал входа и корпоративные документы подтверждали прежний контроль. Основатель открыл один кейс у losing registrar, передал индекс доказательств и попросил связаться с gaining registrar. Дополнительно он уведомил клиентов через давно верифицированную страницу и приостановил смену реквизитов по письмам.
Регистраторы сопоставили состояние на дату transfer и запустили предусмотренное policy взаимодействие; запись вернулась к прежнему registrar. История полностью вымышлена и собрана как учебная модель. Она не обещает TDRP-результат: текущая политика, авторизация, сроки и доказательства могут дать иной вывод. Смысл примера — пользователь готовит материал, а формальный inter-registrar complaint ведёт уполномоченный registrar.
Оценка позиции зависит от реестровой цепочки
Прямой ответ: сильная позиция связывает прежнего registrant, отсутствие согласия, конкретную авторизацию и изменение registrar независимыми документами.
50/50 — это редакционная оценка, а не статистика. Для аварийного спора такой условный ориентир уместен, когда есть исторический RDAP/WHOIS, договор и счета, письма показывают неизвестный transfer, losing registrar получил обращение сразу, а текущая запись и DNS зафиксированы. Позиция слабее при просроченной регистрации, корпоративном конфликте о полномочиях, отсутствии цепочки переоформления, добровольно переданном AuthInfo или попытке применить TDRP к .RU/.РФ.
Комментарий проверен модерацией сайта. Отдельно оценивайте актуальную политику, юрисдикцию, стоимость процедуры, дальнейшие transfers и возможность исполнить решение. Ни публичный реестровый снимок, ни консультация не гарантируют возврат домена конкретному заявителю.
«Гарантированный registrar lock» может быть второй атакой
Прямой ответ: законный участник не просит отправить AuthInfo, MFA-код или криптовалюту в личном чате ради секретной разблокировки.
Мошенник находит публичный кейс, представляется сотрудником registry и обещает «заморозить EPP» за депозит. Он может прислать копию настоящего WHOIS и назвать registrar. Не переходите по его ссылке и не входите через присланную форму. Откройте прежний тикет с сохранённого адреса, сверяйте домен поддержки по договору и оплачивайте только официально выставленные услуги с понятным основанием.
Если деньги или секрет уже переданы, смените доступ через штатный процесс, уведомите registrars, банк или криптосервис и добавьте событие в хронологию. Такая потеря не доказывает обязанность registrar вернуть платёж. Украденный домен и обман «помощника» становятся двумя связанными, но самостоятельными эпизодами.
Финальный комплект воспроизводит инцидент без пароля
Прямой ответ: независимый специалист должен понять зону, участников, transfer и ущерб, не входя в аккаунт владельца.
На первой странице укажите полное имя, Unicode/ASCII при необходимости, TLD, прежнего и текущего registrar, registrant, ключевые даты, номера кейсов и желаемое действие. Далее разместите текущие и исторические RDAP/WHOIS, DNS до и после, договоры, счета, идентификацию, transfer-письма, хронологию, логи, correspondence registrars, уведомления клиентов, банковские документы и расчёт расходов. Пробелы и предельные даты вынесите отдельно.
Удалите из копии пароль, AuthInfo, MFA, recovery-коды, закрытые ключи, полные банковские реквизиты и чужие персональные данные. Бесплатная дистанционная консультация доступна по всей России, но проводится без гарантий возврата записи, компенсации или исхода суда. Получить консультацию