Skip to main content
Forgotten assets are among the most exploitable findings in any external attack surface assessment. They’re unpatched, unloved, and unmonitored — and because no one is paying attention to them, they often remain exposed for years after the project, campaign, or product they supported was retired. An attacker who discovers an orphaned subdomain pointing to an unclaimed cloud resource, or a staging environment running software from three major versions ago, has found an ideal entry point: one with no one watching the door. This guide shows you how to safely identify, validate, and remove forgotten assets so they stop appearing in your attack surface.

​
Types of Assets to Decommission

Before you begin the decommissioning checklist, it helps to understand the categories of forgotten assets most commonly surfaced in external attack surface assessments. Recognizing the pattern makes it faster to track down the right owner and confirm the asset is truly unused.
Orphaned subdomains are DNS records that were created to support a specific service or project and were never cleaned up after the project ended. They typically point to a cloud resource (an S3 bucket, an Azure App Service slot, a Heroku app, a GitHub Pages site) that has since been deleted or allowed to lapse. The DNS record still exists and still resolves — but the resource it points to is either gone or owned by someone else. This creates the conditions for a subdomain takeover attack. Common examples include staging.yourdomain.com, old-blog.yourdomain.com, cdn2.yourdomain.com, or app-v1.yourdomain.com.
Marketing teams register domains for product launches, campaigns, and microsites. Acquisition activity adds domains from the acquired company’s portfolio. Both are frequently forgotten. A domain registered five years ago for a product that was discontinued still appears in your digital footprint — and if it’s not actively maintained, it may be expired, running outdated software, or pointing to infrastructure you no longer control. In acquisition scenarios, the acquired company’s domains often have entirely separate DNS configurations, hosting providers, and security postures that were never integrated into your standard practices.
Development, staging, and QA environments are built for internal use — but they frequently end up internet-accessible because it’s convenient for remote developers, agency partners, or QA contractors to reach them without a VPN. These environments almost always run older software versions, use default or weak credentials, contain real customer data copied from production for testing purposes, and are never covered by your production security review process. They represent a nearly perfect combination of accessibility and unpreparedness.
Cloud infrastructure is trivial to spin up and easy to forget. A developer spins up an EC2 instance to test something, an engineer creates a storage bucket for a one-time data transfer, a team deploys a Kubernetes cluster for a proof of concept — and then the project ends, the team moves on, and no one decommissions the resource. These forgotten cloud resources accumulate over time and create an ever-expanding attack surface. They may contain sensitive data, expose internal services, or simply provide an attacker with a foothold inside your cloud environment.

​
Decommissioning Checklist

Work through each step in order. Skipping steps — especially step one — is the most common cause of accidentally removing an asset that is still in active use.
1

Confirm the asset is truly unused

Before you delete anything, verify the asset is not serving active traffic. Check with the team that originally owned the project or service — someone may still be using it even if it’s not officially supported. Pull DNS query logs if available in your DNS provider to check for recent resolution activity. Check web server access logs for traffic in the past 30 to 60 days. For cloud resources, check the platform’s usage metrics and billing data. An asset that is completely unused will show no recent activity across any of these sources. If you find active traffic, escalate to the owning team before proceeding.
2

Remove or update DNS records

Once you’ve confirmed the asset is unused, remove the DNS records that expose it. For an orphaned subdomain, delete the CNAME, A, or AAAA record from your DNS provider. For a legacy domain, update the nameservers to a parking configuration or let the domain lapse after confirming there are no active services or email flows depending on it. Removing the DNS record eliminates the finding at the attack surface level even if the backing resource takes longer to fully decommission — an attacker cannot reach a resource they cannot resolve.
3

Terminate or secure the backing resource

DNS removal addresses the exposure, but the backing resource still exists until you explicitly terminate it. Decommission the cloud instance, delete the storage bucket, remove the hosting account, or disable the application. If the resource is a cloud storage bucket, verify all objects are deleted or transferred before deleting the bucket — an empty bucket in some providers can still be claimed if the name is predictable. Follow your cloud provider’s standard decommissioning process and confirm the resource no longer exists after deletion.
4

Revoke associated credentials and API keys

Every asset has credentials associated with it — cloud IAM roles, API keys, service account tokens, TLS certificates, SSH keys, and deployment credentials. Revoke all of them as part of decommissioning. A deleted instance with a still-valid SSH key is a smaller but real risk. An S3 bucket that’s gone but whose access key is still valid elsewhere is a risk that will outlive the bucket. Use your cloud provider’s IAM console, secrets manager, and certificate manager to audit and revoke every credential that was scoped to the decommissioned asset.
5

Document the decommissioning

Record what was removed, when it was removed, and who performed the decommissioning. Include the Leverage Cyber finding ID if the decommissioning is in response to a specific finding. This documentation serves two purposes: it provides an audit trail for compliance and incident response purposes, and it gives future team members context if questions arise about why a particular DNS record or cloud resource no longer exists. Store the documentation in your standard IT or security runbook location.
6

Notify Leverage Cyber

After DNS records are removed and backing resources are terminated, the finding will be verified and closed at the next Leverage Cyber monitoring cycle. You do not need to take any manual action in the platform — passive re-assessment will confirm the asset is no longer reachable and update the finding status automatically. If you need the finding closed before the next cycle for reporting or compliance purposes, use the “Mark as Remediated” action in the finding detail view to trigger an expedited verification check.

​
Subdomain Takeover Prevention

Subdomain takeover is a particularly dangerous class of finding that deserves dedicated attention. It occurs when a CNAME record in your DNS points to a third-party service (an S3 bucket, an Azure App Service slot, a Heroku app, a GitHub Pages site, or any other cloud-hosted resource) that has been deleted or allowed to lapse — but the CNAME record still exists and still resolves. An attacker can claim the now-unclaimed resource, publish content under your subdomain, and use it to steal cookies, phish your users, or bypass Content Security Policies that trust your domain. To check whether a subdomain is vulnerable to takeover, examine where its CNAME points and whether that destination still returns a valid response from its expected owner:
If the CNAME resolves to an AWS, Azure, GCP, Heroku, GitHub Pages, or other cloud-hosted hostname, immediately test whether the resource at that destination is claimed:
If you observe any of these responses, remove the CNAME record from your DNS immediately — do not wait to decommission the backing resource first. Eliminating the DNS record closes the takeover opportunity even before the full decommissioning process is complete.
Subdomain takeover vulnerabilities are actively scanned for and exploited by automated tools. If Leverage Cyber surfaces a subdomain takeover finding, treat it as a P1 — the DNS record must be removed the same day the finding is identified. The window between a resource being deleted and an attacker claiming it can be measured in hours.

​
When You Can’t Fully Decommission

In some cases, an asset that should be retired can’t be immediately removed — a legacy system may still be in use by a small number of customers on a long-term contract, an internal tool may be waiting on a migration that has slipped, or an acquisition integration may be taking longer than planned. When full decommissioning isn’t immediately possible, apply these mitigations to reduce the attack surface until removal is complete.
If the asset is currently publicly accessible without authentication, add authentication immediately. Even basic authentication significantly raises the cost of exploitation for an opportunistic attacker. For web applications, enable SSO through your identity provider and require your organization’s standard MFA. For development and staging environments, add HTTP basic authentication or IP-restricted access as a minimum control while the migration proceeds.
When you apply mitigations rather than full decommissioning, document the residual risk and set a hard decommissioning deadline. Without a deadline, mitigated assets have a way of staying in the “temporary” state indefinitely. Mark the finding in Leverage Cyber with the expected decommissioning date and escalate to the asset owner if that date passes without action.
Schedule a quarterly review of all subdomains and cloud assets — separate from, and in addition to, Leverage Cyber’s quarterly reassessment cycle. Export your full DNS zone file and run it against your known active services inventory. Export your cloud asset inventory and filter for resources with public IP addresses or public DNS names that are not in your authorized asset registry. New orphans accumulate faster than most organizations expect, and catching them early — before they become findings in an assessment or before an attacker discovers them first — is far less disruptive than responding to them as incidents.