# Auto-build takedown evidence packs for fake lookalike sites

> Every hour, new brand abuse tickets get scanned, screenshotted, and turned into a ready to send abuse report before an analyst even opens them.

- Workflow type: agent
- Services: urlscan.io, Jira, Slack
- Categories: Operations, Engineering
- Published: 2026-08-10

## What it does

- Checks your brand protection project every hour for new takedown tickets and pulls the reported domain out of each one
- Safely visits the fake site from a remote sandbox, captures a screenshot and the page source, and records who is hosting it
- Looks for other scam pages running on the same server, so you can show the host a whole cluster instead of a single page
- Posts a full evidence dossier and a drafted abuse report back onto the ticket, plus a short heads up in your brand protection channel

## What you'll need

- A Jira Cloud account with a brand protection project where takedown requests get filed
- A urlscan.io account (the free plan is enough for this workflow)
- A Slack workspace with a channel for brand protection alerts
- An agreed status and label your team uses to mark new takedown requests, so the workflow knows which tickets to pick up

## Prompt

Every hour, build a complete takedown evidence pack for every new brand impersonation report sitting in our Jira brand protection project, so an analyst opens the ticket to a finished dossier instead of a blank investigation.

Start with Jira Search Issues (JQL) to find issues in our brand protection project that are still in the New status and carry the takedown label. For each issue that comes back, use Jira Get Issue to read the full ticket and pull out the reported domain or URL. Read the issue's existing comments at the same time and skip any ticket that already has an evidence dossier comment from a previous run, so an hourly schedule never scans the same domain twice. Cap the run at about ten tickets so we stay inside urlscan's free tier quotas.

For each reported domain, submit it with urlscan Submit URL Scan using unlisted visibility. Unlisted is the right default here: it keeps the scan out of urlscan's public search while still producing a link that vetted researchers and the hosting provider can open, and reported phishing URLs often carry victim specific parameters that should not be publicly indexed. Scanning is asynchronous and takes roughly ten to thirty seconds, so poll urlscan Get Scan Result until the finished result comes back rather than assuming it is ready immediately.

From the scan result, capture the hosting IP address, the ASN and the hosting provider or AS name, the page title, and the server details. Fetch urlscan Get Screenshot for a visual record and urlscan Get DOM Snapshot for the page source. Keep the scan permalink, because that is the citable evidence link the abuse report will point to.

Then pivot on the infrastructure: run urlscan Search Scans on that IP address to find other phishing pages sitting on the same host. Takedowns land much harder when you can show the provider a cluster of abusive pages rather than one isolated page, so collect the related domains along with their scan links and count them. Stick to Search Scans on the IP for this pivot. Do not use urlscan's structure or similar search, or file downloads by hash, because those are paid urlscan Pro features and this workflow needs to run on the free tier.

Degrade gracefully instead of failing the whole dossier. Get Screenshot and Get DOM Snapshot return a not found response when that asset was never stored for the scan, and Get Scan Result returns a gone response if the scan was deleted, so note the missing piece in the dossier and carry on with everything else. If the scan returns nothing useful because the site is already down, for example the submission is rejected because the domain no longer resolves or the rendered page comes back empty, flag that clearly and prominently at the top of the dossier so the analyst knows the page went offline before evidence could be captured rather than assuming the evidence is simply missing.

Compile everything into a structured evidence dossier with clear sections: the reported domain and ticket reference, the scan permalink as the citable evidence link, the hosting facts (IP address, ASN, hosting provider, country), the page facts (title, server details, whether a screenshot and page source were captured), and the related sites found on the same IP. Then draft a ready to send abuse report addressed to the hosting provider that quotes the specific evidence rather than speaking in generalities: name the impersonating domain, the IP it resolves to, the page title, what brand it is impersonating, the scan permalink, and the number and list of other abusive pages found on the same IP.

Post the dossier and the drafted abuse report back onto the ticket with Jira Add Comment, starting the comment with a consistent heading so later runs can recognize it and skip that ticket. Then send a short heads up to our brand protection channel with Slack Send a Message noting the impersonating domain, the hosting provider to contact, and how many related sites were found on the same IP, with a link back to the Jira issue. Keep the Slack message brief; the full detail lives on the ticket.

If no matching tickets are found in a given hour, do nothing and stay quiet.

## How to customize

- Change how often it runs, from every hour to a few times a day
- Point it at your own project, status, and label naming, or widen it to cover more than one brand protection queue
- Adjust the tone and recipient of the drafted abuse report, and route the heads up to a different channel or straight to an on call analyst

## FAQ

### Is it safe to visit these fake sites?

You never open them yourself. Each site is loaded in a remote sandbox, and all you see afterwards is the screenshot and the captured page details. Nothing runs on your own machine or network.

### What happens if the fake site is already offline?

The dossier says so clearly at the top rather than quietly failing. That way an analyst immediately knows the page went down before evidence could be captured, instead of assuming the evidence is just missing.

### Do I need a paid urlscan.io plan?

No. This workflow deliberately sticks to what is available on the free plan, including the search that finds other sites hosted on the same server. Paid plans add extra ways to find related pages, but nothing here depends on them.

### Will these scans be visible to the public?

Scans are submitted as unlisted, which keeps them out of public search results while still giving you a stable link you can cite in an abuse report. That matters because reported phishing links often contain victim specific details.

### Does it send the abuse report for me?

No. It drafts the report and attaches it to the ticket so a person reviews, adjusts, and sends it. The goal is that the analyst starts from a finished draft rather than a blank page.

### Why does it bother looking for other sites on the same server?

Hosting providers act faster when you can show a pattern of abuse rather than a single complaint. Finding a cluster of scam pages on one server turns a one page report into a much stronger case.

Use this prompt in General Input: https://www.generalinput.com/prompts/auto-build-takedown-evidence-packs-for-fake-lookalike-sites