XSOAR Playbook: Enrich Suspicious Domains with WHOIS + DNS + Subdomains Before Blocking

TL;DR: When XSOAR receives a suspicious domain indicator, three API calls to WhoisFreaks (one for WHOIS registration data, one for live DNS records, one for the active subdomain list) give you enough context to score the domain before any block action fires. This playbook walks through configuring each task, the curl equivalent for each call, a scoring model with defined thresholds, and the condition logic that routes to auto-block or analyst review.

Why Blocking Without Enrichment Creates Risk

When a SIEM alert or threat intelligence platform surfaces a suspicious domain, the instinct is to block it immediately. That instinct is right about the direction but often wrong about the scope and the confidence level.

Three specific problems appear when blocking fires without prior enrichment.

The first is false positives tied to shared infrastructure. A domain that looks malicious may resolve to a shared IP that also hosts legitimate services. Blocking at the domain level without reviewing the A records and nameserver identity can take down co-hosted properties or trigger unnecessary firewall noise that buries the real threat.

The second is incomplete blocking because the subdomain surface is unknown. Blocking malicious.com without knowing that c2.malicious.com, payload.malicious.com, and panel.malicious.com are all active leaves the operational infrastructure running. The original alert gets closed. The campaign does not.

The third is the absence of a documented decision trail. When a business unit challenges a block, or when a post-incident review asks why a domain was blocked two minutes after the alert arrived, the analyst needs to show what was known at the time. Registration age, registrar identity, nameserver configuration, and subdomain count are the core of that justification. Without them, the block is a judgment call with no paper behind it.

What Each Enrichment Layer Provides

WHOIS: Registration identity and domain age

WHOIS records contain the metadata that describes a domain's legal and operational existence: who registered it, through which registrar, when it was created, when it expires, and what nameservers are authorized to answer for it. For threat triage, the fields with the most practical weight are create_date, domain_registrar.registrar_name, registrant_contact, domain_status, and name_servers.

Domain age is the single clearest signal. A domain registered eight days ago appearing in a phishing alert has no plausible legitimate explanation. A domain registered three years ago at a known enterprise registrar requires a different level of scrutiny. Historical WHOIS adds a second layer: ownership transfers, registrar changes, and repeated re-registrations are patterns that passive DNS alone won't show.

DNS records: Infrastructure fingerprint

DNS records reveal where the domain resolves and how its mail and naming infrastructure is configured. The A record gives you the resolved IP. The NS records identify the nameserver operator, which frequently carries more threat signal than the domain itself. The MX record tells you whether the domain is set up for email delivery, which matters for phishing infrastructure classification. The TXT and SPF records indicate whether the domain has any anti-spoofing posture configured, an absence that is consistent with purpose-built phishing domains. A CNAME pointing to a decommissioned external service indicates subdomain takeover exposure.

Subdomains: Active attack surface map

The subdomain list is the part most playbooks skip entirely. A domain flagged in a single alert may have dozens of active subdomains each serving a distinct function in the attack chain: login., api., cdn., c2., panel., bot.. The first_seen and last_seen timestamps tell you when subdomains appeared and whether they are currently active. When 15 subdomains were all first seen on the same date, the infrastructure was provisioned in a single automated event, not built up organically over time. That is a campaign signal, not a coincidence.

Configuring the WhoisFreaks HTTP Request Integration in XSOAR

Setting up the integration instance

XSOAR ships with a built-in HTTP integration that sends arbitrary GET and POST requests to external APIs. No custom content pack is required to call WhoisFreaks. Navigate to Settings > Integrations > HTTP Feed > Add Instance. Name the instance WhoisFreaks. All three API calls in this playbook share the same base domain: https://api.whoisfreaks.com.

If your instance runs behind a proxy, configure it under the integration instance settings before testing any task.

Authentication and base URL configuration

The WhoisFreaks WHOIS API authenticates via an apiKey query parameter appended to every request. There is no OAuth flow or token exchange. Store the API key as an XSOAR credential under Settings > Credentials, set the type to "Password," and name it WhoisFreaksAPIKey. Reference it in each HTTP task URL as ${inputs.WhoisFreaksAPIKey} rather than hardcoding the value. Set the suspicious domain as a playbook input named SuspiciousDomain so all three tasks pull from the same variable.

The WhoisFreaks live WHOIS API returns responses within 1 to 2 seconds under standard load. Running all three tasks in parallel (covered in the FAQ below) brings total enrichment time to roughly that same window.

Playbook Step 1: Query Live WHOIS Data

Task configuration

Add an Automatic task to the playbook canvas. Select the HTTP integration instance you created above. Set the request method to GET. Set the full URL to:

https://api.whoisfreaks.com/v2.0/whois/live?apiKey=${inputs.WhoisFreaksAPIKey}&domainName=${inputs.SuspiciousDomain}&format=json

Set the response context path to WhoisFreaks.WHOIS. XSOAR parses the JSON response and stores the complete object there. Downstream tasks reference individual fields as ${WhoisFreaks.WHOIS.create_date}, ${WhoisFreaks.WHOIS.domain_registrar.registrar_name}, and so on.

The curl equivalent

To inspect the response structure before building the playbook task, run:

curl "https://api.whoisfreaks.com/v2.0/whois/live?apiKey=YOUR_KEY&domainName=suspicious.com&format=json"

The response of this includes create_date, update_date, expiry_date, domain_registered, domain_registrar, registrant_contact, domain_status, and name_servers.

Not every WHOIS field carries triage weight. The ones that feed the risk scoring model are:

Playbook Step 2: Query DNS Records

Task configuration and record types

Add a second automatic task. Use the same HTTP integration instance. Set the URL to:

https://api.whoisfreaks.com/v2.0/dns/live?apiKey=${inputs.WhoisFreaksAPIKey}&domainName=${inputs.SuspiciousDomain}&type=all&format=json

Set the response context path to WhoisFreaks.DNS. The type=all parameter retrieves all eight record types in a single request: A, AAAA, MX, NS, SPF, SOA, TXT, and CNAME. The dnsRecords array in the response contains one object per record with dnsType, address (for A records), target (for NS and CNAME records), strings (for TXT and SPF records) and ttl.

The curl equivalent

curl "https://api.whoisfreaks.com/v2.0/dns/live?apiKey=YOUR_KEY&domainName=suspicious.com&type=all&format=json"

You can also query individual record types by replacing type=all with a specific type, for example type=ns to retrieve nameserver records only.

Indicators of fast-flux and bulletproof hosting

Three patterns in the DNS response warrant an automatic escalation to high risk regardless of domain age.

Fast-flux indicators appear as multiple A records each with a TTL below 300 seconds. Fast-flux botnets cycle IP addresses rapidly to keep infrastructure accessible after individual IPs get blocked. If the dnsRecords array returns more than five A records all with TTL under 300, treat the domain as fast-flux until proven otherwise.

Bulletproof nameserver matches require a comparison list. NS records pointing to nameserver operators known for hosting criminal infrastructure should trigger an immediate score spike. Store a Custom Indicator Type in XSOAR for "Bulletproof Nameserver" and populate it with known malicious NS domains. The condition task compares each NS record's target field against this indicator type.

Missing SPF with an active MX record is the phishing infrastructure pattern. Check whether the dnsRecords array contains any entry with dnsType: SPF. If SPF is absent and an MX record is present, the domain is configured to send email with no anti-spoofing posture. Add this as a scoring signal, not a standalone block trigger, since legitimate new domains sometimes ship without SPF configured.

Playbook Step 3: Query Subdomains

Task configuration

Add a third automatic task. Set the URL to:

https://api.whoisfreaks.com/v2.0/subdomains?apiKey=${inputs.WhoisFreaksAPIKey}&domainName=${inputs.SuspiciousDomain}&status=active&format=json

Set the response context path to WhoisFreaks.Subdomains. The Subdomain Lookup API draws from a database of over 5.2 billion hostnames built from DNS crawls, certificate transparency logs, and passive DNS collection. The status=active parameter filters to currently resolving subdomains. Remove the filter to include inactive records if your workflow needs full historical coverage of the domain's past subdomain footprint.

The curl equivalent

curl "https://api.whoisfreaks.com/v2.0/subdomains?apiKey=YOUR_KEY&domainName=suspicious.com&status=active&format=json"

The response object includes total_records at the top level and a subdomains array. Each entry in the array carries the subdomain hostname, first_seen, last_seen, and an inactive_from timestamp when applicable.

Interpreting first_seen, last_seen, and naming patterns

A high subdomain count on a recently registered domain is one of the clearest operational signals in the enrichment dataset. Legitimate domains registered 10 days ago rarely have 35 active subdomains. When total_records exceeds 20 and ${WhoisFreaks.WHOIS.create_date} places the domain under 30 days old, the combination points to automated infrastructure provisioning. Treat it as high risk regardless of what other signals say.

first_seen clustering exposes campaign timing. Fifteen subdomains that all appear in the first_seen field with the same date were created in a single provisioning event, not through organic growth. This pattern recurs consistently across phishing kits and C2 infrastructure deployments.

Subdomain naming carries functional intent. Names like c2, panel, bot, cdn, payload, api, and login appear in threat actor infrastructure at a frequency that makes them worth checking explicitly. Use a Set Variable task before the condition block to iterate the subdomain list and flag any name-match against this keyword set. Store the result as a boolean context key SubdomainThreatPattern.

Building the Risk Scoring Logic

After all three enrichment tasks complete, a Set Variable task aggregates the signals into a single risk score. The table below maps each signal to a score increment and the condition logic routes on the total.

Domain age as the primary signal

Domain age carries the highest weight because it is reliable, cheap to retrieve, and hard to fake without a credible domain history. A domain created 8 days ago has no history, no reputation, and no business reason to appear in an alert queue. In the Set Variable task, compute the age by running XSOAR's built-in TimeStampToDate transformer against ${WhoisFreaks.WHOIS.create_date} and comparing it against the incident creation timestamp.

Nameserver and registrar reputation

The NS check requires a maintained comparison list. Store a Custom Indicator Type in XSOAR named "Bulletproof Nameserver" and populate it through your threat intelligence process. The condition task compares each value from ${WhoisFreaks.DNS.dnsRecords} where dnsType equals NS against this indicator type. A match adds 25 to the score and should also set a dedicated context key for visibility in the War Room output.

Subdomain count and naming flags

Use a ForEach loop task over ${WhoisFreaks.Subdomains.subdomains}. Inside the loop, check each subdomain hostname against the threat keyword list (c2, panel, bot, payload, cdn, login, api). If any match is found, set SubdomainThreatPattern = true in context. The scoring task treats this flag as a binary modifier rather than a numeric increment, since a single matching subdomain name is already a significant indicator regardless of overall count.

Condition task branching

The condition task after the scoring block has three branches:

Score 65 or above routes to the automatic blocking task. No analyst input is required at this threshold. The domain score is too clear to hold for review.

Score 35 to 64 routes to a manual task. The analyst sees the enrichment summary, the score breakdown, and two action options: "Confirm Block" or "Close Without Action". Their choice is logged with username and timestamp.

Score under 35 routes to a Work Note task that records the enrichment data and closes the playbook without action. The note remains on the incident if additional correlated alerts arrive later.

The Blocking Task and Analyst Handoff

Passing enriched context to the block integration

The blocking task in this playbook is intentionally integration-agnostic. It calls a sub-playbook named "Block Domain - Generic," which checks which blocking integrations are active in your XSOAR instance (firewall, DNS sinkhole, proxy, or web filter) and routes accordingly. This keeps the enrichment playbook decoupled from your specific blocking stack.

Pass the following context keys to the sub-playbook: SuspiciousDomain, WhoisFreaks.WHOIS, WhoisFreaks.DNS, WhoisFreaks.Subdomains, and RiskScore. Including the full enrichment context in the sub-playbook call means the analyst can see the complete decision basis from inside the incident view without navigating to the parent playbook.

Mandatory annotation before execution

Insert a Work Note task immediately before the blocking sub-playbook call. Set it to Automatic. The note should record the domain name, the computed risk score, the three highest-weight scoring signals, the WhoisFreaks.WHOIS.create_date value, the nameserver check result, and the subdomain count. This note is part of the incident audit trail. For environments with a change management integration (ServiceNow, Jira Service Management), pass the same content to a ticket creation task at this point. The ticket documents the block decision before the block executes.

War Room Output

When the playbook completes, the analyst sees a structured incident record in the XSOAR War Room.

The WHOIS task posts a table with registration date, registrar name, domain status codes, and nameserver list. The DNS task posts the full record set grouped by type with TTL values visible. The subdomain task posts the active subdomain list with first_seen and last_seen dates alongside the total record count. The scoring task posts a breakdown showing which signals contributed and what value each added.

For analyst-review cases (score 35 to 64), the manual task presents all three enrichment tables with a single binary action. The analyst's decision and username are logged on the incident.

For auto-block cases, the Work Note appears in the War Room before the blocking sub-playbook output, giving any analyst who reviews the incident a complete picture of what was blocked and why.