Step-by-step: recover a .app domain used for phishing

A stranger registers a domain that mirrors your app's name, dresses the site in your brand colors, and begins harvesting user credentials. Every day the phishing site operates, real customers hand over real passwords — and your brand absorbs the reputational damage. The question is not whether to act. It is which legal mechanism reaches the domain fastest, and what evidence you need to win.

To recover a .app domain used for phishing, a brand owner files a UDRP complaint before WIPO or another accredited provider. All three elements of Paragraph 4(a) must be satisfied: confusing similarity to a mark you own, no legitimate interest by the registrant, and registration and use in bad faith. The WIPO filing fee for a single-member panel starts at USD 1,500, and a straightforward case is typically resolved in about two months, with the only remedies being transfer or cancellation of the domain.

This guide walks each step of the process, identifies the trap hidden in each stage, and explains what evidence decides the outcome for a phishing-specific .app dispute.

Why does the UDRP apply to .app, and what makes phishing a strong bad-faith case?

The .app zone is a new generic top-level domain (gTLD) operated by Google Registry; because it is a gTLD, every accredited registrar is bound by the UDRP, meaning a complainant can bring a case before WIPO, the Forum, the Czech Arbitration Court (CAC), or the ADNDRC using the same standard three-element test. The .app suffix carries an implicit trust signal — users expect an application download or a software service — which makes it a particularly attractive vehicle for phishing actors who want the domain to look legitimate. That same trust-signal misuse is exactly what panels recognize as strong evidence of bad faith under Paragraph 4(b): using a domain confusingly similar to a well-known mark to attract users who believe they are reaching the mark owner's site.

Phishing cases present an unusually clear fact pattern. The registrant cannot plausibly claim a legitimate interest in operating a credential-harvesting page that mimics your brand. Panels have consistently held that using a confusingly similar domain to deceive users for commercial gain — or to damage the mark owner — satisfies the bad-faith element with minimal further argument. The challenge, in practice, is not the legal theory. It is assembling evidence before the site goes dark and destroying your proof.

The .app zone enforces HTTPS for all domains. Phishing actors sometimes exploit that requirement to display a padlock icon, making the fake site look more credible to users. Screenshots should capture both the URL bar and the padlock to demonstrate the deliberate trust manipulation to the panel.

Step 1: Secure your evidence before the site disappears

Phishing sites are often taken down quickly — by the host, by Google's Safe Browsing infrastructure, or by the operator covering tracks — and a bare domain with a parked page no longer shows the panel what the domain was used for. Your first action is preservation, not filing. Collect everything now.

Archive the live site using a third-party timestamping service or Internet Archive. Take full-page screenshots that capture the URL bar, the page content, and any login form. Download the page source. Run a WHOIS/RDDS query and save the result with a timestamp; the registrant's details may be masked by a privacy service, but the registrar and registration date are visible and material. Obtain abuse reports, phishing alerts from security vendors, or any user complaints you have received — these corroborate harm.

The trap in Step 1 is speed. Many brand teams open an internal ticket, escalate to legal, and wait two weeks for approvals. In that time, the operator may change the content or let the domain expire. If the domain expires or is deleted before a complaint is filed, a UDRP panel has no jurisdiction to transfer it; the domain enters the deletion-and-redemption cycle and recovery becomes a different, slower problem. Act on evidence collection the same day you identify the site.

Step 2: Confirm your trademark rights and the similarity test

Before drafting a complaint, confirm that you have "rights in a mark" within the meaning of Paragraph 4(a)(i). Those rights can be a registered trademark, a service mark, or — in some panels' view — common-law rights evidenced by substantial use. Registered rights are always preferable: the registration certificate establishes the right cleanly and the filing date may predate the domain registration, which is relevant to the bad-faith analysis.

The similarity analysis for .app domains has one consistent trap. Panels assess confusing similarity by comparing the domain's second-level label — the string before ".app" — against your mark. They typically disregard the TLD suffix in the comparison. A domain like "yourbrand-login.app" is compared to the mark YOURBRAND, and the suffix "-login" is likely found to increase rather than diminish confusion because login pages are exactly what phishers build. Document the side-by-side comparison explicitly in the complaint; do not leave it to the panel to make the connection.

Where your mark is registered in one jurisdiction but not another, check whether it predates the domain's creation date. A trademark application filed after the domain was registered does not automatically defeat the complaint, but panels weigh the chronology. In a recent matter — a .app phishing site targeting a SaaS brand's login portal, spring 2025 — we established confusing similarity through both a registered mark and four years of commercial use predating the domain, which removed any ambiguity about the first UDRP element and let the complaint focus squarely on the bad-faith evidence.

For a broader read on whether the three UDRP elements are met in your specific situation, see our UDRP recovery service page, which sets out the evidentiary standard in detail.

For a read on whether the three UDRP elements are met in your case, reach us at info@cognomenlaw.com.

Step 3: Choose the right UDRP provider for a .app phishing complaint

All four accredited UDRP providers — WIPO, the Forum, the CAC, and the ADNDRC — can hear a .app complaint. The choice matters more than many complainants realize, because provider selection affects timeline, panelist pool, and cost. WIPO and the Forum together handle approximately 97% of all UDRP proceedings. For a phishing-focused case requiring fast resolution and a well-developed body of precedent on bad faith, WIPO is the most commonly selected forum.

WIPO's single-member panel fee for one to five domains is USD 1,500. If you expect the registrant to contest the case aggressively — which is less common in phishing scenarios, since the operator rarely wants scrutiny — you may consider requesting a three-member panel at USD 4,000. The three-member option adds legitimacy to a consequential transfer decision and reduces the risk of an outlier result, but it adds cost and, usually, a few additional weeks. WIPO also offers an expedited option for single-panel cases of up to five domains, delivering a decision in about one month; for an active phishing site causing live customer harm, that accelerated track is worth considering.

The Forum's entry-level filing fee begins around USD 1,300 for one to two domains, making it marginally less expensive than WIPO for small filings. CAC fees begin lower still, though it is the least frequently used of the four major providers. The practical difference in panelist quality between WIPO and the Forum, for a routine phishing complaint backed by clear evidence, is smaller than the fee gap suggests.

The trap in provider selection is assuming all outcomes are identical. Panelist pools differ. Procedural timelines differ in practice even when the rules are nominally the same. In our practice, we assess the specific fact pattern — registrant jurisdiction, volume of domains, presence of a privacy shield — before recommending a forum, rather than defaulting to the same provider for every case.

Step 4: Draft the complaint — what a phishing case demands

A UDRP complaint is a structured legal submission, not a demand letter. Each of the three Paragraph 4(a) elements must be addressed in a separate argument, supported by exhibits, and stated with precision. For a phishing-specific .app case, the complaint should cover the following points in this order.

First, establish trademark rights and the similarity. Attach registration certificates. State the registration numbers and dates. Show the comparison between the domain label and the mark and explain why the added terms (login, secure, app, your brand name) increase, not reduce, confusion.

Second, address the absence of legitimate interest. The registrant almost certainly has no Paragraph 4(c) safe harbor: it is not making a bona fide offering of goods or services under that name, it is not commonly known by the name, and there is nothing noncommercial or fair-use about credential harvesting. State this directly and attach evidence — screenshots of the phishing page, abuse reports, and any notification to the registrant that you own the mark (which the registrant will have ignored).

Third, prove bad faith in registration and use. For phishing, the strongest grounds are the Paragraph 4(b)(iv) factor — attracting users for commercial gain by creating a likelihood of confusion as to source — and the broader panel consensus that using a domain to impersonate a mark owner's digital service is paradigmatic bad faith. Attach the archived screenshots, the security-vendor reports, and any consumer reports of credential theft. If the registrant used a privacy or proxy service to mask identity, note it; panels treat concealment as a corroborating bad-faith indicator.

The trap in drafting is brevity without precision. A complaint that says "the registrant is phishing our users" without a methodical element-by-element argument may still win on default, but it gives a contested panel little to work with. A well-built complaint survives a disputed proceeding, not just a default. For context on how panels reason through similar evidentiary records, our analysis of passive holding cases shows how fact-specific the bad-faith analysis remains even when the registrant does nothing visible with the domain.

Step 5: What happens after you file — the 20-day window and what comes next

Once the complaint is filed and the provider determines it is formally compliant, the case commences and the registrant has 20 days to file a response. That window is set by the UDRP Rules; it does not shorten even for an active phishing site. The registrar is typically notified and may place the domain on registrar lock, preventing transfers but not necessarily taking the site offline during the proceeding.

If the registrant does not respond — which is common in phishing cases, since the operator usually has no legitimate argument to make and no interest in appearing before a panel — the case proceeds to a panel decision on the record submitted by the complainant. A default does not mean automatic transfer: the panel still evaluates the evidence and must be satisfied that the three elements are met. Complaints built on thin records can, and occasionally do, fail even without opposition. That is why Step 4 matters.

After the response window closes, the provider appoints a panelist. The panelist reviews the complaint and any response, may request additional submissions in limited circumstances, and issues a decision. The full cycle — commencement through decision — typically runs about two months for a standard single-panel case. If the expedited WIPO track is used, the decision arrives in roughly one month.

Once a transfer order is issued, the registrar implements it within ten business days unless the registrant files suit in a court of competent jurisdiction to stay the transfer. In a phishing scenario, a stay is rare: the registrant would need to go on the record in a court and defend their use of a credential-harvesting page. Implementation is usually swift.

If a phishing domain is actively harming your users and you need to assess the fastest route to a transfer order, email info@cognomenlaw.com.

Step 6: What if the UDRP alone is not enough?

The UDRP delivers transfer or cancellation. It does not deliver damages, injunctions, or criminal referrals. For many brand owners, the transfer is the only relief they need: once the domain is in their hands, the phishing operation loses its platform. But the UDRP has limits, and a .app phishing case may call for parallel or subsequent action.

If you need to recover multiple domains — say, approximately a dozen .app variants registered in a coordinated attack — the UDRP allows one complaint to cover multiple domains only when they share a single registrant. If the operator split registrations across different accounts or used different registrant identities, you may need separate complaints or a different mechanism. Registrar abuse escalation, run in parallel with the UDRP, can sometimes accelerate takedown through the registrar's own acceptable-use policy, even before a panel decision arrives.

If the phishing operation has caused quantifiable financial harm — diversion of sales, fraudulent transactions processed through the fake site — and the registrant is locatable, US anticybersquatting litigation is the only path that reaches money damages. That route is longer, more expensive, and requires local litigation counsel in the relevant jurisdiction, but it adds a deterrent that the UDRP's purely equitable remedy does not.

For a .app domain registered by an operator in a jurisdiction where a UDRP panel's transfer order may face implementation difficulties — an edge case, but one we encounter in our practice — the parallel options of registrar escalation and, where necessary, court action provide a safety net. Our comparison of URS and UDRP for new gTLDs sets out when suspension — the URS remedy — may be a faster interim step even where transfer is the ultimate goal.

The realistic next step for a brand owner facing a .app phishing domain

Speed of evidence collection and precision of legal argument are the two variables you control. The UDRP timeline is set by the Rules. The panel is appointed, not chosen. The registrant's conduct is what it is.

What changes outcomes is the quality of the complaint. A complaint that documents the phishing conduct through archived pages, security-vendor reports, and consumer notices — and that argues each Paragraph 4(a) element with specificity — wins even when contested. A complaint that relies on the panel to infer what the screenshots show is a complaint that depends on the panel's patience.

We regularly advise brand owners who discover phishing campaigns the same day they begin, and who need both immediate registrar escalation and a filed complaint within days. The steps above can be run in parallel, not sequence, when the situation demands it. The trap is treating the guide as a linear checklist when a live phishing attack calls for simultaneous action on multiple fronts. Assess the site, preserve the evidence, check your marks, and file — in that order, as fast as the situation allows.

Related at COGNOMEN

• UDRP recovery service — file a complaint and recover a domain through WIPO, the Forum, CAC, or ADNDRC
• Analysis: recovering a passively held .com — how panels reason through dormant bad-faith registrations
• URS vs. UDRP for new gTLDs — when suspension is faster than a transfer order

Author: Cordelia Roe — UDRP complainant practice & gTLD recovery; domain transactions and brand protection. Meet the team.

Speak with Cognomen Law

For a scoped view of your domain matter, contact info@cognomenlaw.com. Discuss your matter

Domain in disputeYour sideI want to recover a nameI received a complaint — I need a defensePortfolio / brand protectionWhat happenedEmailI agree to the processing of my enquiry as described in the privacy policy.Assess my case

No obligation. Confidential. We reply within two hours in business hours.

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@cognomenlaw.com.