Step-by-step: recover a hijacked .dev domain after account compromise

Step-by-step: recover a hijacked .dev domain after account compromise. UDRP and ccTLD domain recovery and defense across .dev. Email the firm to assess your ca…

Your .dev domain disappears overnight. The registrar account password no longer works, the WHOIS record shows a stranger's name, and the site you built on it now redirects somewhere else. This is account compromise followed by unauthorized transfer – domain hijacking – and the clock starts the moment you notice it.

To recover a hijacked .dev domain after account compromise, the primary legal route is the UDRP administered through WIPO, which governs .dev as a gTLD operated by Google Registry. The registrant must act within hours on the registrar-escalation track and within days on the formal dispute track. Acting too slowly risks a secondary transfer that moves the domain beyond the easiest reversal window, and in some cases a court action becomes the only remaining path.

This guide walks each step in sequence, flags the trap hidden in each one, and maps the point at which arbitration gives way to litigation.

What governs .dev and why it matters before you act

.dev is a generic top-level domain, not a country-code zone. That single fact determines everything that follows. Because .dev is a gTLD operated under ICANN's authority, the UDRP and the ICANN transfer dispute resolution procedures apply – not a national ccTLD policy. WIPO is the principal forum, and all three elements of Paragraph 4(a) govern any formal complaint. However, account compromise is a factual situation that the UDRP was not originally designed for; UDRP panels assess whether the registration and use of the domain are abusive, not whether the underlying account was stolen. That distinction shapes which lever to pull first.

The ICANN Registrar Transfer Dispute Resolution Policy (TDRP) and the ICANN policy on unauthorized transfers are the procedural tools you need before filing a UDRP complaint. Many practitioners miss this. Filing a UDRP while the registrar escalation is still open can complicate – and in some cases delay – the registrar's own investigation. The trap in this step: assuming the UDRP is the only route and filing immediately, burning the faster internal track.

Step 1: Contain the damage within the first hours

The first 24 hours after you discover the compromise are the highest-leverage period. The registrar's internal fraud team can freeze a domain transfer far faster than any arbitration panel. Take these actions in order, without waiting for one to resolve before beginning the next.

First, document the compromise immediately. Take timestamped screenshots of the current WHOIS/RDDS record, the registrar account login failure, and any emails you received about password changes or transfer authorizations you did not initiate. That contemporaneous record is the cornerstone of every track that follows – arbitration, court, and registrar escalation alike. Second, contact the losing registrar (the one that held the domain before the hijack) through its formal abuse and fraud channels, not a general support ticket. Request an emergency domain lock and provide the authentication chain: registration date, original payment records, prior WHOIS history, and the evidence of unauthorized access. Third, file a report with your national cybercrime authority. This is not optional paperwork. A police report or cybercrime complaint creates an official timestamp that corroborates your account of events and may be required later by a court.

The trap in this step: contacting only one channel. Registrar escalation, law enforcement report, and legal counsel should all be engaged simultaneously, not sequentially.

If you are in the first hours of a .dev hijack and need to know which escalation path to open first, contact info@cognomenlaw.com for an immediate assessment.

Step 2: Escalate to the registrar – and know when it has failed

ICANN's policies require accredited registrars to maintain abuse contact procedures and to investigate unauthorized transfer claims. The gaining registrar – the one that now holds the domain – is your second target. Both registrars carry obligations under the ICANN transfer policy. Submit a formal written complaint to both, referencing the unauthorized nature of the transfer and the evidence you collected in Step 1.

What does a successful registrar escalation look like? In the best outcome, the gaining registrar confirms the transfer was unauthorized, places a hold on the domain, and reverses the transfer to the losing registrar within days. That path avoids formal proceedings entirely. We have seen this resolution in cases where the fraud evidence – unauthorized password reset emails, IP geolocation anomalies, and a pattern of immediate redirecting of the domain – was unambiguous and documented from the first hour.

In a recent matter (a .dev domain used by a software studio, autumn 2024), the losing registrar reversed the transfer within five business days after the studio provided the original purchase receipt, the full email chain of unauthorized reset notifications, and a timestamped registrar-account access log. No formal complaint was filed. That outcome depended entirely on evidence assembled within the first 12 hours.

The trap in this step: accepting a "we are investigating" response as progress. Set a written deadline – typically 5 to 7 business days – and state clearly that you will escalate to ICANN and formal dispute proceedings if the matter is not resolved. Registrars respond faster when the escalation path is visible.

Step 3: Understand what evidence decides the outcome

Whether you proceed through registrar escalation, a UDRP complaint, or court action, the same underlying evidence drives every outcome. Understanding the evidential hierarchy before you start collecting saves time and prevents gaps that a registrant on the other side will exploit.

The core evidence package for a hijacked .dev recovery consists of the following categories. Registration history: original registration date, the identity of the registrant at registration, payment records, and WHOIS capture history from a third-party archiving service. Authentication failure evidence: screenshots and server logs showing that legitimate credentials were rejected after a specific date. Unauthorized access indicators: password reset emails you did not request, transfer authorization emails you did not send, IP addresses in account logs that do not match your usual access patterns, and any phishing emails that preceded the compromise. Ownership corroboration: DNS records pointing to your infrastructure before the hijack, public registration of the .dev domain in business materials, development platform records, TLS certificates issued to the domain in your name, and any trademark registration that covers the name. Business harm evidence: revenue impact, customer confusion, and any abuse of the domain by the hijacker after transfer.

The trap in this step: collecting only the most recent evidence and ignoring historical records. Panels and courts place heavy weight on the original registration context. A hijacked registrant who cannot show what the domain pointed to before the attack, and who held it, is at a material disadvantage.

What evidence is genuinely decisive? In our practice, contemporaneous third-party corroboration is the most persuasive category: an email from a colleague noting the site was down, a customer complaint timestamped within hours of the hijack, or a DNS monitoring alert from a third-party service. These records cannot plausibly be fabricated after the fact, and panels and courts treat them accordingly.

When does a UDRP complaint apply – and how does it fit the .dev zone?

Once registrar escalation has either failed or stalled, the UDRP becomes the primary formal route. Because .dev is a gTLD, WIPO and the Forum both have jurisdiction. The WIPO filing fee for a single-panel complaint covering one to five domains is USD 1,500, and a standard case runs approximately two months from commencement to decision.

In an account-compromise scenario the UDRP framing differs from a standard cybersquatting complaint. You are not simply arguing that someone registered a domain identical to your trademark in bad faith. You are arguing that the current registrant has no legitimate interest in the domain and that the registration in their name – or the use they are making of it – is abusive. Where the hijacker has re-listed the domain for sale to you, published competing content on it, or allowed it to be used for phishing, Paragraph 4(b) bad-faith factors apply directly. Where the hijacker has simply parked it and is otherwise silent, passive holding doctrine becomes relevant – panels have consistently held that passive holding of a domain that corresponds to a well-known mark can constitute bad faith where no plausible good-faith use is conceivable.

The trap in the UDRP track: assuming it is always the right route for a stolen domain. The UDRP's only remedies are transfer or cancellation. If the hijacker has monetized the domain for months, caused identifiable revenue loss, or the name does not clearly correspond to a trademark you hold, a court action may be necessary to reach damages and may also produce a swifter injunction. We consider this decision point at the outset of every hijack matter we handle.

To weigh UDRP against a court action for your case, email info@cognomenlaw.com. The choice between forums has lasting consequences.

Step 4: File the UDRP complaint or initiate court proceedings

If registrar escalation has not resolved the matter within a reasonable period, the next decision is which formal route to file. This is a genuine choice with different timelines, costs, and remedies.

The UDRP route: file at WIPO or the Forum. For a .dev hijack with a clear trademark nexus and a hijacker who is silent or parking the domain, WIPO is typically the more efficient forum. Prepare the complaint to address all three elements of Paragraph 4(a) and build the submission around the evidence package described in Step 3. Attach authentication failure logs, prior WHOIS records, and any trademark registration. The respondent has 20 days to file a response after commencement. In a default case – where the hijacker does not respond – panels routinely draw adverse inferences, but the complaint must still prove each element on its own evidence; default is not automatic transfer.

The court route: where arbitration cannot reach. Court action is appropriate in three specific situations for a .dev hijack. First, when the hijacker has transferred the domain to a third party – possibly an innocent purchaser – and the UDRP alone cannot reach the chain of title. Second, when you need an emergency injunction within hours to prevent a further transfer; no UDRP panel can issue an injunction. Third, when you have suffered quantifiable business loss and want to pursue damages alongside domain recovery. For .dev, the relevant jurisdiction typically depends on where the registrar is incorporated, where the hijacker is located, or where you suffered the loss. US anticybersquatting litigation may be available where the registrar is US-domiciled. We coordinate with local litigation counsel in the relevant jurisdiction for court-track matters where the filing country is outside our direct reach.

The trap in this step: filing at the wrong forum for the facts. A UDRP at WIPO when you actually need an injunction will take two months and produce no injunction. A court action when registrar escalation would have resolved the matter in five days is an expensive mistake. Map the situation against the remedy before filing anything.

Step 5: Navigate the panel decision and registrar implementation

After the UDRP decision issues – transfer or cancellation – the case is not over. The registrar has a 10-business-day implementation window during which the respondent can file a court action in the mutual jurisdiction specified by the registrar agreement to halt implementation. That window is the final trap in the UDRP track.

In practice, hijackers who obtained the domain through fraud rarely file a court action to resist implementation. But it is worth knowing the window exists and tracking it. If implementation is not confirmed by the end of the window, follow up directly with the registrar and, if needed, escalate to ICANN compliance. We monitor this stage for every complaint we file because delays in registrar implementation are more common than most practitioners acknowledge.

After the domain is transferred back, immediate remedial steps matter. Change every credential associated with the domain: registrar account login, authentication app, recovery email address, and DNS management access. Enable registry lock at the registrar level – a premium feature offered by most major registrars that prevents transfers without a manual out-of-band verification. Update your TLS certificates, audit your DNS records for any modifications made during the hijack period, and notify any upstream services – such as email providers and CI/CD platforms – that authenticate against the domain. A domain recovered is not automatically a domain secured.

The decision matrix: which route for which situation?

Different situations in a .dev hijack call for different responses. If the hijack is discovered within 24 to 48 hours, the domain has not been re-transferred, and the evidence of compromise is strong, registrar escalation alone – pursued aggressively through both the losing and gaining registrars – has the highest probability of a fast resolution without any formal filing. If the registrar escalation fails after a reasonable period and you hold a trademark corresponding to the domain, a UDRP complaint at WIPO with a USD 1,500 single-panel fee and a roughly two-month timeline is the standard path. If the domain has been re-transferred to a third party, or if you need to freeze the domain within hours, or if you have suffered damages you need to recover, court proceedings – including a request for an emergency injunction and a damages claim under applicable anticybersquatting legislation – become necessary, with substantially higher costs and timelines that depend on the jurisdiction. If the domain sits at a US-domiciled registrar and the hijacker is identifiable, US anticybersquatting litigation is the route that reaches both the domain and monetary relief.

One cross-zone comparison is worth making explicitly. If the same brand holds a .co.uk alongside the .dev, the .uk domain would be governed by the Nominet DRS, not the UDRP. Those procedures run in parallel and are independent. A UDRP order for the .dev does not automatically transfer the .uk – a separate Nominet filing is required. We regularly advise brand owners who discover that recovering the gTLD was only half the problem.

Related at COGNOMEN

• Domain theft recovery: registrar escalation, court action, and transfer reversal
• Court-track anticybersquatting: when arbitration cannot reach the problem
• Respondent defense and RDNH: protecting a legitimate domain holding