Welcome to SAYOR-Secure At Your Own Risk

• Infrastructure: Monitoring unused IP space where no legitimate traffic should exist.
• Data Collection: Any packet arriving at these addresses is categorized as suspicious, eliminating the "noise" of legitimate user traffic.
• Reporting Pipeline: Malicious activity is automatically logged and reported to the community to help secure thousands of independent servers.

1. SSH Brute-Forcing: Bots attempting to crack server credentials via port 22.
2. Web App Probing: Scanners looking for vulnerable files like /phpmyadmin or .env.
3. DDoS Backscatter: Identifying third-party victims of spoofed Denial-of-Service attacks.
4. Mass Reconnaissance: General port sweeps (ZMap/Masscan) searching for open databases (MySQL, RDP).

• Reliability: The use of telescope architecture makes its reports far more reliable than standard firewall logs.
• Global Impact: By feeding data into the AbuseIPDB API, this project empowers sysadmins worldwide to block attackers before they ever reach a production environment.
• Recommendation: System administrators should prioritize reports from verified supporters like sbk97 when configuring automated blocklists (e.g., Fail2Ban or CrowdSec).

Category 1 — Big Tech Origin Discovery: Google and Baidu

This is the most significant cluster in the dataset and the one with the clearest geopolitical signal.

Probing google.com:443

95.111.253.31    → google.com:443
185.249.225.89   → google.com:443
194.165.17.13    → google.com:443
36.255.98.221    → google.com:443
204.76.203.10    → google.com:443
138.124.14.152   → google.com:443
103.252.91.84    → google.com:443
138.121.198.109  → google.com:443
176.65.148.74    → google.com:443
152.42.200.86    → google.com:443
139.59.110.5     → google.com:443
165.245.179.4    → google.com:443
45.205.1.50      → google.com:443
176.65.149.215   → google.com:443
45.135.194.20    → google.com:443

ASN/Geo Attribution:

95.111.253.31 resolves to Contabo GmbH, Munich, Germany (AS51167) — one of the most frequently abused bulk VPS providers in Europe. Contabo's infrastructure is a known launchpad for scanning campaigns because of cheap, no-questions-asked provisioning. The 185.249.225.89, 138.124.x.x, and 176.65.x.x blocks also fall within European commercial hosting ranges commonly seen in reconnaissance datasets. 204.76.203.x is a US-hosted VPS range. 139.59.110.5 is a DigitalOcean Bangalore node (DO-BOT-IND range), and 152.42.200.86 resolves to DigitalOcean's Singapore cluster.

What's being attempted: Every one of these IPs is trying to reach a server that will respond to Host: google.com:443 as an origin would — exposing Google's actual backend IP or a misconfigured upstream that routes google.com traffic internally. This is a known precursor to direct-to-origin DDoS and WAF bypass attacks. The goal isn't to attack Google directly from here — it's to find a misconfigured server somewhere on the internet that leaks origin behavior.

Probing www.baidu.com:443

115.238.44.234   → www.baidu.com:443
202.107.226.5    → www.baidu.com:443
23.235.176.50    → www.baidu.com:443
61.228.211.72    → www.baidu.com:443
114.25.99.76     → www.baidu.com:443
58.240.112.150   → www.baidu.com:443
61.228.202.104   → www.baidu.com:443

ASN/Geo Attribution:

115.238.44.234 is a Hangzhou, China IP (China Telecom Zhejiang Province, AS4134). 202.107.226.5 also maps to China Telecom. 61.228.x.x and 114.25.x.x are Taiwanese IP ranges (Chunghwa Telecom, AS3462). 58.240.x.x is China Unicom Jiangsu.

The geopolitical pattern here is real. Probing for Baidu's origin servers is dominated almost entirely by East Asian IP space — Chinese mainland and Taiwan. The google.com probers lean European and global cloud-hosted. This is not a coincidence. East Asian botnet infrastructure and scanning campaigns naturally target East Asian CDN-protected services. Whether these IPs are compromised residential nodes, VPS bots, or deliberate scanning infrastructure, the geographic clustering with the target domain is consistent across the dataset.

Category 2 — CDN Behavior Mapping: Cloudflare and Google Speed

35.200.210.103   → speed.cloudflare.com
35.200.184.180   → speed.cloudflare.com
34.47.160.27     → speed.cloudflare.com
138.124.96.105   → cloudflare.com
83.142.209.181   → cloudflare.com:443

The 35.200.x.x range is a well-known GCP block — specifically Google Cloud Platform's asia-south1 region (Mumbai). Three separate GCP nodes probing speed.cloudflare.com suggests either compromised compute instances running as bots, or misconfigured automation that's firing connection checks through forged Host headers. speed.cloudflare.com is Cloudflare's own network speed testing endpoint — probing it via Host header injection is a way to map CDN edge routing logic and response timing differences that could expose backend routing inconsistencies.

The 83.142.209.181 → cloudflare.com:443 probe is European hosting infrastructure attempting the same against Cloudflare's primary domain.

Category 3 — OS Connectivity Check Abuse: Microsoft NCSI and Google CaptivePortal

78.138.177.80    → www.msftncsi.com:443
54.162.150.202   → www.msftncsi.com:443
198.46.146.122   → connectivitycheck.gstatic.com:443
69.165.72.109    → connectivitycheck.gstatic.com:443

msftncsi.com (Microsoft Network Connectivity Status Indicator) and connectivitycheck.gstatic.com are endpoints that Windows and Android devices use to verify internet connectivity. They're trusted, whitelisted, and generate near-zero suspicion in most network monitoring stacks.

54.162.150.202 is Amazon EC2 us-east-1 (AWS Virginia). 78.138.177.80 is European hosting. 198.46.146.122 and 69.165.72.109 are US VPS nodes. The fact that these cloud-hosted IPs are probing connectivity-check endpoints via forged Host headers suggests they're trying to blend into baseline traffic — standard evasion behavior designed to slip past IDS/IPS rules that whitelist system-level connectivity destinations.

Category 4 — HTTP Testing Infrastructure and Proxy Validation: httpbin.org

176.65.149.48    → httpbin.org
121.91.235.186   → httpbin.org
102.165.26.200   → httpbin.org
87.121.84.172    → httpbin.org

httpbin.org is a public HTTP request and response service used by developers. But attackers use it too — because it reflects request headers back verbatim, making it an ideal tool for validating whether a proxy or forged Host header is being passed through correctly or stripped by intermediary infrastructure.

These probes likely come from automated exploit frameworks validating their own payload delivery chains. If a bot can send Host: httpbin.org and get a reflection, it knows the target server doesn't strip Host headers before proxying — which means the server might be exploitable for SSRF or header injection at other targets.

Category 5 — Anomalous Targets: S3, Codeforces, Roblox, Sogou

90.148.155.161   → test.s3.amazonaws.com
185.249.225.89   → codeforces.com:443
23.95.130.27     → codeforces.com:443
204.76.203.87    → www.roblox.com:443
45.194.92.11     → www.roblox.com:443
43.133.146.123   → www.sogou.com
64.112.74.158    → authorit.sa.com

test.s3.amazonaws.com is a classic SSRF testing target — attackers probe this to check if a server will make upstream connections to AWS S3 on their behalf, which would confirm a server-side request forgery vulnerability. 90.148.155.161 is a European residential or VPS IP.

www.sogou.com (China's major search engine) probed from 43.133.146.123 — this is a Tencent Cloud IP (Hong Kong region, AS132203). Chinese cloud infrastructure probing a Chinese search engine's origin via forged Host headers is consistent with competitive intelligence gathering or vulnerability research originating from within the same regional ecosystem.

www.roblox.com probes from 204.76.203.87 and 45.194.92.11 — both US VPS ranges — likely represent gaming platform origin discovery or DDoS preparation targeting a high-traffic, CDN-protected platform.

authorit.sa.com — this is the most unusual target. It appears to be a Saudi Arabian (.sa) authority domain. 64.112.74.158 is a US-based IP. This probe stands out as potentially targeted reconnaissance rather than broad-spectrum scanning.

Category 6 — Null Routing and Bogon Host Headers: 0.0.0.0, 1.1.1.1, and Private Ranges

34.151.206.25    → 0.0.0.0
187.110.175.205  → 0.0.0.0
51.38.90.52      → 0.0.0.0
177.190.67.44    → 0.0.0.0
46.101.36.170    → 0.0.0.0
213.209.143.73   → 1.1.1.1:443
176.117.107.96   → 1.1.1.1:443
5.62.63.190      → 100.100.100.200
90.148.155.161   → 100.100.100.200
5.62.63.190      → 100.88.222.5

0.0.0.0 as a Host header is either scanner default-fill behavior or a deliberate probe for servers with a wildcard/default virtual host configured — which would respond to any Host value. If a server responds to Host: 0.0.0.0, it's almost certainly misconfigured, and its default vhost content may expose internal services, admin panels, or staging environments.

1.1.1.1:443 — probing Cloudflare's public DNS resolver via Host header is a check for whether the responding server is a Cloudflare proxy edge node. If it responds as one, the attacker knows they're looking at CDN infrastructure rather than an origin.

100.100.100.200 is Alibaba Cloud's internal metadata service address (the AWS equivalent of 169.254.169.254 in Alibaba's ecosystem). Probing this as a Host header from IPs like 5.62.63.190 (UK hosting range, Porkbun LLC adjacent blocks) and 90.148.155.161 (European VPS) suggests SSRF testing specifically against servers that might be running on Alibaba Cloud infrastructure — if the server makes an internal request to the metadata service, the attacker can potentially harvest IAM credentials.

100.88.222.5 falls within AWS's internal VPC connectivity range. Same attacker (5.62.63.190), same playbook — probe for SSRF against cloud metadata endpoints by injecting them as Host headers.

The East Asian clustering around Baidu and the European/global clustering around Google holds across the entire dataset. This is a meaningful signal. It doesn't mean nation-state actors — it more likely reflects botnet geographic distribution and the natural affinity of regional scanning infrastructure toward regional targets. But it's a pattern worth tracking.

What Should Defenders Do With This?

First, validate your server's Host header handling. If your reverse proxy (nginx, Apache, Caddy) has a default virtual host configured, test what it returns for unknown Host values. It should return nothing useful — a 444 in nginx, or a deliberate stub.

Second, if you're behind a CDN or WAF, ensure your origin server is not directly reachable on port 443 from the public internet. Whitelist only your CDN provider's IP ranges.

Third, flag inbound Host headers containing domains you don't own. If google.com appears in your access logs as a Host header, something has gone wrong — either a misconfigured client or an active probe. Neither should reach your application layer.

Fourth, treat cloud metadata IP ranges (100.100.100.200, 169.254.169.254, 100.88.222.5) as high-severity Host header values in your WAF. Any server-side code that makes outbound connections using user-supplied Host values is a live SSRF risk.

Final Assessment

This dataset represents automated pre-attack infrastructure mapping, not targeted exploitation. The actors here are building a map — finding which servers on the internet leak origin behavior, accept arbitrary Host headers, or could be weaponized as SSRF stepping stones. The real attacks come later, once that map is drawn.

The geographic patterns are consistent, the tooling is varied, and the targets are deliberate. If your server appears in logs like these, you're already on someone's list.

IOC feed and live telescope data: https://sayor.net/host%20header%20attacks.php

Secure at Your Own Risk – Exploring the critical identities safeguarding Internet security

The Internet may feel like a self-regulating machine: packets flow, servers respond, and protocols ensure everything works. But behind the algorithms and cryptography lies a human backbone: a few trusted identities whose integrity ensures the Internet stays secure.

Global DNS Root Server List

The foundation of every Top Level Domain on the Internet

Below are the 13 DNS root server identities that the Internet relies on. Each of these server identities has one (or more) IPv4 and IPv6 addresses, and each is operated by a distinct organization holding responsibility for the DNS root.

Pakistan Has Local DNS Root Infrastructure

Pakistan isn’t isolated from the global DNS root system — it has local instances of root servers, which drastically improves local DNS performance and reduces latency.

✔ ICANN & local ISP deployments

• Pakistan hosts an L‑Root server instance (one of the 13 named root servers) deployed in Islamabad (and additionally in Lahore) through partnerships between ICANN and local operators like Nayatel and COMSATS Internet Services.
• These local instances improve DNS resolution quality and reduce round‑trip time for queries from Pakistan.

The Invisible Guardians

At the heart of Internet security are two critical systems:

• DNSSEC – protects the integrity of domain name resolution.
• BGPSEC / RPKI – secures Internet routing against hijacks.

Both rely on cryptography — private keys, digital signatures, and trust anchors. Yet cryptography alone isn’t enough. The private keys securing the root of the Internet must be managed by reliable, accountable humans.

🔹 Even perfect algorithms can’t replace human trust.

Meet the Trusted Community Representatives (TCRs)

The Root DNSSEC Key Signing Key (KSK) is the ultimate trust anchor. It signs the root zone’s keys, which validate all DNSSEC-protected domains worldwide.

To oversee this, ICANN appoints Trusted Community Representatives - humans tasked with verifying and witnessing key operations.

Current TCRs:

• Tim April
• Nabil Benamar
• Lodrina Cherne
• Kenny Huang
• Ryan Hurst
• Matt Pounsett

These representatives are not symbolic. They ensure:

• Multi-person oversight of cryptographic key operations
• Integrity of global DNS trust
• No single person or organization can compromise the root keys

Why Personality Matters as Much as Cryptography

Think of the Internet like a highway system:

• Network infrastructure = the roads
• Security mechanisms = traffic lights, toll gates, checkpoints
• Trusted personalities = the drivers, inspectors, and gatekeepers ensuring rules are followed

Without accountable humans, even perfectly secure keys can be misused — leading to hijacks, outages, and Denial-of-Service events.

When Trust Fails

A BGP hijack or root server misconfiguration can temporarily disrupt DNS resolution. Even with DNSSEC:

• Traffic may be rerouted or blocked
• Resolvers may fail to reach root servers
• Recovery depends on rapid human intervention

These scenarios highlight why trust in people is the ultimate layer of Internet security.

Takeaways for Security Professionals

1. Security is not just technical — it is technical + human accountability.
2. Knowing who holds responsibility for keys and certificates is key for threat intelligence.
3. Awareness of root governance and key ceremonies reveals how the Internet withstands attacks that cryptography alone cannot stop.

Closing Thoughts

The Internet’s autonomy is an illusion. From the TCRs overseeing DNSSEC root keys to operators managing BGP and RPKI, a handful of accountable personalities literally hold the keys to global connectivity.

At SAYOR.net, we explore the intersection of technology, human behavior, and security risk — because knowing who is trusted is just as important as knowing how the system works.

In today’s hyper-connected world, the cyber battlefield is no longer confined to isolated breaches. A new war is emerging—a war fought not with bombs or tanks, but with sophisticated malware, compromised supply chains, and control over the very infrastructure that keeps the global internet alive. At the heart of this conflict lie two digital superpowers: the United States and China.

The Invisible Battlefield

Supply Chain Sabotage

Modern cyber attacks increasingly exploit vulnerabilities in the global supply chain. Consider the infamous case of Stuxnet—the worm discovered in 2010 that is estimated to have destroyed up to 1,000 Iranian centrifuges and cost its adversaries millions in economic damage. In another oft-cited example, anecdotal reports of “pager explosions” in the late 1990s (allegedly engineered by intelligence agencies) illustrate how even everyday devices can be weaponized. Such incidents underscore the dangers when trusted hardware and software become vectors for sabotage.

Data Centers: The New Nerve Centers

Data centers are emerging as the nerve centers of digital warfare. In a 2020 study, cybersecurity experts noted that roughly 70% of global internet traffic flows through just a few Tier 1 data centers. Gaining control over these hubs would let an attacker not only intercept and decrypt sensitive communications but also enforce rogue digital certificates. In the event of a cyber conflict, even a brief disruption could affect millions of users worldwide.

DNS and CA: Rewriting Digital Trust

Control of the Domain Name System (DNS) and certificate authorities (CAs) is the keystone of internet trust. Past incidents have revealed how a compromised CA can shake the very foundations of secure communications. For example, in 2015, mis-issuance issues with the Chinese government–backed CNNIC led major browsers to temporarily distrust its certificates—an early sign of how state-controlled CAs can become tools for exerting digital influence. Recent trends suggest that if adversaries succeed in adding state–controlled CAs into the trust stores of major operating systems, they could issue fraudulent certificates to intercept encrypted traffic worldwide.

Market Domination and Vendor Lock–in

The cyber domain is further complicated by the market capture of global technology giants. Today, Microsoft dominates over 75% of the desktop OS market, while Android holds nearly 72% of the global mobile market. Apple, Meta (Facebook), and Twitter each command billions of user accounts. Such widespread reliance means that if these companies—or their supply chains—are coerced (or subtly influenced through vendor lock–in tactics), a nation–state actor could gradually tighten its grip on critical digital infrastructure. For instance, if key software update channels or cloud platforms were compromised or mandated to include back–doors, the resulting lock–in could force organizations into a state of perpetual vulnerability.

Escalation: From Stealthy Infiltration to Global Control

Phase 1: Silent Infiltration

Both the United States and China are believed to be actively planting malware and hardware implants deep into global supply chains. Stuxnet’s success in infiltrating Iranian industrial systems—and similar covert operations—illustrate how early access can later yield crippling effects.

Phase 2: The Credential Coup

After establishing a foothold, attackers may target certificate authorities. By compromising a CA (or even adding state–controlled CA’s to global trust stores), adversaries can issue rogue digital certificates. A single compromise in this chain can potentially affect millions of secure communications, as demonstrated by past CA breaches that forced major browsers to update their trust lists overnight.

Phase 3: Hijacking the Digital Highway

At the heart of the internet lies the Border Gateway Protocol (BGP). Over the years, several notable BGP hijacking incidents have been recorded—such as the 2008 YouTube incident when Pakistan Telecom’s misconfiguration redirected global YouTube traffic for several hours. More recent studies suggest that hundreds of such hijacks occur every year, allowing attackers to redirect and intercept data flows on a massive scale.

Phase 4: Data Center Assault and AI–Driven Cyber Offensives

In a full–scale digital conflict, massive attacks on Tier 1 data centers could paralyze global communications. AI–powered malware, much like that seen in recent proof–of–concept campaigns, might autonomously exploit vulnerabilities in real time, targeting critical infrastructure from power grids to water systems.

Real–World Implications

The cyber battlefield is already active. In addition to Stuxnet’s legacy, multiple documented BGP hijacks have disrupted internet traffic globally, and CA compromises have forced a rapid reassessment of digital trust frameworks. More alarmingly, allegations that state–sponsored groups are influencing trust stores (adding Chinese CA’s) highlight a potential future where vendor lock–in isn’t just a commercial strategy but a matter of national security. When companies as dominant as Microsoft, Apple, and Android underpin our digital lives, the manipulation of their update and certification processes could leave entire sectors hostage to a state’s will.

For everyday users, the consequences are profound: our personal data, commercial secrets, and even the very fabric of internet trust hang in the balance. In this high–stakes arena, the biggest losers may well be ordinary citizens caught in the crossfire of global espionage and cyber warfare.

Looking Ahead: Defending a Decentralized Future

The digital arena is evolving, and so must our defenses. Strategies to counter this emerging threat include:

• Decentralizing the Web: By reducing the reliance on a few central data centers, we lower single points of failure.
• Enhanced DNS Security: Adopting protocols such as DNSSEC and DANE can help safeguard against hijacking and fraudulent certificate issuance.
• Revamping CA Practices: Strengthening code–signing procedures and tightening CA vetting processes are essential to restore trust.
• AI–Powered Cyber Defenses: Advanced AI tools can help monitor vast networks in real time and rapidly identify anomalous behavior, reducing the window of vulnerability.

As cyber warfare intensifies, the battle for digital supremacy is not a distant future scenario—it is unfolding right now. The struggle over supply chains, DNS, and digital certificates is the new frontier of national power. In this escalating conflict, the party that masters the infrastructure of the internet may well shape the global order for decades to come.