Step-by-step: reverse an unauthorized transfer of a .cloud domain

Step-by-step: reverse an unauthorized transfer of a .cloud domain. UDRP and ccTLD domain recovery and defense across .cloud. Email the firm to assess your case.

A domain registered under .cloud disappears from a portfolio overnight. The registrar's WHOIS shows a new holder. The attacker redirected email, locked out the original owner, and is already demanding payment to return control. This is domain theft — and time is the deciding variable.

To reverse an unauthorized transfer of a .cloud domain, the owner must act across three parallel tracks simultaneously: escalate a registrar lock and account-compromise report within hours, gather cryptographic and access-log evidence before it ages out, and assess whether a UDRP complaint at WIPO or a court action is the faster route to a binding transfer order. The 20-day response window under the UDRP is fixed; the registrar's own fraud-escalation window is often shorter. Speed and evidence quality decide the outcome.

This guide walks each step in sequence — and names the trap buried inside each one.

What governs unauthorized transfers of a .cloud domain?

The .cloud registry operates under a standard gTLD policy regime: ICANN's Transfer Policy, the Registrar Accreditation Agreement, and — critically for recovery — the UDRP administered by WIPO, the Forum, CAC, or ADNDRC. The UDRP is available for .cloud because the registry is an ICANN-accredited gTLD. That matters because it gives the dispossessed owner a contractual arbitration path, not merely a civil litigation path, to recover the name.

There is a further layer. ICANN's Transfer Policy includes a provision that can be used where an unauthorized inter-registrar transfer occurred: the Registrar Transfer Dispute Resolution Policy (TDRP). The TDRP addresses whether the gaining registrar followed proper transfer procedures. It does not, however, adjudicate bad faith by a human thief. That gap means owners almost always need both a registrar-level escalation and an external proceeding.

The trap in this step: many owners assume .cloud behaves like a ccTLD with a national dispute authority. It does not. The applicable dispute path runs through ICANN-accredited providers — primarily WIPO and the Forum — not a national registry body. Checking the zone before filing saves weeks of misdirected effort.

Step 1: Freeze the domain within the first 24 hours

The first action is locking the domain at every available point to prevent a second transfer — from the theft registrar to a third registrar — which would add another layer of procedural complexity. A domain that moves twice is materially harder to recover than one that moves once.

Contact both the original registrar (where the account compromise occurred) and the gaining registrar (where the domain now sits). Both are contractually bound by ICANN's rules. Request an immediate registrar lock, citing suspected unauthorized transfer and account compromise. Use the word "unauthorized" explicitly; registrars are trained to escalate on that trigger.

Simultaneously, file a complaint with ICANN's Compliance department at icann.org/compliance. ICANN Compliance does not order a transfer, but an open compliance case creates a formal record that the transfer was disputed from the outset. That record is useful evidence in any subsequent arbitration or court proceeding.

The trap in this step: the gaining registrar may claim it has no obligation to lock the domain because it received a technically valid authorization code (AuthInfo/EPP code). Do not accept that answer. An authorization code obtained through phishing, credential stuffing, or account compromise is not a valid authorization. Preserve every communication in writing and escalate to the registrar's abuse team in parallel with the general support channel.

Step 2: Secure and preserve the evidence of compromise

Evidence assembled in the first 48 hours is almost always stronger than evidence gathered two weeks later. Logs age out, email headers disappear, and the attacker may begin covering tracks. Preservation is not just good practice — panels and courts treat contemporaneous evidence as more reliable than reconstructed records.

The categories of evidence that routinely decide .cloud domain theft cases are: account-access logs showing an IP address inconsistent with the owner's geography or device; phishing emails or SIM-swap confirmations that preceded the transfer; the authentication confirmation email sent to the registrant's address (if the attacker redirected it, that fact is itself strong evidence of compromise); WHOIS/RDDS history showing the registrant change; and DNS propagation records showing the redirect from the original server.

Download and hash-certify each document. A simple SHA-256 hash of each file, stored with a trusted timestamp service, establishes that the document existed at a specific moment. This matters if the other side later claims the records were fabricated.

In our practice, we routinely advise clients to screen-capture the current WHOIS record within the first hour and every 12 hours thereafter. A domain pointed to a pay-per-click parking page — showing the attacker monetizing the name — is direct evidence of bad faith use, which is a factor in both the UDRP bad-faith analysis and a court's assessment of harm.

The trap in this step: the original owner sometimes logs into the compromised account to "check" the status, which can overwrite the very access logs needed to prove unauthorized entry. Instruct every person with system access to stand down and preserve the environment.

How do you choose between a UDRP and a court action to reverse the transfer?

The right route depends on what you can prove, how fast you need relief, and whether the attacker is identifiable. Neither path is universally better. The choice is a fact-specific assessment made at Step 2 — not after the UDRP deadline has already passed.

A UDRP complaint at WIPO is the faster route where the three elements of Paragraph 4(a) are clearly met: the domain is confusingly similar to a mark the original owner holds, the attacker has no legitimate interest, and the registration and use are in bad faith. A standard WIPO case resolves in roughly two months. The WIPO filing fee starts at USD 1,500 for a single-member panel on one to five domains. The UDRP remedy is transfer or cancellation — no monetary damages, no injunction, no costs award. That is both its strength (speed) and its limit (no money recovery).

A court action in the relevant jurisdiction is the better route where the owner also needs monetary damages, where the attacker's identity is known and assets are locatable, or where interim injunctive relief — a court order preventing any further transfer while the proceeding runs — is required urgently. Anticybersquatting litigation in the United States, for example, allows a court to order transfer and award statutory damages. Equivalent routes exist in other jurisdictions; COGNOMEN coordinates with local litigation counsel where the proceeding is abroad.

A third scenario arises where the theft is recent — within days — and the original registrar is responsive. A well-documented account-compromise report, combined with ICANN Compliance pressure, sometimes produces a voluntary reversal without any external proceeding. This is not a substitute for filing a UDRP; it runs in parallel while the UDRP is being prepared.

In a recent matter (a .cloud theft, spring 2025), we pursued a registrar escalation and a WIPO complaint simultaneously. The registrar's abuse team reversed the transfer within three weeks — before the UDRP panel was even appointed — because the account-compromise evidence was overwhelming. The WIPO proceeding was then withdrawn. Had we waited to see whether the registrar would cooperate before filing, we would have lost several weeks.

For an assessment of which route fits your .cloud theft — registrar escalation, UDRP, or court action — contact info@cognomenlaw.com.

Step 3: File the UDRP complaint correctly

A UDRP complaint for an unauthorized transfer of a .cloud domain must satisfy all three elements of Paragraph 4(a): confusing similarity to a mark, no legitimate interest in the respondent, and registration and use in bad faith. In a theft case, all three are usually easier to establish than in a standard cybersquatting complaint — but procedural errors in the filing can still cause a case to fail or delay.

Choose the provider first. WIPO and the Forum together handle approximately 97% of all UDRP filings. WIPO's online filing portal (WIPO ECAF) is the most commonly used for .cloud disputes. CAC offers a lower entry fee — roughly USD 500 to 800 — but is less frequently selected by complainants in theft cases. ADNDRC is an option for parties with an Asia-Pacific connection.

The complaint must name the current registrant as the respondent — which in a theft case may be the attacker's anonymous identity. Panels in theft cases regularly permit the complaint to proceed against a name such as "unauthorized transferee" or a privacy-masked registrant. The identity gap does not defeat the complaint, but it must be acknowledged in the filing and the bad-faith evidence must compensate for it.

Address each element in full, even where the answer seems obvious. Panels have declined to grant transfer in theft cases where the complainant treated the bad-faith element as self-evident rather than argued. The evidence assembled in Step 2 — access logs, phishing artifacts, DNS redirect records — goes here.

The trap in this step: filing a complaint before completing the evidence-gathering in Step 2 locks the filing record. Supplemental filings in UDRP proceedings are disfavored; panels grant them only in exceptional circumstances. Assemble the full evidentiary record before clicking submit.

Step 4: Manage the 20-day response window and default risk

Once a UDRP complaint commences, the respondent — here, the attacker — has 20 days to file a response. Most theft attackers do not respond. A default is not automatically a win; the panel still evaluates whether the complainant has met all three elements on the evidence filed. However, default removes the adversarial challenge and typically narrows the proceeding to a record review.

Where the attacker does respond — rare in theft cases — the response may assert that the transfer was authorized (claiming the owner sold or gifted the domain) or that the domain was registered legitimately. The owner's contemporaneous evidence, assembled in Step 2, is the answer to both assertions. A recent account-creation date for the attacker's registrar profile, combined with a phishing email received the day before the transfer, is hard to rebut.

During the response window, the owner should also monitor whether the domain is being used to impersonate the brand — sending phishing emails from the domain, redirecting payment portals, or hosting counterfeit pages. Each of those uses strengthens the bad-faith element in the complaint. Document them in real time.

The trap in this step: some owners interpret a default as a signal that the case is over and reduce their attention to the proceeding. Panels sometimes issue procedural queries or request supplemental evidence even in default cases. Stay engaged through the full proceeding.

Step 5: Implement the transfer order and secure the recovered domain

A WIPO panel decision ordering transfer is communicated to the registrar holding the domain. Under the UDRP, there is a mandatory 10-business-day implementation delay after the decision is notified, during which the respondent may seek a stay by initiating court proceedings in the jurisdiction specified in the registrar's dispute policy. In practice, theft attackers almost never seek a stay. The registrar then effects the transfer to the winning complainant's registrar of record.

Recovery of the domain is not the end of the task. The following hardening steps should occur immediately after transfer:

• Enable registrar lock (also called "client transfer prohibited") at the receiving registrar before or immediately upon transfer.
• Enable two-factor authentication on the registrar account and on any email account associated with the domain.
• Rotate the AuthInfo/EPP code immediately and store it in a password manager with restricted access.
• Audit DNS records — an attacker who held the domain may have inserted redirect or mail-exchange records that persist unless purged.
• Verify that the domain's email MX records point to the correct mail server; a lingering attacker-inserted MX record continues to intercept email even after the domain transfers back.
• Set a WHOIS monitoring alert so that any future change of registrant triggers an immediate notification.

In a recent matter (a .cloud e-commerce domain, summer 2024), we recovered a stolen name for a software company within approximately eight weeks of filing. The attacker had inserted a fraudulent MX record that continued intercepting transactional emails for 11 days after the transfer because the audit step was deferred. That delay had real business consequences. The hardening checklist now forms a standard part of every domain recovery we handle.

To plan recovery of a stolen or hijacked .cloud domain and put the hardening protocol in place from day one, contact info@cognomenlaw.com.

What evidence actually decides the outcome?

Evidence quality is the single most variable factor across .cloud theft recovery cases. The legal test is relatively stable; the facts are not. Panels and courts both weigh the same core categories, though they apply different standards of proof.

The evidence that panels consistently find persuasive in unauthorized-transfer cases includes: (1) account-compromise artifacts — phishing emails, SIM-swap carrier confirmations, or password-reset emails the owner did not initiate; (2) WHOIS/RDDS records showing registrant change on a specific date, correlated with the account-compromise date; (3) historical WHOIS or WhoWas records showing the original owner's long-term registration history; (4) DNS change records showing a redirect away from the original server within hours of the registrant change; (5) evidence of the attacker monetizing the domain — parking-page revenue, phishing emails sent from the domain, or a ransom demand.

The evidence that weakens a theft claim — and which panels have used to deny transfer — includes: gaps in the ownership chain where a prior transfer is not explained; an owner who registered the domain only days before the alleged theft; a domain that was already the subject of a prior dispute; and any suggestion that the owner voluntarily shared credentials with the person now holding the name.

Courts evaluating a cybersquatting or conversion claim apply the same categories but under a preponderance-of-evidence standard (in most US proceedings) or the applicable national standard. An injunction application additionally requires a showing of irreparable harm — the domain's role in the owner's commercial operations, and the ongoing harm from the redirect, typically satisfies that test for an active .cloud domain.

How is a .cloud theft case different from a standard cybersquatting dispute?

A standard cybersquatting UDRP complaint targets a registrant who proactively registered a domain that infringes a mark. The original owner never held the domain. The complaint argues that the registration itself was in bad faith from day one.

A theft recovery case is different in two respects. First, the original owner held the domain — the complainant is also the rightful prior registrant — and the bad faith arose at the point of the unauthorized transfer, not at the original registration. Panels recognize this distinction and do not require the complainant to prove that the domain was originally registered in bad faith; instead, the bad-faith analysis focuses on the attacker's conduct in obtaining and using the name after the transfer.

Second, the evidence is different in character. A standard cybersquatting case relies largely on the domain's current use — parking pages, pay-per-click links, or active infringement — and on the registrant's registration history. A theft case relies primarily on account-compromise artifacts, the timeline of unauthorized changes, and the discrepancy between the attacker's profile and a legitimate registrant's profile. The argument is forensic rather than merely comparative.

This distinction also affects the choice between WIPO and a court. Courts are better positioned to evaluate forensic evidence — logs, hash records, technical affidavits — than a UDRP panel operating on a paper record without live testimony or discovery. Where the evidence of compromise is complex or the attacker contests the account-compromise narrative, a court proceeding may be the stronger forum even if it is slower.

Is there a myth worth addressing here? Many owners believe that because they "own" the domain — it was in their portfolio for years — the recovery is automatic once they file. It is not. Panels apply the three-element test to the post-theft registrant without giving automatic weight to the complainant's prior history. The prior history must be argued and evidenced, not assumed.

Related at COGNOMEN

• Court recovery and domain theft services — COGNOMEN's full range of theft reversal and litigation options
• Case study: recovering a hijacked domain across jurisdictions — strategy and outcome for a disputed transfer
• Case study: domain escrow and pre-acquisition due diligence — protecting ownership at every stage of a transaction