DNSTwister Typosquatting & Phishing Detector

DNSTwister helps brand-protection teams, SOC analysts, registrars, and security researchers inventory registered lookalike domains. Give it an authorized registrable domain; it generates bounded typo, keyboard, homoglyph/IDN, combosquatting, subdomain, and TLD variants, checks DNS/MX registration, and returns ranked dataset rows with optional HTTP/TLS and page-similarity evidence.

Best fit and scope

Choose this Actor when the decision is which registered domain variants deserve human review first. It works well for periodic brand monitoring, a newly reported lookalike domain, defensive phishing triage, and a pre-takedown evidence pass. It is designed as a focused standalone workflow: the dataset is the handoff to an analyst, ticketing system, registrar process, or a separate website-health workflow.

The network layer makes bounded GET requests and reads certificate metadata. It never submits forms, logs in, follows private-address targets, or stores page bodies. The phishing flag is a heuristic triage signal; analysts should confirm ownership, content, redirects, certificate details, and applicable policy before taking action.

Candidate families are informed by the open-source dnstwist project, which documents typo, homograph, DNS, HTTP, MX, and certificate-oriented discovery techniques. This Actor is an independent Node.js implementation with explicit bounds and Apify dataset/PPE contracts; it does not bundle the Python project.

Workflow: from an authorized seed to a review queue

1. A brand owner supplies example.com and selects the breadth and probe caps.
2. The Actor generates and deduplicates variants, then resolves A, AAAA, MX, NS, and CNAME records.
3. Registered candidates are ranked using label similarity, variant family, DNS/MX evidence, optional page signals, and TLS state.
4. The overview, DNS, and phishing dataset views give the analyst a short queue with provenance and collection time.
5. The analyst confirms the evidence and passes selected rows into the organization’s incident, registrar, or monitoring workflow.

Quick start

The required input is one public registrable domain that you are authorized to monitor. A URL is accepted and reduced to its registrable domain.

{
  "domain": "example.com",
  "maxCandidates": 300,
  "maxResults": 100,
  "maxHttpProbes": 100,
  "fuzzers": ["omission", "insertion", "homoglyph", "combosquatting", "tld-swap"],
  "checkHttp": true,
  "checkTls": true,
  "concurrency": 20
}

Input	Meaning	Default
domain	Authorized registrable seed domain or URL	required
maxCandidates	Generated variants sent to DNS resolution, from 1 to 2,000	300
maxResults	Registered rows persisted and billed, from 1 to 500	100
maxHttpProbes	Registered candidates receiving network inspection; 0 gives DNS/MX-only output	100
fuzzers	Selected variant families; duplicates are removed	all families
checkHttp	Enable bounded GET page inspection	true
checkTls	Capture certificate metadata for selected network targets	true
concurrency	Parallel DNS/network work, from 1 to 50	20

For a fast inventory, start with maxCandidates: 100, maxHttpProbes: 25, and the typo-oriented families. For a broad defensive review, raise the candidate cap while keeping the network cap aligned with analyst capacity.

Data you receive

One dataset row represents one registered candidate. Unregistered variants are counted in RUN_SUMMARY and are not emitted or billed.

Field	Description
domain, unicodeDomain, url	ASCII candidate, optional Unicode rendering, and review URL
fuzzer, editDistance, similarityScore	Generation provenance and label similarity
dnsStatus, registered, aRecords, aaaaRecords, mxRecords, nsRecords, cnameRecords	Registration and DNS evidence
httpStatus, httpFinalUrl, httpResponded, redirectHosts	Bounded GET response and public redirect chain
pageTitle, brandMentioned, credentialFormDetected, loginKeywordDetected	Page-level triage signals
tlsAuthorized, tlsIssuer, tlsSubject, tlsValidFrom, tlsValidTo, tlsDaysUntilExpiry	Certificate metadata
htmlSimilarityScore	Visible-text similarity to the seed page when both pages are readable
phishingSignals, potentialPhishing, riskScore, riskLevel	Explainable heuristic triage output
checkedAt, warnings	Collection timestamp and row-specific caveats

Example persisted row:

{
  "seedDomain": "example.com",
  "domain": "examp1e-login.com",
  "unicodeDomain": null,
  "url": "https://examp1e-login.com/",
  "fuzzer": "combosquatting",
  "editDistance": 7,
  "similarityScore": 58,
  "dnsStatus": "registered",
  "registered": true,
  "aRecords": ["203.0.113.10"],
  "aaaaRecords": [],
  "mxRecords": ["10 mail.examp1e-login.com"],
  "nsRecords": ["ns1.example.net"],
  "cnameRecords": [],
  "hasMx": true,
  "httpStatus": 200,
  "httpFinalUrl": "https://examp1e-login.com/",
  "httpResponded": true,
  "httpError": null,
  "redirectHosts": [],
  "pageTitle": "Account verification",
  "brandMentioned": true,
  "credentialFormDetected": true,
  "loginKeywordDetected": true,
  "tlsAuthorized": true,
  "tlsAuthorizationError": null,
  "tlsIssuer": "Example Certificate Authority",
  "tlsSubject": "examp1e-login.com",
  "tlsValidFrom": "2026-08-01T00:00:00.000Z",
  "tlsValidTo": "2026-11-01T00:00:00.000Z",
  "tlsDaysUntilExpiry": 63,
  "htmlSimilarityScore": 78,
  "phishingSignals": ["registered-domain", "mail-exchange", "credential-form", "seed-brand-text", "similar-page", "potential-phishing"],
  "potentialPhishing": true,
  "riskScore": 91,
  "riskLevel": "critical",
  "checkedAt": "2026-08-30T00:00:00.000Z",
  "warnings": []
}

OUTPUT contains the terminal outcome and dataset pointer. RUN_SUMMARY contains candidate counts, effective bounds, warnings, validation diagnostics, and the billed event count. Terminal outcomes are COMPLETE, PARTIAL, VALID_EMPTY, INVALID_INPUT, UPSTREAM_FAILED, and CONFIG_ERROR, so an agent can distinguish a useful empty inventory from an interrupted run.

Pricing and platform usage

This Actor uses Pay per event: $0.04 for each fully validated registered-domain row persisted to the dataset, plus the Actor Start event. A run that persists 50 rows therefore has an Actor-level estimate of $2.00 plus the start event. DNS-only and unregistered candidates remain outside result-event billing. Apify platform usage is paid by the user and is separate from these PPE events; the live Pricing tab is the current source of truth for the Actor’s configured prices and usage presentation.

The maxResults setting is the result-event cost cap. The Actor reports its effective event count and expected PPE amount in RUN_SUMMARY, while Apify remains the billing source of truth.

AI-agent and MCP prompt card

Hosted Apify MCP can call the Actor as a bounded read-only investigation. A useful request is:

For the authorized domain example.com, generate up to 150 candidates, inspect up to 30 registered candidates, return the phishing dataset view, and summarize outcome, dataset readback, candidate provenance, collection time, cost, scope, pagination, warnings, and any rows needing human review.

Agents should pass the exact seed domain, keep candidate and network caps explicit, read OUTPUT and RUN_SUMMARY, then retrieve the dataset for row-level provenance. Treat potentialPhishing as triage, preserve fuzzer, DNS, HTTP/TLS, and timestamp fields, and request another bounded page or run when a result set is intentionally capped.

Scope and best results

• Keep the seed to a public registrable domain and written monitoring authorization.
• Use typo and homoglyph families for brand inventory; add combosquatting and TLD families when the review includes landing-page impersonation.
• Use maxHttpProbes as the analyst’s network-inspection budget. Rows outside that cap retain DNS evidence and clearly state the inspection scope.
• Treat DNS observations, certificate state, redirect destinations, and page text as time-sensitive evidence; rerun before a consequential decision.
• Compare results with the organization’s own domain inventory and incident records before contacting a registrar, host, or site owner.

Focused standalone workflow

This Actor is designed as a focused standalone workflow for a bounded domain-evidence handoff.

Builder's note

I designed this as a provider-free Actor because registration and first-pass phishing triage are strongest when the evidence stays close to DNS, public HTTP responses, and certificate metadata. The implementation keeps candidate generation local, validates the complete row before the coupled dataset/PPE write, and stores only bounded page signals rather than response bodies. That makes the output useful to both an analyst and an agent while keeping network scope visible.

API example

Replace YOUR_APIFY_TOKEN with an Apify token that has permission to run the Actor. The endpoint returns a run; use the returned run ID and dataset link for readback.

curl -X POST \
  'https://api.apify.com/v2/acts/khadinakbar~dnstwister-typosquatting-detector/runs?token=YOUR_APIFY_TOKEN' \
  -H 'Content-Type: application/json' \
  --data '{
    "domain": "example.com",
    "maxCandidates": 100,
    "maxResults": 25,
    "maxHttpProbes": 10,
    "checkHttp": true,
    "checkTls": true,
    "concurrency": 10
  }'

Responsible use

Run this Actor only against domains and public services you are authorized to monitor, and follow applicable law, site terms, registrar policies, and internal security procedures. The Actor performs discovery and evidence collection; human review remains the decision boundary for attribution, takedown, notification, or enforcement.