Encrypted, not anonymous: how DarkForums leaked their IP through Censys

Picture this: you’ve set up a private XMPP server for internal communications. Encryption is configured, TLS is on, nobody outside can read the messages. You reasonably consider the server protected. Then someone runs a basic Censys query — and sees your real IP address, hosting provider, datacenter location, and open port list. No exploit, no breach, no special knowledge — just public DNS records read in the right order.

That’s exactly what happened to DarkForums — one of the largest English-language hacking communities on the dark web. The forum ran its own XMPP service under two domains — darked.im and darkforums.im — pitched to members as “a private, encrypted, unmonitored channel for those who don’t want their communications monitored or censored.” On June 17, 2026, analysts at Covert Security, based in Tallinn, published their findings: both domains resolve to the same public IP 172.234.115.5, the server runs on Linode under Akamai Connected Cloud in Stockholm, and a standard Censys query finds it in minutes. No Tor. No hidden service. No anonymization layer of any kind — a standard cloud server, indexed like any other.

This isn’t a vulnerability in XMPP and it isn’t a flaw in the encryption. It’s an operational failure: the people who promised anonymity solved one problem (encrypting the content) and completely ignored the other (hiding the infrastructure). For any sysadmin running a private service — a Matrix instance, a VPN gateway, an internal chat, a corporate messenger — this case shows exactly the mistake that’s easy to make yourself.

HOW THEY FOUND IT

Covert Security’s methodology is fully transparent and replicable. Step one: query Censys for domains associated with DarkForums infrastructure. Censys is an internet infrastructure search engine that continuously scans the entire IPv4 address space, collects service banners, TLS certificates, DNS records, and indexes the results. Step two: review the forward DNS data for the returned IP address. Step three: cross-reference every domain resolving to the same address. Step four: investigate any unexpected or unexplained domains in the results.

The results spoke for themselves. IP 172.234.115.5 belongs to Linode/Akamai (AS172.234.96.0/19), geolocated to Stockholm, Sweden (59.32938° N, 18.06871° E). Six services are running on that address: SSH on port 22, HTTP on 80 and 443, and three XMPP ports — 5222, 5223, and 5269. The HTTP/443 response, last observed at 07:09 UTC on June 14, 2026, returns the HTML title “Darked.IM | Free Secure XMPP for the DarkForums Community” — which definitively identifies the server without any active probing.

The same IP also hosts xmpp.sg — a separate public XMPP service with no apparent connection to DarkForums, whose users had no reason to know they were sharing infrastructure with one of the largest hacking forums on the dark web. Also present: the subdomain jdrtyipau.er18.mobi, left over from the expired domain er18.mobi, currently listed for sale on the Chinese registrar west.cn. Nobody cleaned up the DNS record, and it still points at the same server. The subdomain name itself reads like an auto-generated identifier — the kind produced by monitoring tools or CDN configuration scripts. What it means is genuinely unclear; Covert Security deliberately draws no conclusions from a single orphaned record.

WHY ENCRYPTION ISN’T ENOUGH

This is the core lesson of this incident, and it’s worth stating plainly: encrypting traffic and hiding infrastructure are two separate problems, solved by different means. XMPP with TLS protects the content of messages. It does not hide the fact that the server exists, its location, its provider, its open port list, or — most importantly — connection metadata.

Different observers see different things. Censys and Shodan see the server itself: open ports, TLS certificates, service banners. The hosting provider — Linode in this case — sees network traffic at the flow level: which IP addresses connected to the server, when, how often, and for how long. That’s metadata. In criminal investigations, metadata is often more valuable than content. It’s precisely why Signal has spent years engineering metadata minimization as a dedicated problem — not because their encryption is insufficient, but because encryption doesn’t hide the fact of communication itself.

Linode and Akamai are US companies. The server physically sits in Sweden. That means connection data is potentially accessible through mutual legal assistance using both US and EU law. XMPP encryption doesn’t change that: it protects the content, but not against a request to the hosting provider asking which IP addresses connected to the server and when.

COMMON MISTAKES WHEN RUNNING PRIVATE SERVICES

DarkForums made a textbook set of mistakes — the ones that show up whenever someone stands up an “internal” service and underestimates how visible it is from the outside.

The first and most fundamental mistake: the service listens on a public IP. If a service isn’t meant for public access, it shouldn’t be reachable from the internet at all. TLS and strong passwords don’t help here — the open port on a public IP is enough for Censys, Shodan, and similar tools to index the server in minutes. The fix: the service listens only on loopback (127.0.0.1) or an internal interface, with outside access only through a VPN tunnel.

Second mistake: running a private service on the same IP as public services. In DarkForums’ case, xmpp.sg on the same address serves as an additional identifier during OSINT analysis. Seeing xmpp.sg, a researcher connects two supposedly independent services through shared infrastructure. The fix: private and public services on separate servers with separate IPs — no overlap at the addressing level.

Third mistake: abandoned DNS records. The er18.mobi domain expired, but the subdomain jdrtyipau.er18.mobi kept pointing at the same server — a digital trail that links current infrastructure to the operators’ past history. Before giving up a domain or IP, audit every record pointing to it, including subdomains via crt.sh.

Fourth mistake: the illusion of choice without real isolation. The two domains darked.im and darkforums.im gave users the feeling of a choice, but both resolved to the same IP. Picture a user who registered on darkforums.im thinking it was “more private” or just out of habit. From Censys’s point of view, they connected to the same 172.234.115.5 as everyone else. Real isolation means separate servers, separate hosting accounts, separate jurisdictions. Two domains on one VPS is just two labels on the same folder.

HOW TO ACTUALLY HIDE YOUR INFRASTRUCTURE

The right approach depends on how serious your confidentiality requirements are. But the baseline principles are the same for any “internal” service — a corporate messenger, VPN gateway, admin panel, or monitoring stack.

The most reliable option: the service doesn’t listen on any public interface at all. For most services this means specifying a concrete internal address instead of 0.0.0.0. To check what your service is actually listening on:

ss -tlnp

The output lists all TCP ports in LISTEN state. The Local Address column shows which interface each service is bound to: 0.0.0.0:5222 means it’s listening on all interfaces and is reachable from the internet. 127.0.0.1:5222 or 10.0.0.1:5222 means loopback or an internal interface only — not visible from outside.

If a service needs outside access but only for specific users, nftables with IP-based restrictions or a VPN tunnel is the right answer. An nftables rule that allows the XMPP port only from a specific subnet:

nft add rule inet filter input tcp dport 5222 ip saddr 10.0.0.0/24 accept
nft add rule inet filter input tcp dport 5222 drop

The first rule allows connections to port 5222 from the 10.0.0.0/24 subnet. The second drops everything else. Order matters: nftables processes rules sequentially, and the first match wins.

For cases where public access is needed without exposing the real IP — Cloudflare Tunnel. It establishes an outbound connection from your server to Cloudflare, after which traffic flows through Cloudflare’s infrastructure. The real server IP is never exposed to clients — they connect to Cloudflare, not your server directly. For HTTP services this works through the standard Tunnel. For XMPP and other non-standard TCP protocols — through Cloudflare Spectrum, but there’s an important caveat: Spectrum is available on Pro and Business plans, but only for selected protocols (SSH, FTP, Minecraft). Arbitrary TCP ports including XMPP (5222, 5223, 5269) require the Enterprise plan per the official Cloudflare documentation. For most private deployments that’s not realistic — a WireGuard tunnel as described below solves the problem more simply and cheaply.

If the service is for a limited group of users, a VPN tunnel is the cleanest isolation option. The classic setup: WireGuard or AmneziaWG on the server, the private service configured to listen only on the WireGuard interface (typically wg0, with an address like 10.0.0.1). From the outside, only the WireGuard UDP port and SSH are visible — nothing else. Users connect to the VPN first, and only then reach the private services. Censys sees the open WireGuard UDP port but sees none of the XMPP ports or any other services behind it — those exist only inside the VPN network.

WireGuard hides the service from scanners — but it doesn’t erase the history. If the server was ever tied to a domain, if DNS records were left dangling after an IP change, if an expired domain was never cleaned up — the digital trail exists regardless of how well the current service is hidden. That’s why DNS hygiene is a separate mandatory practice that complements network isolation rather than replacing it. Before giving up a domain or IP, audit all DNS records pointing to it, including subdomains. For a quick check of records you already know about:

dig +short @8.8.8.8 example.com
dig +short @8.8.8.8 www.example.com
dig +short @8.8.8.8 mail.example.com

But manual checks are unreliable — you don’t know about every subdomain that ever existed. Better to use Certificate Transparency logs: every TLS certificate ever issued for your domain is visible on crt.sh. Query it at https://crt.sh/?q=%.example.com and review the list — it shows every subdomain that ever had a certificate issued. That gives you the full picture of what existed, even if the DNS records have been removed.

Checking your server’s visibility through public scanners is good regular hygiene. Censys lets you search by IP address, domain, and TLS certificates. For your own server: visit https://search.censys.io/hosts/YOUR_IP and see what’s visible from the outside. Per Covert Security’s own note, the free Censys tier is sufficient for this — no special access or paid subscription required. It takes a minute and shows exactly what any external observer sees.

TIMELINE

June 14, 2026, 07:09 UTC — the last Censys-recorded HTTP response from server 172.234.115.5 with the HTML title “Darked.IM | Free Secure XMPP for the DarkForums Community.” This predates the publication — the server was already indexed and the data was already in Censys’s database. Covert Security found it later by reviewing archived data.

June 17, 2026 — Covert Security publishes “Dark Forums Jabber — IP Leak by Design.” The full methodology is open and replicable: DNS queries plus Censys, no active probing of the service. Specifically noted: the entire process took minutes, and the free Censys tier is sufficient for a complete replication.

June 20, 2026 — the story receives broad coverage in the security press. At the time of publication, DarkForums had not issued any public statement about the infrastructure exposure. Per open source data, the server continues to operate and the infrastructure has not changed.

WHY THIS MATTERS

DarkForums is not the first case of deanonymization through infrastructure analysis, and it won’t be the last. Freedom Hosting — once the largest dark web hosting provider — was identified by the FBI through network infrastructure analysis well before any technical breach. AlphaBay, the largest dark web marketplace at the time of its 2017 takedown, was deanonymized in part through operational mistakes: administrator Alexandre Cazes used the same email address ([email protected]) for marketplace setup and in his personal LinkedIn and PayPal accounts. Silk Road fell through a similar lapse — Ross Ulbricht sought technical help on public forums under his real name. The pattern is consistent: the cryptography worked, the content was protected, but operational mistakes in infrastructure and behavior gave everything else away.

The same mistake shows up in corporate environments where teams spin up “internal” tools on cloud servers with public IPs. A Matrix instance for internal communications, Gitea for private repositories, Grafana for monitoring, an admin panel — these regularly get launched on 0.0.0.0 under the assumption that “nobody outside knows the address.” Censys knows. Shodan knows. FOFA knows. All of these tools scan the entire IPv4 range continuously — your “internal” service ends up in their database within hours of launch.

For anyone planning a private service — VPN, Matrix, XMPP, admin interface — this case provides a concrete checklist: no public IP for services that shouldn’t be public; no shared IP between public and private infrastructure; no abandoned DNS records; no illusion of domain choice without real isolation. Encrypting traffic is one problem. Hiding the fact that the service exists is another. History keeps showing that you need to solve both.

CONCLUSIONS

What makes the DarkForums case useful is that it’s fully replicable and instructive without any vulnerability involved. Nothing was hacked. No CVE. Just DNS plus Censys plus a few minutes — and a complete infrastructure picture available to anyone willing to look.

Covert Security’s analysts found DarkForums during a coffee break — their words, not hyperbole. Checking your own server takes about as long. Run ss -tlnp and see which addresses your services are actually listening on. Visit https://search.censys.io/hosts/YOUR_IP and see what Censys sees right now. Check crt.sh for subdomains you may have forgotten. If the results don’t surprise you — good. If they do — better to find out yourself than to wait for someone else to publish a writeup about your infrastructure.