Prerequisites
- Target system, dependencies and environment configured.
Usage
Purpose
When attackers set up a phishing page impersonating your login, register a lookalike domain, or create fake social profiles of your brand/executives, taking that infrastructure down protects your users and customers from being phished through it. Takedown is the process of getting malicious content removed by the parties who can remove it — registrars, hosts, platforms. This skill covers running a takedown workflow, the response that shrinks the attacker's reach against your organisation.
When to use it
When you discover malicious infrastructure targeting your organisation — from phishing analysis (a harvest page), certificate-transparency/domain monitoring (a lookalike domain), or dark-web/brand monitoring (impersonation content). It's the action arm of external threat detection.
Procedure
- Identify who can take it down. Different infrastructure has different responsible parties, and knowing which to contact is half the battle:
- A phishing page — the hosting provider (they can remove the content) and the domain registrar.
- A lookalike/malicious domain — the registrar (for removal) and, faster, browser/email blocklists (Google Safe Browsing, Microsoft SmartScreen) which flag it in browsers even before removal.
- Fake social profiles / brand impersonation — the platform (each has an impersonation/abuse reporting process).
- Malicious content in search/ads — the search engine or ad platform.
- Gather evidence. A takedown request needs proof: the malicious URL, screenshots of the impersonation/phishing, evidence it's harming your users, and (for brand cases) proof of your trademark/ownership. Well-documented requests get actioned faster.
- Report through the right channels. Submit to the responsible party's abuse/takedown process — registrar/host abuse contacts, platform impersonation reporting, and browser/email blocklists. Blocklisting is often the fastest protection (it flags the site to users quickly, even before the host removes it), so do it in parallel with the removal request.
- Use takedown services for scale. For organisations facing frequent impersonation, commercial brand-protection/takedown services (and some threat-intel providers) handle detection and takedown at scale with established relationships that speed removal. Doing it in-house works but is slower per-incident.
- Blocklist in parallel — protect users immediately. Removal can take time (hours to days depending on the party); meanwhile, getting the URL onto browser/email blocklists and into your own email/web filtering protects your users now. Immediate protection matters more than waiting for removal.
- Preserve evidence before it disappears. Capture the malicious content before takedown (screenshots, the page source, IoCs) — for the record, for the investigation, and because it may vanish once reported (the phishing-analysis and IoC skills).
- Track and follow up. Takedowns aren't always immediate; track requests, follow up if not actioned, and escalate (some registrars/hosts are slow or unresponsive). For persistent attackers, involve law enforcement.
Cheatsheet
attacker infra targeting you (phishing page / lookalike domain / fake profile) -> TAKE IT DOWN
= get it removed by who CAN remove it (registrar/host/platform) -> shrinks attacker reach
WHO can take it down (knowing this = half the battle)
phishing page -> HOSTING provider + registrar
lookalike domain -> registrar + BROWSER/EMAIL BLOCKLISTS (Safe Browsing/SmartScreen — faster)
fake social/brand -> the PLATFORM (impersonation/abuse process)
malicious search/ads -> search engine / ad platform
process
GATHER EVIDENCE (URL, screenshots, harm, trademark/ownership) -> faster action
REPORT to the right channel (abuse contacts / platform reporting / blocklists)
BLOCKLIST IN PARALLEL -> protects users NOW (removal takes hours-days) — immediate > waiting
takedown SERVICES for scale (frequent impersonation — established relationships speed it)
PRESERVE evidence before it disappears (may vanish once reported)
TRACK + follow up + escalate (slow/unresponsive parties ; law enforcement for persistent)
Reading the workflow
- Knowing the right party to contact (host for content, registrar for domain, platform for profiles, blocklists for browser protection) = half the battle; a takedown request to the wrong party stalls. Match the infrastructure to who can remove it.
- Blocklisting done in parallel with removal = users protected immediately; removal can take hours to days, but blocklisting flags the site in browsers/email fast. Waiting only for removal leaves users exposed meanwhile — immediate protection is the priority.
- A well-documented request (URL, screenshots, harm, ownership) = actioned faster; sparse requests get deprioritised. Evidence quality drives takedown speed.
- Frequent impersonation handled in-house = slow per-incident; takedown services with established provider relationships scale better for organisations facing many attacks.
- Evidence not preserved before takedown = the content may vanish once reported, losing it for investigation and record. Capture it first.
- Slow/unresponsive registrars or hosts = expected sometimes; track, follow up, escalate, and involve law enforcement for persistent attackers. Takedown isn't always immediate.
Pitfalls
- Waiting only for removal. Takedown takes time; blocklist in parallel to protect users immediately. Immediate protection matters more than waiting for the host to act.
- Contacting the wrong party. A request to someone who can't remove the content stalls; match the infrastructure (host/registrar/platform/blocklist) to who's responsible.
- Sparse takedown requests. Poorly-documented requests get deprioritised; provide the URL, screenshots, evidence of harm, and ownership proof for faster action.
- Not preserving evidence. Content may disappear once reported; capture it first for the record and investigation.
- No follow-up. Takedowns aren't always immediate or successful; track requests, follow up, and escalate slow/unresponsive parties.
- Doing high-volume takedowns manually. For frequent impersonation, in-house is slow; takedown services scale with established relationships.
References
- Google Safe Browsing, Microsoft SmartScreen, and APWG reporting (blocklisting)
- The phishing-email-analysis, certificate-transparency, and dark-web-monitoring skills (detection sources)
- Registrar/host abuse-reporting processes and platform impersonation-reporting docs
- Commercial brand-protection / anti-phishing takedown services
Inputs
- Relevant source code, logs, network traces, or system specifications.
Outputs
- Analysis findings, security audit report, or generated code artifacts.
1---2name: takedown-workflow3description: Use when getting malicious lookalike sites, phishing pages, and impersonation content removed — the process for reporting and taking down infrastructure that targets your organisation.4---5678## Prerequisites9- Target system, dependencies and environment configured.1011## Usage12### Purpose1314When attackers set up a phishing page impersonating your login, register a lookalike domain, or create fake social profiles of your brand/executives, taking that infrastructure down protects your users and customers from being phished through it. Takedown is the process of getting malicious content removed by the parties who can remove it — registrars, hosts, platforms. This skill covers running a takedown workflow, the response that shrinks the attacker's reach against your organisation.1516### When to use it1718When you discover malicious infrastructure targeting your organisation — from phishing analysis (a harvest page), certificate-transparency/domain monitoring (a lookalike domain), or dark-web/brand monitoring (impersonation content). It's the action arm of external threat detection.1920### Procedure21221. **Identify who can take it down.** Different infrastructure has different responsible parties, and knowing which to contact is half the battle:23 - **A phishing page** — the hosting provider (they can remove the content) and the domain registrar.24 - **A lookalike/malicious domain** — the registrar (for removal) and, faster, browser/email blocklists (Google Safe Browsing, Microsoft SmartScreen) which flag it in browsers even before removal.25 - **Fake social profiles / brand impersonation** — the platform (each has an impersonation/abuse reporting process).26 - **Malicious content in search/ads** — the search engine or ad platform.272. **Gather evidence.** A takedown request needs proof: the malicious URL, screenshots of the impersonation/phishing, evidence it's harming your users, and (for brand cases) proof of your trademark/ownership. Well-documented requests get actioned faster.283. **Report through the right channels.** Submit to the responsible party's abuse/takedown process — registrar/host abuse contacts, platform impersonation reporting, and browser/email blocklists. Blocklisting is often the fastest protection (it flags the site to users quickly, even before the host removes it), so do it in parallel with the removal request.294. **Use takedown services for scale.** For organisations facing frequent impersonation, commercial brand-protection/takedown services (and some threat-intel providers) handle detection and takedown at scale with established relationships that speed removal. Doing it in-house works but is slower per-incident.305. **Blocklist in parallel — protect users immediately.** Removal can take time (hours to days depending on the party); meanwhile, getting the URL onto browser/email blocklists and into your own email/web filtering protects your users *now*. Immediate protection matters more than waiting for removal.316. **Preserve evidence before it disappears.** Capture the malicious content before takedown (screenshots, the page source, IoCs) — for the record, for the investigation, and because it may vanish once reported (the phishing-analysis and IoC skills).327. **Track and follow up.** Takedowns aren't always immediate; track requests, follow up if not actioned, and escalate (some registrars/hosts are slow or unresponsive). For persistent attackers, involve law enforcement.3334### Cheatsheet3536```37attacker infra targeting you (phishing page / lookalike domain / fake profile) -> TAKE IT DOWN38 = get it removed by who CAN remove it (registrar/host/platform) -> shrinks attacker reach3940WHO can take it down (knowing this = half the battle)41 phishing page -> HOSTING provider + registrar42 lookalike domain -> registrar + BROWSER/EMAIL BLOCKLISTS (Safe Browsing/SmartScreen — faster)43 fake social/brand -> the PLATFORM (impersonation/abuse process)44 malicious search/ads -> search engine / ad platform4546process47 GATHER EVIDENCE (URL, screenshots, harm, trademark/ownership) -> faster action48 REPORT to the right channel (abuse contacts / platform reporting / blocklists)49 BLOCKLIST IN PARALLEL -> protects users NOW (removal takes hours-days) — immediate > waiting50 takedown SERVICES for scale (frequent impersonation — established relationships speed it)51 PRESERVE evidence before it disappears (may vanish once reported)52 TRACK + follow up + escalate (slow/unresponsive parties ; law enforcement for persistent)53```5455### Reading the workflow5657- **Knowing the right party to contact** (host for content, registrar for domain, platform for profiles, blocklists for browser protection) = half the battle; a takedown request to the wrong party stalls. Match the infrastructure to who can remove it.58- **Blocklisting done in parallel with removal** = users protected immediately; removal can take hours to days, but blocklisting flags the site in browsers/email fast. Waiting only for removal leaves users exposed meanwhile — immediate protection is the priority.59- **A well-documented request (URL, screenshots, harm, ownership)** = actioned faster; sparse requests get deprioritised. Evidence quality drives takedown speed.60- **Frequent impersonation handled in-house** = slow per-incident; takedown services with established provider relationships scale better for organisations facing many attacks.61- **Evidence not preserved before takedown** = the content may vanish once reported, losing it for investigation and record. Capture it first.62- **Slow/unresponsive registrars or hosts** = expected sometimes; track, follow up, escalate, and involve law enforcement for persistent attackers. Takedown isn't always immediate.6364### Pitfalls6566- **Waiting only for removal.** Takedown takes time; blocklist in parallel to protect users immediately. Immediate protection matters more than waiting for the host to act.67- **Contacting the wrong party.** A request to someone who can't remove the content stalls; match the infrastructure (host/registrar/platform/blocklist) to who's responsible.68- **Sparse takedown requests.** Poorly-documented requests get deprioritised; provide the URL, screenshots, evidence of harm, and ownership proof for faster action.69- **Not preserving evidence.** Content may disappear once reported; capture it first for the record and investigation.70- **No follow-up.** Takedowns aren't always immediate or successful; track requests, follow up, and escalate slow/unresponsive parties.71- **Doing high-volume takedowns manually.** For frequent impersonation, in-house is slow; takedown services scale with established relationships.7273### References7475- Google Safe Browsing, Microsoft SmartScreen, and APWG reporting (blocklisting)76- The phishing-email-analysis, certificate-transparency, and dark-web-monitoring skills (detection sources)77- Registrar/host abuse-reporting processes and platform impersonation-reporting docs78- Commercial brand-protection / anti-phishing takedown services7980## Inputs81- Relevant source code, logs, network traces, or system specifications.8283## Outputs84- Analysis findings, security audit report, or generated code artifacts.