How Security Teams Enrich Alerts with DNS, WHOIS, and IP Data in 2026

Why Raw Alerts Waste SOC Time

A SIEM fires an alert: suspicious outbound connection to 198.51.100.42 on port 443. The event contains an IP, a timestamp, and a process name. The analyst staring at this alert needs to answer three questions before they can decide what to do: who owns the destination, where is it geographically, and is the infrastructure legitimate or known-bad?

Without enrichment, the analyst tabs out to WHOIS lookup tools, runs manual DNS queries, copies the IP into a geolocation service, and pieces together context over several minutes. Multiply that by hundreds of alerts per shift, and the backlog compounds fast. Enrichment automates these lookups so the alert arrives pre-loaded with ownership, location, and infrastructure context.

What Alert Enrichment Actually Looks Like

Enrichment means querying external data sources at the moment an alert fires and appending the results to the alert record. The three most useful data types for infrastructure-related alerts are:

Enrichment Decision Matrix

Not every alert benefits from every enrichment type. Use this matrix to decide which API calls to make based on the alert category. The goal is to minimize unnecessary API calls while maximizing actionable context.

Building the Enrichment Workflow

The pattern is straightforward: a webhook or polling script receives new alerts from the SIEM, extracts the relevant indicators (IP addresses and domains), calls the enrichment APIs, and writes the results back. Here is a practical implementation using TypeScript that works with any SIEM that supports webhooks.

// enrichment-pipeline.ts
// Enriches security alerts with DNS, WHOIS, and IP data

interface SecurityAlert {
  id: string;
  type: 'outbound_connection' | 'phishing' | 'brute_force' | 'c2_comm' | 'dns_tunnel';
  indicator: string; // IP or domain
  timestamp: string;
}

interface EnrichedAlert extends SecurityAlert {
  enrichment: {
    dns?: { records: Record<string, string[]>; resolvedAt: string };
    whois?: { registrar: string; createdDate: string; expiresDate: string; registrantOrg?: string };
    ipGeo?: { country: string; city: string; isp: string; asn: string; isVpn: boolean };
    reverseIp?: { domains: string[]; totalCount: number };
  };
}

const API_KEY = process.env.OPS_TOOLS_API_KEY;
const BASE_URL = 'https://api.ops.tools/v1';

async function enrichAlert(alert: SecurityAlert): Promise<EnrichedAlert> {
  const enriched: EnrichedAlert = { ...alert, enrichment: {} };
  const isIp = /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/.test(alert.indicator);

  // Parallel API calls for speed
  const results = await Promise.allSettled([
    isIp
      ? fetchIpGeolocation(alert.indicator)
      : fetchDnsRecords(alert.indicator),
    fetchWhoisData(alert.indicator),
    isIp ? fetchReverseIp(alert.indicator) : Promise.resolve(null),
  ]);

  if (results[0].status === 'fulfilled' && results[0].value) {
    enriched.enrichment = isIp
      ? { ...enriched.enrichment, ipGeo: results[0].value }
      : { ...enriched.enrichment, dns: results[0].value };
  }
  if (results[1].status === 'fulfilled' && results[1].value) {
    enriched.enrichment.whois = results[1].value;
  }
  if (results[2].status === 'fulfilled' && results[2].value) {
    enriched.enrichment.reverseIp = results[2].value;
  }

  return enriched;
}

The Three API Calls

// DNS record lookup
async function fetchDnsRecords(domain: string) {
  const res = await fetch(
    `${BASE_URL}/dns/lookup?domain=${domain}&recordType=A,MX,TXT,NS`,
    { headers: { 'Authorization': `Bearer ${API_KEY}` } }
  );
  const data = await res.json();
  return {
    records: data.records,
    resolvedAt: new Date().toISOString(),
  };
}

// WHOIS registration data
async function fetchWhoisData(domain: string) {
  const res = await fetch(
    `${BASE_URL}/whois/${domain}`,
    { headers: { 'Authorization': `Bearer ${API_KEY}` } }
  );
  const data = await res.json();
  return {
    registrar: data.registrar,
    createdDate: data.creationDate,
    expiresDate: data.expirationDate,
    registrantOrg: data.registrant?.organization,
  };
}

// IP geolocation with ISP and VPN detection
async function fetchIpGeolocation(ip: string) {
  const res = await fetch(
    `${BASE_URL}/ip/geolocation?ip=${ip}`,
    { headers: { 'Authorization': `Bearer ${API_KEY}` } }
  );
  const data = await res.json();
  return {
    country: data.country,
    city: data.city,
    isp: data.isp,
    asn: data.asn,
    isVpn: data.isVpn ?? false,
  };
}

Quick Reference: cURL Enrichment Calls

# DNS records for a suspicious domain
curl -s "https://api.ops.tools/v1/dns/lookup?domain=suspicious-example.com&recordType=A,MX,TXT,NS" \
  -H "Authorization: Bearer YOUR_API_KEY"

# WHOIS registration data
curl -s "https://api.ops.tools/v1/whois/suspicious-example.com" \
  -H "Authorization: Bearer YOUR_API_KEY"

# IP geolocation with ISP and VPN data
curl -s "https://api.ops.tools/v1/ip/geolocation?ip=198.51.100.42" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Reverse IP lookup to find co-hosted domains
curl -s "https://api.ops.tools/v1/ip/reverse?ip=198.51.100.42" \
  -H "Authorization: Bearer YOUR_API_KEY"

Wiring It Into Your SIEM

The enrichment pipeline sits between your SIEM and the infrastructure APIs. Here is how it connects to three common platforms.

Splunk: HTTP Event Collector + Lookup

In Splunk, configure a scripted input or a modular alert action that triggers on new high-severity events. The script calls the enrichment pipeline and writes results to a KV store lookup. Analysts then use enrichment_lookup as a subsearch to append DNS, WHOIS, and geolocation context directly to their investigation dashboard.

Microsoft Sentinel: Playbook with HTTP Action

Create a Sentinel playbook triggered by the Microsoft Defender for Endpoint alert schema. Add an HTTP action step that calls your enrichment API endpoint with the alert's indicator extracted from entities[0].IpAddress or entities[0].Url. The playbook updates the incident with enrichment data before analysts see it in the queue.

Elastic Security: Ingest Pipeline + Enrich Processor

Elastic Security supports HTTP-based enrichment processors in ingest pipelines. Configure a pipeline that calls the API for each incoming event with an IP or domain field, then maps the response fields (country, isp, registrar, createdDate) into the event document. Enriched fields appear automatically in detection rule queries and the alerts UI.

Turning Enrichment Into a Risk Score

Raw enrichment data still requires analyst judgment. But you can build a lightweight scoring model that flags high-risk combinations automatically. Here is a scoring framework based on the enrichment data.

Alerts scoring above 40 get routed to Tier 1 analysts immediately. Below 40, they queue for batch review. This is not a replacement for analyst judgment, but it reduces triage time by eliminating obvious false positives before a human looks at the alert.

Handling Alert Surges at Scale

During incident response or a mass phishing campaign, alert volume can spike from dozens per hour to hundreds. The enrichment pipeline needs to handle this without hitting rate limits or timing out the SIEM webhook. Two practical strategies:

Setting Up Automated Alert Workflows

Beyond SIEM integration, infrastructure APIs work well in standalone alerting workflows. Use webhook notifications to trigger automated responses when WHOIS or DNS data changes on monitored domains. For example, configure monitoring on your organization's domains: if the registrant changes, if the name servers shift to a different provider, or if a new subdomain appears, the webhook fires and your security team receives a notification before the change shows up in periodic audits.

Frequently Asked Questions