Research note
What happens when stale trust outlives the cloud address it was meant for?
In the same way that replacing your phone number can result in someone else receiving calls meant for you on the old number, releasing ephemeral cloud addresses without updating stale DNS records can cause traffic intended for your services to be sent to the wrong place, with disastrous consequences.
While working on the home-brewed collaborator we use for pentests and red teaming, we noticed something odd: whenever its ephemeral addresses were rotated, we would often receive unexpected requests. Most of these looked like background noise from dangling DNS records that still pointed to the newly assigned address, but every now and then we also saw a short burst of live traffic that was intended for somewhere else.
As is often the case, digging into the details showed that this was not a new problem. Several existing papers had already covered related issues, although they do not seem to have received the attention they deserved when they were released.
We chose the name “afterlife” because even after an address has been disassociated from its original resource, its security impact can continue. Stale DNS records, allowlists, callbacks, or validation paths may still point to that address, so if it is later reallocated, the new holder can inherit trust that was meant for the previous owner.
In short, the address is gone from the original system, but its security consequences live on in an afterlife.
Issue no.1
The root cause of this issue is that a DNS record was configured to point to an ephemeral address, which was then released without the DNS record also being updated. This means that if the address is later allocated to another organisation, then any traffic meant for it is sent to the wrong place.
From the research, these appear to be mostly the result of an incomplete teardown of an environment, where someone has deleted an entire resource group, but left the DNS records pointing either directly at the ephemeral pool, or indirectly via services like CloudFlare.
If an attacker is later allocated the released ephemeral address, the dangling DNS record can turn into a full domain-level compromise primitive. The attacker can serve content from a victim-owned hostname, receive traffic intended for the legitimate service, and potentially issue trusted TLS certificates for that hostname using HTTP-based validation.
In practice, this can expose cookies, bearer tokens, API keys, session identifiers, request bodies, webhook payloads, and other sensitive data sent to the old endpoint. The impact can also extend beyond simple traffic interception, because many systems still make security decisions based on same-site or domain-level trust, including cookie scope, cache partitioning, CORS allowlists, OAuth/SAML redirects, and domain-based access controls.
At the organisational level, the risk includes phishing, malware hosting, or attacker-controlled pages served under a trusted domain, as well as privacy and compliance concerns where personal data, tracking identifiers, or regulated data is sent to the reallocated address.
Issue no.2
This issue is mostly caused by delays in the DNS records propagating. A record may be updated correctly when a service is moved, recreated, or assigned a new address, but dependent systems can continue using the previous answer until their cache expires. This means that if the old ephemeral address is released and then allocated to another organisation during that window, some traffic intended for the legitimate service may still be sent to the wrong place.
From the analysis, these appear to be mostly the result of normal infrastructure churn rather than fully abandoned records. For example, an environment may recycle a node within a cluster, and update the DNS record to match, but cached DNS answers and dependent systems can continue to reference the previous ephemeral address until their state expires.
The impact is similar to the persistent case, but the shape of the risk is slightly different. Issuing a trusted TLS certificate is still theoretically possible, but appears less likely in practice, because HTTP-based validation generally requires the stale DNS state to be visible to the certificate authority, not just to a dependent system.
The more immediate concern is that these are often live services in the middle of a change, so the traffic is more likely to be current and useful. If an attacker receives it, it is probable they will see active cookies, bearer tokens, API keys, session identifiers, request bodies, webhook payloads, OAuth/SAML flows, or other sensitive data intended for the legitimate endpoint.
Avoid pointing long-lived DNS records directly at ephemeral cloud IP addresses, especially for hostnames that receive sensitive traffic. Use stable endpoints instead, such as load balancers, reserved addresses, or provider-managed names. If an ephemeral address has to be used, make sure the DNS record has a clear owner and is removed before the address is released.
Make DNS cleanup part of the teardown process. When deleting a resource group, cluster, node, tunnel, temporary environment, or load balancer, immediately remove or update any related DNS records, CDN entries, callbacks, webhooks, OAuth/SAML redirects, and allowlist rules.
For planned migrations or address rotations, reduce the stale window. Lower DNS TTLs before the change, keep the old endpoint alive until important clients and resolvers have aged out their cached answers, and avoid releasing the old address immediately after updating DNS.
Before deallocating an address, confirm that it is no longer receiving meaningful traffic. Monitor passive DNS, resolver behaviour, application logs, and network traffic to check that clients have stopped resolving or connecting to the old address.
Monitor for stale records across your domains. Regularly resolve owned hostnames and check that the resulting addresses still belong to the expected account, service, or resource. Treat records pointing to released, unowned, or unexpected infrastructure as security issues.
Use CAA records where practical to restrict which certificate authorities can issue TLS certificates for your domains, and monitor Certificate Transparency logs for unexpected certificates. This does not fix stale DNS, but it can reduce or detect some certificate abuse paths.
Where cloud providers support it, use controls that reduce immediate reuse of released resources, such as reserved addresses, deletion protection, or cooldown periods before an address is returned to the pool.