Як було зупинено сайт атакувальника: позначка часу clientHold у WHOIS і погляд із доменної галузі

28 жовтня GMO Internet Group повідомила (Повідомлення № 13), що домени сайту, який використовувала сторона, що називає себе атакувальником в інциденті з «Onamae.com Desktop Cloud», включно з його дзеркалом, були підтверджено заблоковані близько 04:00 того ж дня. У цій статті зафіксовано, як це блокування виглядає в реєстраційних даних домену, звірених зі службами WHOIS і RDAP реєстру .store, і подано погляд автора, який працював у доменній галузі. Сам інцидент, пошукові підказки та котирування акцій відстежуються в терміновому випуску (https://nkzw.jp/2026/10/27/gmo_incident_suggest_stock_security_investment_2026_en/), який оновлюється щоробочого дня.

Ця стаття також опублікована англійською на sitescouter.net і nkzw.jp та японською на sitescouter.net. Це українська версія на Site Scouter, перекладена з англійської.

Що показують WHOIS і RDAP

Рано вранці 29 жовтня (JST) я надіслав запити до WHOIS-сервера реєстру .store (whois.nic.store) та його служби RDAP (відповіді надає оператор реєстру Radix на rdap.radix.host) щодо сайту атакувальника та його дзеркала. Результати:

DNS-запит увечері 27 жовтня показував, що основний домен делеговано на хостингові сервери імен реєстратора і він резолвиться в IP-адресу тієї ж хостингової служби. Станом на 29 жовтня жоден із двох доменів не існує в зоні .store при проходженні від кореня, тож жоден не резолвиться. Поле WHOIS «Updated Date» — це момент зміни статусу. Два домени було оновлено з різницею в шість секунд, що вказує на те, що одна особа або одна пакетна операція заблокували обидва.

Дані реєстранта приховано і у WHOIS, і в RDAP за правилами ICANN, тому запит не говорить, хто зареєстрував домени.

Хронологія: блокування приблизно через 16 годин після дедлайну

Якщо накласти позначки часу WHOIS на повідомлення компанії та повідомлення преси, отримаємо таку послідовність (JST):

• 27 і 31 серпня: зареєстровано два домени (приблизно за два місяці до розкриття інциденту)
• 26 жовтня: сторона, що називає себе атакувальником, оголошує, що опівдні 27 жовтня опублікує дані клієнтів і запустить програму-вимагач (преса)
• 27 жовтня, 12:00: дедлайн атакувальника. GMO підтверджує, що платити не буде
• 27 жовтня, після 13:00: преса повідомляє, що атакувальник опублікував один запис, схожий на персональні дані (автентичність невідома)
• 27 жовтня, 14:55: Повідомлення № 11 GMO підтверджує, що дані відвідувачів сайту атакувальника збиралися атакувальником
• 27 жовтня, 19:10: Повідомлення № 12 GMO оголошує програму винагороди та спеціальні компенсаційні виплати
• 28 жовтня, 03:35-03:36: на обидва домени встановлено clientHold (Updated Date у WHOIS)
• 28 жовтня, близько 04:00: GMO підтверджує блокування (Повідомлення № 13)
• 28 жовтня, 11:00: опубліковано Повідомлення № 13, яке описує блокування як результат взаємодії з відповідними провайдерами

Це приблизно 15.5 години після полуденного дедлайну і приблизно 12.5 години після Повідомлення № 11. За повідомленнями преси, американський провайдер, яким користувався атакувальник, імовірно, заблокував домени за порушення умов обслуговування; запис WHOIS із цим узгоджується. Реєстратор не оприлюднив своїх причин, тож понад повідомлення преси нічого не відомо.

Що таке clientHold: найшвидший важіль реєстратора

clientHold — один із кодів статусу домену (EPP-статусів), визначених ICANN; це блокування, яке встановлює реєстратор (https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en). Домен у статусі clientHold вилучається з файлу зони TLD, його делегування на сервери імен зникає, і він перестає резолвитися будь-де. Сама реєстрація не видаляється: запис і рядок WHOIS зберігаються до дати закінчення (для цих двох — серпень 2027 р.). Супутній статус clientTransferProhibited блокує перенесення до іншого реєстратора.

Схожий за назвою статус serverHold встановлює не реєстратор, а реєстр (тут — Radix, оператор .store), і реєстратор не може його зняти. Заморожування за рішенням суду або на запит правоохоронних органів частіше застосовують саме на цьому рівні. Запис тут показує лише clientHold, тобто домени було зупинено на розсуд реєстратора.

Призупинення хостингу та блокування домену — різні речі. Увечері 27 жовтня сайт розміщувався на хостингу, що належить групі самого реєстратора. Призупинення лише хостингового облікового запису залишає статус WHOIS без змін, а домен можна спрямувати на інший сервер і повернути за хвилини. Блокування домену не дає йому резолвитися, куди б не переїхав сервер. Тут було зроблено друге. Те, що реєстратор і хостинг-провайдер належали одній групі, імовірно, одна з причин, чому дію вдалося виконати за один крок.

Чому «сайт зупинив реєстратор, а не хостинг-провайдер»

Оскільки сервери імен і далі вказані у WHOIS, доречно запитати, чи не було зупинено хостинг, а не домен. Запис показує дію реєстратора з таких причин.

1. Встановити clientHold може лише реєстратор. Розділ 2.3 RFC 5731, що визначає протокол EPP для реєстрації доменів, каже, що значення статусу «можуть встановлюватися лише клієнтом, який спонсорує об'єкт домену, і сервером, на якому об'єкт розміщено», а значення з префіксом «client» додає й знімає клієнт, тобто реєстратор. Пояснення ICANN до кодів статусу також говорить, що clientHold «встановлюється реєстратором вашого домену» і «вказує реєстру вашого домену не активувати домен у DNS», тож він «не резолвитиметься». Хостингова компанія не має ні повноважень, ні каналу для зміни статусу в базі даних реєстру.
2. Збереження серверів імен у WHOIS — саме так працює clientHold. RFC 5731 приписує для clientHold і serverHold, що «інформація про делегування DNS НЕ ПОВИННА публікуватися для об'єкта». Сервери імен залишаються в реєстраційних даних; припиняється лише їх публікація в зоні. Саме це показали запити 29 жовтня: сервери імен присутні у WHOIS, у DNS — NXDOMAIN (домени відсутні в зоні .store). Призупинення лише хостингу виглядає навпаки: DNS і далі резолвиться в IP-адресу, а браузер показує сторінку призупинення або помилку з'єднання.
3. Це збігається з власним описом реєстратора. Стаття підтримки Namecheap каже, що «статус Client Hold призначається реєстратором домену, здебільшого з причин, пов'язаних із шахрайською/зловмисною діяльністю» або за «недотримання наших Умов обслуговування», і вказує як контакт свою команду Legal & Abuse. Там само зазначено, що serverHold «встановлюється реєстром домену (не Namecheap)».
4. Реєстратор і хостинг-провайдер були однією компанією. На момент фіксації ввечері 27 жовтня основний домен резолвився в 198.54.116.91. RDAP ARIN показує, що цю адресу виділено Namecheap, Inc. (198.54.112.0-198.54.127.255); сервери імен були хостинговими серверами компанії (namecheaphosting.com), а заголовок HTTP-відповіді — LiteSpeed, серверне ПЗ, яке використовується на її спільному хостингу. Тож «зупинив хостинг-провайдер» і «зупинив реєстратор» вказують на одну й ту саму компанію. Точне формулювання: зафіксована дія — це clientHold з боку реєстратора.

Опис преси «американський провайдер заблокував за порушення умов обслуговування», отже, найкраще узгоджується з clientHold, застосованим командою Legal & Abuse компанії відповідно до її умов. Оскільки реєстратор не оприлюднив причин, це залишається умовиводом.

З погляду збереження доказів блокування також правильніше за видалення. Видалення домену запускає процес закінчення в реєстратора та реєстру і відкриває можливість повторної реєстрації. При блокуванні дані реєстранта, платіжні дані та журнали доступу залишаються в реєстратора і можуть бути надані слідчим на запит.

Погляд із доменної галузі

Я входив до виконавчого комітету доменно-серверного бізнесу дочірньої компанії групи GMO, а нині веду бізнес із бекордерів доменів і доменів з історією («вікових» доменів). З цієї позиції викладаю свою думку щодо блокування.

По-перше, за мірками галузі це блокування було швидким. Служби abuse реєстраторів отримують величезні обсяги скарг з усього світу, і кілька днів від скарги до дії — не рідкість. П'ятнадцять з половиною годин після дедлайну — результат того, що публічна японська компанія працювала разом із поліцією. Приватній особі чи малому бізнесу, які постраждали від такого самого роду атаки, не варто очікувати тієї ж швидкості. Якість скарги (скриншоти, URL, опис шкоди, участь правоохоронних органів) безпосередньо визначає, як швидко діє реєстратор. Це також не був випадок, коли «реєстратор діяв за вказівкою уряду США». Коли американська влада зупиняє домен, вона робить це за судовим ордером на вилучення, як у міжнародній операції проти LockBit у лютому 2024 року; такі операції готуються місяцями, а після вилучення сервери імен зазвичай замінюють на сервери самої влади. Щоб японська поліція могла юридично примусити американського провайдера, потрібна процедура за Договором про взаємну правову допомогу в кримінальних справах між Японією та США (чинний із 2006 року), яка також триває місяцями. Запис тут показує лише clientHold з незмінними серверами імен, тому природне прочитання таке: реєстратор діяв за скаргою відповідно до своїх умов, а не за ордером. Добровільна скарга чи запит японської поліції або постраждалої компанії до американського провайдера не мають обов'язкової сили, але скарга з доданими доказами має велику вагу при рішенні провайдера в межах його умов обслуговування. Швидкість визначили якість і канал скарги, а не урядова вказівка.

По-друге, сайти вимагання та витоку даних не підпадають під визначення зловживання DNS від ICANN. Поправки до Угоди про акредитацію реєстраторів ICANN, що набули чинності у квітні 2024 року, визначають «зловживання DNS» у розділі 3.18.2 як «шкідливе ПЗ, ботнети, фішинг, фармінг і спам (коли спам слугує механізмом доставки інших форм зловживання DNS)» і вимагають, щоб реєстратор, який «має придатні для дій докази того, що спонсороване ним зареєстроване ім'я використовується для зловживання DNS», «негайно вжив відповідних заходів із пом'якшення, які є розумно необхідними». Сайт, що демонструє погрозу і перелічує те, що він називає викраденими даними, не підпадає під жодну з п'яти категорій. Тому таке блокування здійснюється не за зобов'язанням перед ICANN, а за умовами обслуговування та на розсуд кожного реєстратора. Оскільки це розсуд, швидкість і поріг різняться від реєстратора до реєстратора, і для жертви результат залежить від того, яким реєстратором випадково скористався атакувальник. Це структурна слабкість галузі, і я вважаю, що сайти такого роду мають зупинятися за спільним стандартом, а не за індивідуальними умовами обслуговування.

По-третє, виявити це заздалегідь нереалістично. Два домени було зареєстровано приблизно за два місяці до розкриття інциденту. Новий gTLD на кшталт .store коштує в перший рік кілька сотень єн, а нешкідливий рядок без назви бренду не спрацює в моніторингу нових реєстрацій, який ведуть компанії. Заздалегідь готувати кілька одноразових доменів — стандартна практика атакувальників такого роду. Замість інвестицій у раннє виявлення ефективніше прописати у власних процедурах реагування найкоротший шлях до зняття сайту постфактум: служби abuse реєстратора та хостинг-провайдера, власник IP-адреси і за потреби правоохоронні органи. Запит WHOIS або RDAP за хвилину підкаже, куди скаржитися.

По-четверте, clientHold — не кінець. Блокування оборотне: якщо реєстратор його зніме, сайт повернеться за хвилини. Реєстрації чинні до серпня 2027 року. Дзеркала та сайти в Tor не зачіпаються DNS-блокуванням. Атакувальник може за хвилини зареєструвати інше ім'я в іншого реєстратора. Заява GMO в Повідомленні № 13 про те, що компанія домагатиметься зняття будь-якого подібного сайту, відображає цю реальність. Щоб зупинити сайт остаточно, потрібні serverHold на рівні реєстру, заморожування або передача за рішенням суду та здатність працювати з кількома реєстраторами та реєстрами одночасно.

По-п'яте, повторну реєстрацію після закінчення слід запобігати. Це безпосередньо стосується мого власного бізнесу, тому скажу прямо. Якщо ці домени дійдуть до дати закінчення в стані блокування, вони пройдуть пільгові періоди, будуть видалені й стануть доступними будь-кому. Ім'я, використане для вимагацького повідомлення, і далі живе в результатах пошуку, дописах у соцмережах і новинних статтях. Перереєстроване, воно може перетворитися на підроблену сторінку «публікації даних» або фішинговий сайт. Я веду бізнес із бекордерів і вікових доменів і не придбаватиму подібні домени; на мою думку, ніхто в галузі не повинен цього робити. Правильний механізм — щоб реєстр резервував такі імена, і вони ніколи не поверталися на ринок.

По-шосте, про практичний бік для постраждалої компанії. «Взаємодія з відповідними провайдерами» в Повідомленні № 13 конкретно означає звернення до реєстратора, хостинг-провайдера та власника IP-адреси, а також запити правоохоронних органів. У більшості компаній немає процедури на випадок, коли вони самі мають домагатися зняття сайту атакувальника. Рекомендую додати до плану реагування на інциденти пункт «виявити інфраструктуру атакувальника та повідомити про неї» з кроками запитів WHOIS, RDAP і DNS та заздалегідь підготовленим шаблоном звернення до служб abuse.

Обмеження та застереження

• Дані реєстранта у WHOIS і RDAP приховано; реєстрант невідомий.
• Реєстратор не оприлюднив причин блокування. «Заблоковано за порушення умов обслуговування» ґрунтується на повідомленнях преси.
• 29 жовтня я перевірив лише DNS, WHOIS і RDAP. На сам сайт атакувальника я не заходив. Як зазначено в Повідомленні № 11 GMO, дані відвідувачів цього сайту збиралися атакувальником; якщо сайт із тим самим іменем з'явиться знову, не заходьте на нього.
• Ця стаття не оцінює реакцію групи GMO. Вона фіксує те, що публічна інформація та публічні реєстраційні дані показують з одного питання: блокування доменів.

Розкриття конфлікту інтересів

Я працював у дочірній компанії групи GMO і входив до виконавчого комітету її доменно-серверного бізнесу. Колись я володів акціями групи, але нині не маю з нею жодних стосунків і акцій не тримаю. Наразі я веду бізнес із бекордерів доменів і вікових доменів, і розділ 4 написано з цієї позиції. Стаття ґрунтується виключно на публічній інформації та публічних реєстраційних даних і не використовує нічого з того, що я дізнався, працюючи там. Це не інвестиційна порада.

Джерела

Остання перевірка: 2026-10-29. Специфікації та правила можуть змінюватися; перш ніж діяти, звіртеся з першоджерелами.

• RFC 5731: Extensible Provisioning Protocol (EPP) Domain Name Mapping, 2.3 Status Values
• ICANN: EPP Status Codes | What Do They Mean, and Why Should I Know?
• Namecheap: Why was my domain suspended with a serverHold or clientHold status?
• ICANN: 2024 Global Amendments to the 2013 Registrar Accreditation Agreement (definition of DNS Abuse in 3.18.2: malware, botnets, phishing, pharming, and spam)
• .store registry WHOIS: whois.nic.store; RDAP
• ARIN RDAP (allocation of 198.54.116.91)
• Ministry of Foreign Affairs of Japan: Treaty between Japan and the United States of America on Mutual Legal Assistance in Criminal Matters
• KrebsOnSecurity (20 Feb 2024): Feds Seize LockBit Ransomware Websites
• GMO Internet Group, Notices No. 11, 12 and 13