Introduction
"Your account has been suspended." "Please update your payment information." — Phishing SMS and emails like these have become a daily occurrence in Japan.
As a security engineer, I used to manually report every phishing site I came across, but the workload per report was simply too much to keep up with:
- Look up the domain's IP address
- Identify the hosting provider via WHOIS
- Find the abuse contact email address
- Write a report email in English
- Take a screenshot and attach it
- Send it, then check whether the site was taken down
15 to 30 minutes per report. Doing this for multiple sites every day just isn't realistic.
So I built a system on AWS that automates all of the above with a single URL submission. In this article, I'll share the architecture and the lessons learned during development.
System Overview
curl -X POST https://xxx.execute-api.us-east-1.amazonaws.com/prod/report-auto \
-d '{"url": "https://phishing-site.example.com"}'
This single curl command triggers the following automated workflow:
- Capturing a screenshot of the site
- Using Bedrock (Claude) to analyze the page and infer the impersonated brand
- Looking up technical information such as hosting provider and abuse contact
- Drafting and sending a report email with supporting evidence
- Submitting reports to services such as Google Safe Browsing and Netcraft
- Monitoring DNS changes afterward to help confirm whether the site has been taken down
To reduce false reports, the system stores reporting history, keeps a registry of known legitimate sites, and relies on multiple pieces of evidence before proceeding.
Architecture Diagram
AWS Services Used
| Service | Purpose |
|---|---|
| API Gateway (HTTP API) | REST endpoints (4 routes) |
| Lambda (Zip x3) | Report processing, reply handling, takedown monitoring |
| Lambda (Container x1) | Playwright screenshots + form auto-submission |
| DynamoDB | Abuse contact cache, report history, legitimate site registry |
| S3 | Screenshot storage |
| ECR | Container image for Screenshot Lambda |
| Bedrock (Claude) | Email generation, screenshot analysis, brand detection |
| EventBridge | Daily takedown monitoring schedule |
| Route 53 | Email domain DNS (SPF/DKIM/DMARC) |
All infrastructure is managed with Terraform — a single terraform apply deploys everything.
Interesting Technical Challenges
1. Collecting Usable Screenshots from Phishing Sites
Screenshots are important evidence in abuse reports. In practice, however, phishing sites often make automated access difficult, and a straightforward screenshot attempt may fail.
To improve reliability, the system uses multiple approaches to collect screenshots, including third-party services such as urlscan.io when appropriate.
In addition to helping with screenshot collection, third-party scan results can also serve as supporting evidence when reporting a site.
2. Three Uses of Bedrock (Claude)
This system leverages Claude in three different contexts:
a) Screenshot Quality Assessment
Determines whether the captured screenshot shows actual phishing content, rather than a bot detection page, 404 error, or blank page.
b) Automatic Brand Detection (/report-auto)
The URL-only endpoint uses screenshots and HTML to determine which brand the phishing site is impersonating.
c) Report Email Generation
Based on technical information such as redirect chains, page HTML, and screenshots, Claude automatically generates professional emails for hosting provider abuse teams. It captures technical details that templates can't convey.
3. A Multi-Layered Reporting Strategy
Reporting a phishing site to only one destination is often not enough.
That is why the system can notify multiple relevant parties for a single phishing site:
Hosting provider abuse contacts
Domain registrar abuse contacts
Google Safe Browsing
Netcraft
These channels serve different purposes.
For example, hosting providers may take action against the server itself, while registrars may suspend the domain. Browser warning services can also help protect users by displaying alerts even if the site remains online for some time.
This layered approach improves the chance of reducing harm, even when one reporting path does not immediately lead to action.
Cost
Because the system is built on serverless services, the monthly cost has been relatively low in my current usage:
- Lambda: Pay-per-use
- DynamoDB: On-demand capacity
- S3: Screenshot storage
- Bedrock (Claude): the main variable cost
- Resend: Email sending
- urlscan.io: public scans within the free tier
In my current setup and usage volume, the total cost has been roughly $5–10 per month, though this can vary depending on report volume and model usage.
Future Plans
- A reporting analytics dashboard to visualize response times by hosting provider and impersonated brand trends
- Sharing successfully taken-down phishing URLs with services such as PhishTank
- Expanding support for additional browser warning services such as Microsoft SmartScreen
Conclusion
Reporting phishing sites is repetitive and time-consuming work, especially when handled one case at a time.
By combining AWS serverless services with Bedrock (Claude), I built a system that streamlines much of that process — from screenshot collection to reporting and follow-up monitoring — from a single URL submission.
There is still plenty of room to improve how we respond to phishing at scale, but even small automation can make this work more sustainable. I hope this article provides a useful reference for others working on similar problems.
Top comments (0)