"Lost in the .cloud: Internal Domain Collisions in SoftLayer/IBM Cloud"
Security Research Team
Philippe Caturegli
May 20, 2025
7 min read
For the past year, we’ve been conducting security research on the resurgence of internal domain name collision. During this research, we uncovered countless companies affected. While we can’t share the details of every finding, this particular case involving IBM Cloud / SoftLayer highlights how common, and often misunderstood, this problem is.
Seemingly minor configuration assumptions can quietly lead to serious security exposure. In this case, the issue stemmed from the use of internal Fully Qualified Domain Names (FQDNs) under the publicly available .cloud top-level domain, without actually registering the corresponding domain names. This led to unintended data leaks and introduced multiple potential attack vectors.
What is internal domain name collision?
A name collision occurs when an attempt to resolve a name used in a private namespace (e.g., a short or unqualified internal name) results in a query being sent to the public Domain Name System (DNS).
For analogy: imagine calling out “Alice” in a small office where there’s only one Alice, now imagine shouting “Alice” in a shopping mall and expecting the same response. The context that worked internally no longer applies.
To prevent this, best practice has long been to use non-routable, reserved suffixes such as .local for internal domains. Unfortunately, not all organizations followed this advice. In many environments, internal FQDNs were built using TLDs assumed to be safe simply because they weren’t yet in use.
With ICANN’s expansion of the DNS root zone and the introduction of hundreds of new generic top-level domains (gTLDs) over the past decade (such as .cloud, .dev, or .app) some of these internal naming choices now collide with valid, routable domains. Even if a name didn't pose a risk when originally configured, it might now or in the future if that TLD is delegated.
One other factor contributing to the recent resurgence of domain name collisions is the shift toward remote and hybrid work. Historically, corporate workstations operated within the same internal network, consistently relying on a centralized DNS resolver. In such scenarios, domain collisions often went unnoticed. But as employees increasingly work remotely, connect through VPNs, or roam between networks, corporate devices now interact with a variety of DNS resolvers, both internal and public. This increases the likelihood that internal DNS queries are leaked to the public internet, especially when internal systems use names built under valid public TLDs.
This issue affects all operating systems. While legacy proxy behaviors like Web Proxy Auto-Discovery (WPAD) are specific to Windows, the use of DNS suffixes to resolve unqualified names is common across Windows, Linux, macOS, and other systems. When internal domains are built under publicly delegated TLDs, these lookups can leak to external resolvers regardless of the platform.
How did it all start?
Our investigation began as part of a broader effort to identify internal domain names unintentionally leaking into the public internet. One of the techniques we used was scanning self-signed TLS certificates indexed by Censys and cross-referencing all observed domains with their registration status.
If we encounter a TLS certificate with an internal-looking domain that uses a publicly valid top-level domain (TLD) and that domain is unregistered, we have a classic case of an exploitable internal domain name collision.
Passive DNS monitoring in action.
In this particular case, we focused on the .cloud TLD, specifically looking for domains that were clearly intended for internal use and had not been registered. Among them, we found over 140 certificates containing the domain softlayer-internal-acs-support.cloud.
As we reviewed the dataset, we saw various Common Names (CN) and Subject Alternative Names (SANs) tied to what looked like internal services, including Veeam backup infrastructure, bare-metal hosts, and other test or management systems.
Next, we did what anyone looking for exploitable internal domain collision would do in this situation: we checked if the domain was actually available for purchase. Sure enough, it was.
Screenshot from namecheap.
For the price of a latte ($3.98), we registered softlayer-internal-acs-support.cloud to observe whether any legitimate traffic would reach us.
It didn’t take long to confirm our suspicion. Within a few days, our passive DNS logs had captured over 390,000 DNS queries, including WPAD resolution attempts, standard Microsoft DNS-Based domain discovery, and general subdomain queries. These requests originated from a wide range of IPs all tied to SoftLayer infrastructure (e.g., ASN36351).
Passive DNS monitoring in action.
Observation Details
What we observed wasn’t just benign DNS chatter. These were internal machines trying to communicate with each other over the public internet:
Some of the hostnames being queried resolved to externally accessible systems, including Windows servers with RDP exposed to the internet on a non-standard port 😉.
To go a step further, we crafted and served a wpad.dat file. The file did not proxy any traffic or alter user routing, but instead used a DNS-based exfiltration method to leak the internal client IP addresses and hostnames visited by the client.
WPAD IP leakage exploit.
One particularly interesting set of DNS queries involved a system attempting to reach a WSUS host named wsusdal1001.service.softlayer.com.
Leaking internal hostnames.
What’s more concerning is that this internal hostname leaked its internal IP address to the internet due to a separate DNS misconfiguration.
We also observed systems attempting to reach internal Ansible servers using our controlled domain: ansible1.softlayer-internal-acs-support.cloud, ansible2.softlayer-internal-acs-support.cloud, and ansible3.softlayer-internal-acs-support.cloud.
At this point, with control of the domain and visibility/control over hostname resolution and proxy requests, it would have been technically possible to:
Redirect legitimate traffic
Steal NTLM hashes
Impersonate internal services
Potentially achieve remote code execution through credential relay
Of course, we didn’t go down that path. But it’s clear the attack surface was very real.
Disclosure and response
We disclosed our findings to IBM PSIRT in May 2024, offering to transfer the domain and share our data. IBM promptly acknowledged our report, confirmed the issue was under investigation, and responded professionally throughout the process.
Within days, they formally requested ownership of the softlayer-internal-acs-support.cloud domain. We transferred it to them at no cost… that said we do expect a latte ($3.98) from them at some point. 😉
IBM later confirmed that the root cause had been identified and addressed on IBM-managed systems and that impacted customers had been notified. No additional technical details or remediation guidance were shared with us, and no public advisory was issued at the time.
We were, however, acknowledged on IBM’s Product Security Recognition page for our contribution.
Wait… there’s more…
A few months later, we ran a second wave of scans using improved tooling. This time, we scanned IP ranges belonging to IBM SoftLayer, looking for exposed TLS services, SMTP banners, and NTLM authentication headers that referenced .cloud FQDNs which were not registered.
We found 634 IPs leaking 135 unregistered .cloud domains.
All of these domains followed the pattern <hostname>.<SoftLayer_Account_Name>.cloud, suggesting they were automatically generated, likely based on internal project names or customer account identifiers set through IBM Cloud provisioning systems.
We registered a handful of these domains and confirmed they exhibited the same behavior we had previously observed with softlayer-internal-acs-support.cloud. But this time, the affected systems belonged to IBM Cloud customers, not IBM’s own infrastructure.
We reached back out to IBM in October 2024 with our new findings. IBM confirmed that the root cause had been addressed and that impacted customers had been notified. At that point, the responsibility for remediation was in the customers’ hands.
Unfortunately, resolving this kind of issue isn’t always straightforward. For example, if the affected systems are tied to an Active Directory domain using an internal .cloud FQDN, renaming the domain post-deployment is not possible.
To this day, we continue to observe DNS queries and WPAD traffic targeting several of the domains we registered. This suggests the issue remains partially unresolved across customer environments.
Speculating on the root cause
While IBM did not share many technical details with us, the likely root cause, based on our observation, appears to be tied to how internal hostnames were automatically deployed within IBM Cloud / SoftLayer environments.
Specifically, provisioning systems seemed to assign internal FQDNs using a format like <host>.<SoftLayer_Account_Name>.cloud, without verifying whether the resulting domain name was actually registered or reserved in the public DNS.
This likely stemmed from several misaligned assumptions or practices:
Assuming that .cloud was safe to use as an internal-only suffix, similar to .internal, even though .cloud is a valid, delegated top-level domain.
Using automation or provisioning templates that embedded these unregistered FQDNs into internal systems and services, including Active Directory and DNS suffixes.
The result was predictable: internal systems relying on DNS resolution for core functionality ended up leaking queries, trusting unowned domains, and potentially exposing sensitive data or credentials.
TL;DR
This class of vulnerability is not unique to IBM. Brian Krebs covered another domain name collision case we uncovered in 2024 involving local governments (Krebs on Security). The broader takeaway is that domain collisions involving valid public TLDs are a systemic and persistent issue, especially as infrastructure becomes increasingly automated and cloud-integrated.
While this research started as a curiosity, it uncovered a meaningful risk pattern that could impact many organizations, including those outside our client base.
We reported the issue, collaborated with the affected vendor, and continued to monitor similar risks across other infrastructure.
We’re not sharing this case study to assign blame, IBM PSIRT was great to work with. Instead, we’re highlighting how easily public namespaces can be mistaken for private ones. It’s a small misstep, but one that can quietly open the door to data leaks, credential theft, and service impersonation if left unchecked.
Timeline of key events
May 14, 2024 – Initial disclosure sent to IBM PSIRT
May 15–17, 2024 – Ongoing communication with IBM; confirmation of issue, offered to transfer domain
May 31, 2024 – Seralys transferred domain ownership to IBM
June 3–7, 2024 – IBM confirmed root cause remediation and acknowledgment on their security page
