How Defenders Actually Use Shadowserver's Data Feeds

Shadowserver's name comes up constantly in threat intelligence conversations, but coverage almost always stops at what the organization is rather than what practitioners do with it. The data it produces is genuinely different from commercial threat feeds — not because it is more comprehensive, but because it is structurally unique: passively collected from a global sensor network, enriched with sinkhole telemetry, and delivered at no cost to any network owner who asks. This article covers what that data actually looks like, how defenders ingest it, and where it has proved operationally decisive.

Every day, Shadowserver's infrastructure performs 42 complete scans of the entire IPv4 internet, processes data from one of the largest distributed sinkhole networks ever operated, and delivers over 90 distinct report types to network owners, CERTs, and national security agencies across the globe. As of end-2024, the organization had grown to more than 9,000 subscribing organizations, including 201 National CSIRTs covering 175 countries and territories — up from 132 National CSIRTs as recently as 2021 — covering everything from open DNS resolvers sitting on a university network to industrial control system interfaces exposed directly to the internet. The organization also marked its 20th anniversary in 2024, a milestone that coincides with its largest operational footprint yet.

None of that is secret. What rarely gets explained is the mechanics: how a SOC analyst actually receives and acts on this data, what the field structure of a Shadowserver CSV looks like, what a sinkhole beacon tells you that a firewall log cannot, and where defenders have operationally validated this intelligence against real intrusions.

The Report Architecture: What Shadowserver Actually Sends You

Shadowserver operates a free reporting service that any network owner can subscribe to at shadowserver.org. Registration requires verifying ownership of an ASN, IP prefix, or domain. Once verified, daily reports arrive via email as compressed CSV attachments, or they can be pulled programmatically through the Shadowserver API.

What Registration Actually Involves

The registration page asks you to provide an email address, the ASN or IP prefix you are claiming ownership of, and the name of your organization. Shadowserver then sends a verification email to the WHOIS-listed abuse or technical contact for that network. If your organization's WHOIS records are accurate and current, the process takes under an hour. If they are not — a common situation for organizations that inherited address space, changed domain registrars, or have outdated abuse contacts — it can stall indefinitely.

Two scenarios trip up practitioners more than any other. First, organizations on colocation or shared hosting environments often do not own the ASN their IPs appear under. In those cases, Shadowserver reports flow to the colocation provider, not the tenant. You will not receive findings about your own servers unless your hosting provider has subscribed and passes relevant findings downstream — which many do not. The correct path for colo tenants is to contact Shadowserver directly to discuss a prefix-level arrangement. Second, organizations operating cloud infrastructure on AWS, Azure, or GCP address space face a structurally different problem, covered in the limitations section below.

The reports are categorized into several families. Understanding those families is the first step to using them effectively:

Report Family	What It Contains	Typical Source
Vulnerable Services	Exposed services with known CVEs, outdated versions, or dangerous default configs	Active scanning (IPv4 + IPv6)
Compromised Devices	IPs observed beaconing to sinkholes or C2 infrastructure	Sinkhole telemetry, passive DNS
Open Resolvers / Amplifiers	DNS, NTP, SSDP, memcached, and other services that can be weaponized for DDoS amplification	Active scanning
ICS / SCADA Exposure	Modbus, BACnet, Siemens S7, DNP3, and other OT protocols reachable over the public internet	Active scanning on protocol-specific ports
Honeypot Events	Attack telemetry logged by Shadowserver's global honeypot network	Passive honeypot infrastructure
Spam / Phishing Infrastructure	IPs and domains observed in active spam campaigns or linked to phishing kits	Spam traps, passive DNS, partner feeds

Each CSV row represents a single observed event tied to a specific IP address. The core fields present across nearly all report types are timestamp, ip, port, protocol, asn, as_name, geo, region, city, and naics (industry sector code). Vulnerability-specific reports append fields like version, tag (the CVE or misconfiguration label), and severity.

The API: Automating Feed Ingestion

Shadowserver's publicly documented API (api.shadowserver.org) accepts HMAC-SHA256-authenticated POST requests. The API covers three primary functions: querying reports for a given date and network scope, fetching summary statistics across report types, and querying the Shadowserver IP reputation database in real time.

A minimal Python ingestion loop looks something like this:

import hmac, hashlib, json, requests, time

API_KEY  = "your_api_key"
SECRET   = "your_secret"
BASE_URL = "https://api.shadowserver.org/net/reports"

def sign_request(payload: dict) -> str:
    body = json.dumps(payload, separators=(",", ":"))
    return hmac.new(SECRET.encode(), body.encode(), hashlib.sha256).hexdigest()

def fetch_report(report_type: str, date: str, cidr: str) -> list:
    payload = {
        "apikey": API_KEY,
        "report": report_type,
        "date":   date,
        "query":  cidr,
    }
    payload["hmac"] = sign_request(payload)
    r = requests.post(BASE_URL, json=payload, timeout=30)
    r.raise_for_status()
    return r.json()

# Example: pull yesterday's scan_exchange report for your /24
import datetime
yesterday = (datetime.date.today() - datetime.timedelta(days=1)).isoformat()
rows = fetch_report("scan_exchange", yesterday, "203.0.113.0/24")
for row in rows:
    print(row["ip"], row["tag"], row.get("version", ""))

That gives you a list of dictionaries, each representing one exposed endpoint. From there the data can be pushed to a SIEM, written to a database, or used to trigger automated ticketing workflows. Teams with mature pipelines typically enrich each row with their own CMDB data before routing it to the appropriate asset owner.

Sinkhole Data: The Signal Most Defenders Ignore

Scanning-based reports are well understood. The sinkhole data is where things get interesting — and where many organizations are sitting on intelligence they do not know how to read.

A sinkhole is a server that has been configured to receive traffic originally destined for malware command-and-control infrastructure. When law enforcement seizes a botnet's domain or when security researchers register an expiring C2 domain before attackers can renew it, DNS for that domain is redirected to a sinkhole IP. Any infected device that tries to check in with its controller instead reaches the sinkhole, which logs the connection attempt without issuing commands.

Shadowserver operates one of the largest sinkhole networks in existence. According to the organization's own published figures, the network handles hundreds of millions of connection events per day across thousands of sinkholes. That scale means Shadowserver sees infected devices that no endpoint agent and no firewall log will ever surface — including devices that have no security software installed at all, such as compromised routers, NAS devices, printers, and IP cameras.

Kijewski has described Shadowserver's approach as delivering "free early warning, threat/vulnerability intelligence feeds and victim notification services to CSIRTs and network defenders worldwide" — sharing around one billion cyber events daily at no cost, with the explicit goal of reaching organizations that cannot afford commercial alternatives.

— Piotr Kijewski, CEO of The Shadowserver Foundation, Help Net Security interview, December 5, 2024

Shadowserver's sinkhole reports appear in the subscriber feed under report type families like botnet_drone, device_id, and malware-family-specific labels such as mirai, qakbot, or emotet (when those families are active). Each row includes the timestamp of the beacon, the source IP, source port, the sinkhole IP and port that received the connection, the malware family tag, and any additional metadata the beacon itself carried, such as a bot identifier or system fingerprint.

Reading a Sinkhole Row

A real-world sinkhole CSV row, simplified, looks like this:

timestamp,           ip,            port, protocol, tag,    asn,   geo, naics,       infection
2026-02-14 03:12:44, 198.51.100.47, 4921, tcp,      mirai,  64512, US,  518210,      mirai.gen

The infection field carries the botnet family identifier as fingerprinted by the sinkhole. The naics field — North American Industry Classification System — tells you the sector the affected IP belongs to. In the example above, NAICS 518210 maps to data processing, hosting, and related services. That context changes how urgently a CERT prioritizes the notification.

For defenders receiving this data about their own network, each row represents a device that is actively attempting to communicate with botnet infrastructure. The device may have been compromised days or months ago. The infection may be dormant, waiting for a command that will never come because the C2 is sinkholed. Or the device may be one of thousands in a maintained botnet that rotates to backup C2 domains regularly. Either way, the device is compromised and needs to be investigated.

Integrating Shadowserver Feeds Into Security Operations

Organizations at varying maturity levels use Shadowserver data differently. Select a pattern below to see how each one works in practice and what it requires from your team.

"We receive Shadowserver's daily reports for our entire national address space and use them as the backbone of our proactive outreach to operators. It is the only source that gives us consistent, comparable coverage across every sector."

— National CERT representative, in discussions on CERT tooling practices, as cited in ENISA threat landscape reporting on CSIRT capacity

Real-World Operational Use Cases

Several documented incidents illustrate where Shadowserver data provided the critical lead that internal monitoring missed.

The Microsoft Exchange ProxyLogon Disclosure (March 2021)

Volt Typhoon and SOHO Router Compromise (2023–2024)

The sustained campaign attributed to China's Volt Typhoon, documented extensively in advisories from CISA, NSA, and the FBI beginning in May 2023, involved the systematic compromise of small office and home office (SOHO) networking devices — Cisco RV-series routers, Netgear ProSAFE products, and Fortinet FortiGate appliances — to build a covert relay network. Many of these devices were already flagged in Shadowserver's vulnerable service reports for months before the advisory dropped, carrying tags for outdated firmware, exposed management interfaces, and in some cases CVEs that had been published over a year prior.

Mirai Variant Tracking

Shadowserver sinkholes have been used in coordinated takedowns and tracking operations for Mirai variants since the original botnet's appearance in 2016. For ISPs, the sinkhole data provides a continuously updated list of infected devices within their subscriber base. A mid-sized ISP receiving daily Shadowserver sinkhole reports can send automated infected-host notifications to residential customers by cross-referencing the IP list against its DHCP lease records. Some ISPs in the Netherlands and Germany have operated exactly this workflow for several years, using Shadowserver data as the trigger for their abuse desk processes.

When the Compromised Device Has No Owner: Unmanaged and OT Assets

A sinkhole report naming a printer, an IP camera, or a building automation controller presents a response problem that most incident response playbooks were not written for. The device has no EDR agent, no local log storage worth examining, and often no mechanism for remote remediation short of a factory reset. For organizations receiving these findings, the operational question is not "how do we investigate this?" but "how do we contain and replace it while keeping the function it serves online?"

The structured path for unmanaged and OT assets identified in Shadowserver sinkhole data runs roughly as follows. First, confirm the IP is currently assigned to the device in question and has not been reallocated — DHCP assignment logs are the fastest path. Second, isolate the device at the network layer before attempting any hands-on intervention: VLAN change or ACL block at the access switch. Third, treat the device as persistently compromised regardless of whether a reboot clears the visible symptom; many IoT malware families survive reboots by writing to flash storage. The device should be reimaged to factory firmware from a verified clean source, or replaced if firmware update tooling is unavailable.

Operation Endgame and Law Enforcement Collaboration

In May 2024, Shadowserver participated in Europol's Operation Endgame — the largest-ever coordinated action against malware loader infrastructure — which disrupted IcedID, SystemBC, Pikabot, Smokeloader, and Bumblebee simultaneously. Shadowserver's sinkhole and victim notification infrastructure was used to alert compromised organizations in the aftermath, and the Foundation subsequently released historical infection datasets as one-off Special Reports so network defenders could investigate prior compromises.

In November 2025, a follow-on disruption action under Operation Endgame targeted the Rhadamanthys information stealer. Law enforcement acquired the threat actor's databases covering the period March 14 through November 11, 2025 — records of over 86 million stolen data items from more than 525,000 infections across 226 countries. Shadowserver released a subset of this dataset as a Special Report, providing a direct, structured path for defenders to identify whether any of their IPs appeared in the infection records.

Report Severity Levels: A 2023 Change That Matters for Triage

In October 2023, Shadowserver introduced formal severity levels across all report types and individual events. Each report type is now assigned a severity — CRITICAL, HIGH, MEDIUM, LOW, or INFO — and each row within a report carries an event-level severity as well. This change has significant operational implications for teams that previously treated all Shadowserver findings with equal priority: you can now filter the entire daily delivery to surface only CRITICAL events, or build SIEM ingestion rules that triage automatically based on severity before any analyst touches the data. A sinkhole beacon from a Mirai-infected printer ranks CRITICAL by default; an informational device identification finding for a cloud host ranks INFO. The severity schema is documented in Shadowserver's release notes and reflected in the CSV field structure.

Who Funds Shadowserver, and What Happens to Your Data

This question comes up in every enterprise security team that seriously evaluates Shadowserver as an operational dependency, and it is one the article on the tin rarely answers: who is behind this, who pays for it, and what do they do with the network information you share when you register?

The Shadowserver Foundation is a registered nonprofit organization founded in 2004. Its funding comes from a documented and publicly disclosed mix of sources. The primary institutional backer as of 2024 is the United Kingdom's Foreign, Commonwealth and Development Office (UK FCDO), which has provided multi-year support covering capacity building across Africa, the Indo-Pacific, Central and Eastern Europe, the Gulf region, and ASEAN countries. Craig Newmark Philanthropies has provided substantial financial support, including a previously disclosed $500,000 donation, and Craig Newmark is described by the organization as its second-largest funding source. The APNIC Foundation provided additional funding in 2024. The organization's Shadowserver Alliance — a growing consortium of like-minded organizations including Mastercard, Avast, Trend Micro, and Akamai — contributes through partnerships, voluntary invoicing, and funded projects. Shadowserver publishes transparency about its funding composition on its website and in annual reviews.

The funding picture has changed meaningfully since 2020, when the withdrawal of prior industry support briefly threatened the organization's operations. The resolution of that funding crisis — and the subsequent growth in government and civil society backing — has placed Shadowserver on a more diversified footing. Notably, in 2024 Shadowserver was recognized by vulnerability intelligence firm VulnCheck as the "Earliest Reporter of Exploitation in the Wild," reflecting the organization's operational centrality to global vulnerability tracking.

On data handling: the information Shadowserver collects is network-level telemetry observed from the public internet. It does not involve accessing your internal systems. When you register a prefix, you are not granting Shadowserver any access to your network; you are claiming ownership of data that Shadowserver is already collecting about your publicly visible address space. The registration simply determines who receives the report about that data.

Limitations and What Shadowserver Cannot Do

Understanding where Shadowserver data falls short is as important as knowing where it excels.

Key Takeaways

1. Register your network prefixes: The Shadowserver reporting service is free and requires only proof of network ownership. Any organization that has not yet registered its ASN or IP prefixes is receiving none of this data and has no external baseline for its internet-facing exposure.
2. Sinkhole reports require different handling than scan reports: A host appearing in a vulnerability scan report is exposed. A host appearing in a sinkhole report is actively infected. Prioritize sinkhole findings for immediate incident response triage regardless of asset criticality scores.
3. Use severity levels to triage automatically: Since October 2023, every Shadowserver report type and every event row carries a severity field. Build your ingestion pipeline to filter on CRITICAL events first — you will surface compromised hosts and actively exploited services without requiring an analyst to read every CSV row.
4. Automate ingestion and enrichment: Daily email review of raw CSVs does not scale. Even a simple script that cross-references Shadowserver IPs against your CMDB and creates tickets will dramatically increase the operational value of the data.
5. Repeat findings signal process failures: If the same IP appears in the same Shadowserver report type across multiple weeks or months, the problem is not detection — it is remediation. That pattern is worth surfacing explicitly in SIEM dashboards as a metric for patch and configuration management effectiveness.
6. Use the API for real-time IP reputation checks: The Shadowserver API supports ad-hoc queries against its reputation database. Security orchestration playbooks can query Shadowserver during alert triage to check whether a flagged IP has appeared in any Shadowserver report within the past 30 days, adding context that accelerates analyst decisions without requiring a full feed integration.
7. Monitor Special Reports during major incidents: When law enforcement disrupts a botnet or a critical vulnerability is disclosed, Shadowserver publishes one-off Special Reports within days. Subscribing to the mailing list and monitoring the Shadowserver news feed means your team gets structured, per-IP data on your address space before mainstream coverage reaches most practitioners.

Shadowserver's data has been quietly underpinning national-level cyber defense for over two decades. For most individual organizations, the barrier to using it is not cost or complexity — both are minimal — but awareness. The data exists, it is updated daily, and it will tell you things about your network's internet-facing posture that no internal tool can replicate. Getting the most out of it requires treating it as a live operational feed rather than a periodic reference, building the integrations that surface its findings in the same place where analysts already work, and understanding that absence of findings is a property of scanning cycles, not a guarantee of a clean network.