Phishing-Tracker

A locally hosted, MCP-powered threat-intelligence workflow for turning phishing reports into reusable detection logic, scored infrastructure leads, IOC exports, analyst reports, and human-gated takedown packs.

Phishing infrastructure moves quickly. Domains appear, get reported, disappear, and reappear under new names. A static IOC list is useful, but it ages fast.

phishing-tracker is built around a different idea: the most valuable output is not only the domain list. It is the detection logic that finds the next wave.

That means preserving the kit wording, URL patterns, page titles, worker patterns, IP pivots, ASN clusters, screenshot evidence, false-positive notes, and analyst actions that explain why something looks like phishing infrastructure in the first place.

What It Does

phishing-tracker takes a source report, blog post, advisory, or local write-up and turns it into an analyst-ready threat-intelligence package.

At a high level it:

• Reads a source report about a phishing kit, AiTM campaign, PhaaS platform, or suspicious infrastructure.
• Extracts useful markers such as domains, IPs, kit wording, page titles, URL paths, JavaScript filenames, worker patterns, and lure brands.
• Generates passive OSINT queries for URLScan, search engines, certificate transparency logs, Wayback, and IP pivots.
• Scores discovered URLs and domains against the extracted markers.
• Pulls screenshots from URLScan and analyses them with a locally hosted vision model.
• Clusters related infrastructure by IP, ASN, server headers, worker patterns, and repeat scans.
• Exports IOCs, candidate lists, a long-term RAG entry, and a self-contained analyst report.
• Drafts takedown notifications, but never sends them automatically.

The workflow is passive by design. It does not submit forms, enter credentials, brute force paths, bypass bot protection, or authenticate to target services.

Why MCP Matters

The tool is exposed as an MCP server, so the analyst assistant can call structured functions instead of scraping shell output or manually stitching together scripts.

The MCP exposes tools such as:

• run_pipeline to start a campaign.
• poll_pipeline to monitor progress.
• get_markers to inspect extracted kit markers.
• list_candidates and get_candidate to review scored infrastructure.
• get_iocs to export domains, IPs, URLs, and kit indicators.
• get_rag_entry to retrieve durable detection logic.
• run_ip_pivot, run_urlscan_query, and run_searxng_query for interactive investigation.
• resolve_contacts and notification tools for human-reviewed abuse reporting.

This makes the LLM useful as an operator interface rather than a black box. The model can reason over the campaign, but the actions are constrained to typed, auditable tools.

Locally Hosted LLMs

The interesting part is that the intelligence work does not need to leave the local environment.

phishing-tracker uses locally hosted OpenAI-compatible LLM endpoints for two jobs:

• Text extraction: finding kit markers and infrastructure clues in source reporting.
• Vision analysis: describing URLScan screenshots and feeding that evidence back into candidate scoring.

This means report text, campaign context, screenshots, and analyst notes can stay inside the local network. For threat intelligence, that matters. Some investigations involve sensitive client names, unpublished indicators, pending takedowns, or infrastructure that should not be disclosed before review.

Local models are not treated as perfect. Their output is parsed defensively, scored against evidence, and put behind analyst review. The LLM accelerates the work, but it does not get final authority.

Pipeline Flow

Source report
    -> marker extraction
    -> query generation
    -> passive OSINT pivots
    -> candidate scoring
    -> screenshot collection
    -> local vision analysis
    -> infrastructure clustering
    -> IOC exports, RAG entry, report, notifications

The current pipeline runs through these stages:

Detection Logic, Not Just IOCs

The most useful output is the rag_entry.json file.

It stores the pieces that remain useful after today's phishing domains go dead:

• URLScan queries.
• Search queries.
• Certificate transparency pivots.
• Wayback pivots.
• IP pivot lists.
• Kit wording.
• Page titles.
• URL and path patterns.
• Worker and subdomain patterns.
• Infrastructure signatures.
• Cluster summaries.
• False-positive indicators.
• Recommended analyst actions.

That becomes reusable intelligence. When the operator rotates to new domains, the old IOC list may be stale, but the saved query logic can still find the next deployment.

What The MCP Is Producing

The current local MCP state contains 12 campaign runs, of of July 2026.

Across those runs, the pipeline has produced:

Two recent examples show the scale:

Those numbers are not presented as automatic truth. A confirmed tier means confirmed by scoring logic, not that a human has legally or operationally attributed the infrastructure. Every high-impact action still goes through analyst review.

Human Gate For Takedowns

The notification workflow is intentionally conservative.

The system can resolve contacts, build an evidence pack, and draft a notification. It can identify possible recipients from security.txt, RDAP, hosting abuse contacts, CDN providers, brand-abuse contacts, and national reporting channels.

It does not send the notification.

Notifications sit in a review queue until a human approves, edits, rejects, exports, or manually marks them as sent. This is important because phishing infrastructure tracking has false positives. A news article about a kit, a legitimate storefront with a name collision, or an old shared-hosting IP can look suspicious to an automated system.

The human gate is not a formality. It is part of the design.

Why This Is Useful For Threat Intel

Traditional phishing tracking often stops at indicators:

domain, IP, URL, hash, date seen

phishing-tracker tries to preserve the analyst reasoning around those indicators:

why this marker matters
where it was observed
what queries found related infrastructure
which screenshots support it
which clusters it belongs to
what would make it a false positive
what action an analyst should take next

That makes it useful for:

• Building internal watchlists.
• Monitoring URLScan for new kit deployments.
• Pivoting from one reported campaign into related infrastructure.
• Producing client-ready threat-intelligence summaries.
• Preserving investigation logic for future RAG-assisted analysis.
• Drafting takedown packs with evidence attached.
• Demonstrating what sovereign, locally hosted AI can do in a real security workflow.

What Local AI Adds

The local LLM does not replace the analyst. It removes repetitive work.

It can read a long report and extract markers in seconds. It can generate multiple OSINT pivots. It can describe screenshots consistently. It can compare candidate evidence against known kit wording. It can summarise an investigation into reusable detection logic.

The analyst still decides what is real, what is noise, what should be escalated, and what should be reported.

That is the practical value of local AI in threat intelligence: fast enough to scale the boring parts, private enough for sensitive work, and constrained enough to keep the human in control.

The Short Version

phishing-tracker is a local threat-intelligence pipeline for phishing infrastructure.

It turns public reporting and analyst notes into structured markers, passive pivots, scored candidates, screenshots, clusters, IOC exports, RAG entries, reports, and human-reviewed takedown drafts.

The point is not to create another disposable IOC feed. The point is to capture the detection logic that survives domain rotation.

That is where locally hosted LLMs become useful: not as magic attribution engines, but as private, fast, evidence-aware assistants inside a constrained analyst workflow.