Takedown Requests
Takedown Requests is the single queue where every request to remove malicious or infringing content lives — phishing sites, fake mobile apps, squatted domains, impersonating social accounts, exposed code repositories, and more. You raise a takedown from the finding inside its source module; ShadowMap mints a case, dispatches abuse notices to the right hosting providers, registrars, CDNs, and browser blocklists on a timed cadence, and tracks the request through to removal — all visible from one page.
Overview
The Takedown Requests page (Dashboard → Takedown Requests) is a working queue, not a static report. At the top, a metrics strip and an optional analytics panel summarize the health of your takedown operation. Below that, status tabs segment requests by where they are in the lifecycle, a filter/search bar narrows the list, and the table lists each request with its title, source module, status, priority, requester, assignee, relevance, and request date. Selecting any row opens a detail drawer with the full case history, including a sanitized record of every abuse notice ShadowMap has dispatched on your behalf and the next scheduled action.
You do not create a takedown here. You create it from the finding in its module (Phishing & Impersonations, Fake Applications, Domain Squatting, and so on), and this page is where you then manage and track it.
Customer-tier feature
Takedown enforcement is available only on active customer accounts. Trial (POC), red-team, partner, and vendor accounts can see findings but cannot raise takedowns — the request is rejected at submission time.
How it works
The mechanics below are the part you cannot infer from the UI. They determine when a request can be raised, what ShadowMap actually does after you submit, and how the status you see in the queue gets updated.
Raising a request requires an attestation
A takedown notice asserts — to a hosting provider, registrar, or platform — that you are authorized to act and that the content is genuinely abusive. Because that assertion is made on your behalf, ShadowMap requires the requester to attest to authorization, good-faith belief, and accuracy before the request is created. A submission without that attestation is rejected (HTTP 422) and no request is created. The attesting user, the timestamp, and the attestation wording version are stored with the request as a permanent audit trail — the record that defends your authority if the target files a counter-notice or alleges wrongful takedown.
Not every module is enforceable
Some findings are intelligence you can act on internally but cannot have "taken down" because no provider has the authority to remove the data:
- Data Breaches and Stealer Logs reference dumps that are already published or shared peer-to-peer across paste sites and dark-web channels. There is no provider to email. Attempting to raise a takedown on these returns a 422 with an explanatory message.
- Ransomware leak sites (
.onion), Telegram conversations, and Executive Leaks can have a tracking request created, but ShadowMap's automated dispatcher will not email an abuse channel for them — there is no reachable provider. These are handled by ShadowMap's analyst team rather than the automation.
For every other module (phishing, fake/mobile apps, domain squatting, social media, code repositories, S3 buckets, Docker containers, leaked files), the request is both tracked here and eligible for automated dispatch.
What happens after you submit
When a request is created it lands in Requested status, and the dispatch engine takes over:
- Case ID minted. On first dispatch the request is assigned a unique case ID that ties together every notice sent for it.
- Provider resolution. ShadowMap resolves the ordered list of providers responsible for the malicious content — for example the hosting provider, the domain registrar, the CDN fronting the site, and relevant browser/abuse blocklists (Google Safe Browsing, PhishTank, URLhaus, Microsoft SmartScreen, and others).
- Abuse notice dispatched. A templated abuse notice is sent to each provider — by email, by a provider abuse API (e.g. Cloudflare, GitHub, GoDaddy), or by a web-form submission queued for an analyst. Your authorization letter is attached automatically when available.
- Status advances. On the first successful dispatch the request moves from Requested to Ongoing and the processed-on time is recorded.
Timed escalation cadence
The dispatcher runs continuously (roughly every 15 minutes) but is not spammy: it only fires a step when that step is due. Each request progresses through up to four cadence steps per provider, with the timing driven by the request's priority:
| Step | Purpose |
|---|---|
| Initial dispatch | The first abuse notice to the provider |
| Reminder | A follow-up if the provider has not actioned the request |
| Escalation | Widens recipients to the parent provider and your legal contact |
| Internal alert | Flags a stale case to the ShadowMap team for manual escalation |
Higher-priority requests run a tighter cadence (the reminder, escalation, and internal-alert steps fire sooner). Each step is sent at most once per provider — restarts and concurrent runs cannot double-send the same notice.
Priority is operational, not cosmetic
The priority you set when raising a request directly controls how fast ShadowMap chases the provider. Reserve High/Critical for confirmed, active abuse where every hour of exposure matters.
How status gets updated
A request's status reflects where it sits in the removal lifecycle. It is advanced automatically by the dispatcher (Requested → Ongoing on first send) and by inbound provider replies and removal-verification probes; analysts can also set the terminal Takedown denied state, or Counter notice received when the target contests the removal. Every transition is written to a status-history timeline you can read in the detail drawer.
Understanding the data
Status lifecycle
The tabs across the top correspond to these statuses:
| Status | Tab | Meaning |
|---|---|---|
| Requested | Requested | Submitted; the initial notice is queued or in flight |
| Ongoing | Ongoing | At least one abuse notice has been dispatched; awaiting provider action |
| Pending with hosting | Pending | Handed off to the hosting provider, who is processing it |
| Awaiting response | Awaiting | Notice sent; waiting on a reply from the provider/platform |
| Completed | Completed | The malicious content has been removed (terminal) |
| Takedown denied | Denied | The provider declined the request (terminal) |
| Counter notice received | (within All) | The target contested the removal |
| Dismissed | (within All) | Closed without enforcement — tracked for the record but no further dispatch will occur |
The All tab shows every request regardless of status. Tab labels carry a count badge so you can see queue depth at a glance.
Table columns
The table is column-customizable (the column picker lives in the page header). Title is always shown; the rest can be toggled.
| Column | Description |
|---|---|
| Title | What is being taken down — derived from the underlying finding, not free text |
| Module | The source module the finding came from (Phishing, Fake Applications, Domain Squatting, …) |
| Status | Current lifecycle status (see table above) |
| Priority | Low / Medium / High / Critical — drives the escalation cadence |
| Requested By | The contact who raised the request |
| Assigned | The team member responsible for the request (assignable in bulk) |
| Relevance | A relevance score for the underlying finding |
| Requested On | When the request was raised (shown as relative time) |
Each row also exposes inline actions: bookmark (star), a comment thread, and share.
Metrics strip
Five at-a-glance cards summarize the queue. Clicking the Active Takedowns, Requested, Ongoing, or Completed card jumps to the matching tab (the Avg Resolution card is informational only):
| Metric | What it counts |
|---|---|
| Active Takedowns | All requests not in a terminal state |
| Requested | Requests still in Requested status |
| Ongoing | Requests with notices dispatched and in progress |
| Completed | Requests where content was removed |
| Avg Resolution | Average days from request to completion |
Analytics panel
Toggled from the page header, the analytics panel renders four charts: Status Distribution (donut), Takedowns by Module (which surfaces generate the most enforcement work), a 30-Day Trend of new requests versus completions, and a Resolution Time histogram. Use these to spot which brand-abuse channels are hitting you hardest and which providers are slow to respond.
Detail view
Selecting a row opens a drawer with the full case file. Use j / k to move between rows, Esc to close.
Badges — status, priority, and source module at the top.
Actions — Share the request, and View Source to jump back to the originating finding in its module.
Takedown Details — title, module, status, priority, requested-by, requested-on, processed-on, completed-on, and assignee.
Status Timeline — every status transition with its date and the actor who made the change, giving you a defensible audit trail.
Takedown Dispatch Progress — the customer-facing view of the automation. This shows what ShadowMap actually did on your behalf, with internal details (abuse mailbox addresses, message IDs, staff names) deliberately stripped:
- A summary strip: how many notices were dispatched, how many are in a manual queue (web-form submissions awaiting an analyst), how many are in progress, and the total events.
- A next-action ETA: the next scheduled cadence step and when it is due (flagged "due now" if overdue — it fires on the next dispatch cycle).
- A provider timeline: one entry per provider (e.g. "Hosting provider", "Domain registrar", "Cloudflare", "Google Safe Browsing"), collapsing repeated cadence attempts into a single row with the attempt count, the latest cadence step, and the current status.
Reason — the justification supplied when the request was raised.
Submitting a takedown
You submit takedowns from the finding, not from this page.
- Open the relevant finding in its module — for example a confirmed phishing URL in Phishing & Impersonations, a counterfeit app in Fake Applications, or a squatted domain in Domain Squatting.
- Choose Request Takedown on the finding.
- Fill in the details: title (pre-derived from the finding), reason, priority, and contact information.
- Attest to authorization, good-faith belief, and accuracy. This is required — the request cannot be created without it.
- Submit. The request is created in Requested status and the dispatch engine begins working it automatically.
- Track and manage it from this page.
Modules that can originate a takedown include Phishing & Impersonations, Fake Applications, Mobile Applications, Domain Squatting, Social Media, Code Repositories, S3 Buckets, Docker Containers, and Leaked Files. (Data Breaches and Stealer Logs cannot — see How it works.)
One request per finding
ShadowMap rejects a duplicate takedown for a finding that already has an open request (HTTP 409). Manage the existing request rather than raising a second one.
Filtering and search
The filter bar supports field-scoped filters and free-text search across:
- Title, Module, Status, Priority, Requested By, Assigned To, and Requested On (date filter).
- A Bookmarked toggle to show only starred requests.
Filters combine with the active status tab. You can save the current view, and the applied filter (including AND/OR logic) is carried through to Export so the exported file matches exactly what you see on screen.
Taking action
Select one or more rows (or use Select all) to reveal the bulk action bar:
| Action | Effect |
|---|---|
| Assign | Route selected requests to a team member or team (with a searchable picker) |
| Clear Assignee | Remove the current assignee |
| Bookmark | Star selected requests for quick recall |
| Share | Share selected requests via the configured integrations |
Per-row, you can bookmark, comment (with comment templates), share, and open the detail drawer. Use Export in the filter bar to generate a downloadable file of the current, filtered list as a background job.
Use assignment to run takedowns as a workflow
For teams handling volume, assign each request to an owner and work the Requested and Ongoing tabs as a queue. The dispatcher handles provider chasing; your team handles verification and any provider that requires a manual web-form submission.
Common questions
Do I send the abuse emails myself? No. After you raise the request, ShadowMap resolves the responsible providers and dispatches the abuse notices automatically — by email, provider API, or a web-form submission an analyst completes. You track the result here.
Why is my request still "Requested" and not "Ongoing"? A request flips to Ongoing on the first successful dispatch. If it is sitting in Requested, the initial notice has not gone out yet (the dispatcher fires on a ~15-minute cycle), the source finding may be an orphaned record, or no provider has been resolved for it yet. Open the drawer's dispatch progress to see the next scheduled action.
Why can't I raise a takedown on a data breach or stealer log? That data is already public or shared peer-to-peer, and no provider has the authority to remove it on request. ShadowMap surfaces it as intelligence but does not offer takedown enforcement for those sources.
What does priority actually change? Priority controls the escalation cadence — how quickly ShadowMap sends reminders, escalates to a parent provider plus your legal contact, and raises an internal alert if the provider does not respond. Higher priority means faster chasing.
What is the "manual queue" in the dispatch progress? Some providers only accept abuse reports through a web form, not email or API. Those dispatches are queued for a ShadowMap analyst to submit by hand; they show in the summary strip as "Manual queue" until completed.
Can I see who submitted a request and when, for compliance? Yes. Each request stores the attesting user, timestamp, and attestation version, and the status timeline records every transition with its actor — a defensible audit trail for counter-notice or wrongful-takedown disputes.
Who can raise takedowns? Only active customer-tier accounts. Trial, partner, vendor, and disabled accounts can view findings but cannot create takedown requests.
Related
- Phishing & Impersonations — the most common source of takedown requests; raise removals for phishing sites here.
- Fake Applications — counterfeit mobile apps; request store/listing removals.
- Domain Squatting — abusive lookalike domains; request registrar/hosting takedowns.
- Social Media — impersonating accounts and profiles.
- Code Repositories — exposed source/secrets; request removal from the code-hosting platform.
- Takedowns dashboard — the dashboard tile and metrics for takedown activity.
- SLA Policies — define response/resolution targets that frame how aggressively you prioritize takedowns.
- Severity & Status — how severity and status drive prioritization across ShadowMap.