brand_impersonation_takedown v1.0.0

name: brand_impersonation_takedown description: Respond when a brand is impersonated online: spot fake sites, phishing pages, and copycat accounts, build an evidence packet that survives review, file takedowns with registrars, hosts, search engines, and platforms in parallel, and warn customers while cases run. Use when a fake site, shop, account, app, or phishing email copies a brand.

Brand Impersonation Takedown

Purpose

Stop a copycat from collecting passwords, payment details, or orders in a brand name, and do it in an order that holds up. The skill covers the full run: confirm the impersonation, capture evidence before anything is filed, identify who controls each layer of the fake, file in parallel across registrar, host, CDN, browser blocklists, search, and platform, warn customers from official channels only, and track every case to a verified closure or a dated escalation.

The output is a case packet folder, a filing log with a reference for every channel, a published customer warning, and a closure check. One filing never finishes the job. A registrar suspends a domain, a host deletes files, a platform removes an account, and a blocklist warns visitors. Each needs its own report with the same evidence.

Workflow

1. Confirm it is impersonation before acting. Open the suspect page or profile from a safe browser session and compare it with the official site or account. Impersonation means it presents itself as the brand: copied name, logo, photos, page layout, support claims, or sign in and checkout flows. A critical review, a fan account that labels itself as unofficial, a reseller, or a parody that a reasonable visitor would not mistake for the brand is a different problem. Note the call and who made it in the case record.

1. Classify the case, since the kind sets the channel list. Use one of: phishing-site, fake-shop, copycat-account, fake-app, phishing-email, other. A copycat account that links to a phishing site is two cases in one: file the platform reports for the account and the site reports for the domain.

1. Build the case packet before filing anywhere. Run python3 ~/workspace/skills/brand-impersonation-takedown/scripts/build_case.py <case-dir> --brand "<brand>" --bad-url "<exact bad URL>" --official-url "<official URL>" --kind <kind> and work through the evidence-checklist.md it creates. Pages often vanish or change after the first report lands, and a reviewer who cannot see the harm in one read will close the case. The packet needs full page screenshots with the URL bar visible, a side by side with the real page, the exact URL as text, a UTC timestamp, saved page source, the redirect chain that led there, how it was found, and proof of brand rights.

1. Protect the capture. Never enter real credentials, a real payment card, or a real login code on the fake page to get a better screenshot. Never order, pay, or message the operator from a real account. For a phishing email, save the original message as a file with full headers intact instead of forwarding it inline, which strips headers reviewers use to trace the sender.

1. Identify who can act, and write each one into filing-log.csv before sending anything. Find the registrar and its abuse contact with ICANN Lookup at lookup.icann.org. Find the host by resolving the domain to an IP and looking up the owner of that IP range, with nameserver records as a second hint. Note whether a CDN sits in front, since a CDN hides the origin host and becomes a filing channel of its own. Full per channel steps are in references/channel-guide.md.

1. Pick the legal basis that matches each form, and do not mix them. Impersonation is the claim that the account or page pretends to be the brand. Trademark is the claim that a registered name, logo, or slogan is used in a way likely to confuse people, and it needs registration details. Copyright is the claim that a specific photo, video, text, or design was copied, and it needs a link to the original work. Counterfeit is the claim that goods for sale are fake, and it needs registry details. Filing a copied photo as trademark, or a confusing handle as copyright, puts a true case in front of the wrong test and it fails on paper.

1. File in parallel, in the order in references/channel-guide.md. Registrar, host, and CDN first, since they can take the page down. Google Safe Browsing, Microsoft SmartScreen, and the Anti-Phishing Working Group next, since browser warnings cut traffic while the takedown runs. Platform impersonation and IP reports next, plus a separate report on each post, ad, or listing doing harm. Search legal removal after that. Authorities last: they record the harm, they do not remove the page.

1. Use the generated report-body.txt as the base text for every filing and adjust only the channel name, the requested action, and the evidence list. State who is filing and that they are authorized to act for the brand, give a business email on the brand domain, list the impersonating URL and the official URL side by side, describe in plain words what the page collects, and ask for a case reference. Keep the bad URL defanged, written as hxxps and example[.]com, in tickets, chats, and warnings. Paste the real URL only inside the filing form itself.

1. Warn customers while the case runs, from verified official channels only. Use the templates in references/templates.md: a short pinned post, and a banner or email version when sign ins or payments are at risk. The warning names the fake in defanged form, gives the one official domain or account list, tells people who already entered details exactly what to do next (change the password on the real site, turn on two factor authentication, check account activity, contact their bank if payment details went in), and promises one update when the case closes. Never warn from a new or unverified account, since that reads as part of the scam.

1. Log every filing the moment it goes out: channel, target name, time in UTC, case reference, and status in filing-log.csv. A filing with no reference gets a follow up note asking for one. If a form gives no reference, log the confirmation screenshot filename instead.

1. Follow up on a clock, not on a feeling. Recheck the bad URL and each open channel at least once a day while the page is live. Send the follow up template with the packet attached again, so the reviewer does not need to rebuild the case. If a registrar has not acted, escalate to ICANN Contractual Compliance with the registrar name, the filing date, and proof the registrar was contacted first. If a platform denies a report, appeal once with any missing proof the denial names, then switch the claim to the route that fits better, for example copyright for reposted photos after a trademark denial.

1. Consider a domain dispute only after the abuse filings are running. The UDRP is the ICANN route for a gTLD domain name itself: the brand must prove the domain is identical or confusingly similar to its mark, the registrant has no rights or legitimate interests in it, and it was registered and is being used in bad faith. Outcomes are transfer, cancellation, or denial. The URS is faster for clear cases and can only suspend. Both are slower than an abuse report during live phishing, so neither delays step 7.

1. Close the case only on proof. The bad URL returns an error or a registrar or host suspension page, the account or listing is gone, and browser warnings have cleared, all checked directly and dated in the log. Publish the all clear template, unpin the warning, and keep the packet. Copies often return under a new domain or handle, so add the bad domain, its registrar, and any reused text or images to the watch list the brand checks in future sweeps.

1. Run a short prevention pass at closure. Record which lookalike domains the brand should register or monitor, whether the official site and profiles link to each other so customers can verify them, whether support staff know the escalation contact list, and whether a standing abuse mailbox and a saved evidence folder exist for the next case. Keep this to what the case actually showed. Do not turn one incident into a large program without the brand owner agreeing to it.

Output Contract

Deliver, for each case:

1. A case folder built by scripts/build_case.py containing case.json, evidence-checklist.md with every item ticked or marked not applicable with a reason, filing-log.csv, and report-body.txt.
2. An evidence folder holding the screenshots, saved page source, any original phishing email file with headers, the ICANN Lookup result, and the host lookup result, each file named with the date and what it shows.
3. A filing log where every channel that applies has a row with target, filing time in UTC, reference, status, and outcome. Channels that do not apply are marked with the reason, for example no CDN in front.
4. A customer warning published on an official channel, with its URL recorded in the case notes, plus the closing all clear post when the case ends.
5. A one page case summary: what the fake was, how it was found, what harm is known, which channels acted and when, which channels never replied, and what stays on the watch list.

Operating Rules

• Evidence first, filings second. A report filed before the screenshots exist is a report that cannot be repaired after the page changes.
• File in parallel. Waiting for a registrar before contacting the host or the blocklists gives the fake free days. Each channel controls a different layer and ignores reports sent to the others.
• Match the claim to the form. Impersonation, trademark, copyright, and counterfeit are different tests run by different teams. The fastest route is the one whose test the evidence actually passes.
• Never promise a takedown time. No primary source in this field guarantees one. Say what was filed, when, and what the next check date is. Timelines in secondary guides conflict with each other and are not a basis for a promise to a customer.
• A browser warning is not a takedown, and a search removal is not a takedown. Report both in the summary as what they are: fewer people reaching the page, with the page still live until the registrar or host acts.
• Keep personal data out of the packet. Customer reports prove harm by count and by type of loss. Names, account details, and ID documents go only into a platform form that asks for them, never into a shared evidence folder or a warning post.
• File IP reports only for rights the brand actually holds, in the name of the holder or an authorized representative. Forms warn that false IP claims can cost the filer their own account, and platforms share the filer contact details with the account holder on IP reports.
• Verify every support address and form from the official site or help center before sending documents. Fake support numbers and paid removal services target brands mid incident. No legitimate registrar, host, or platform charges a fee to receive an abuse report.
• This skill is an operating procedure, not legal advice. A case involving large losses, threats, or a dispute over who owns the mark goes to a lawyer, with the packet as the starting file.