When Retired Domains Come Back to Haunt: The Hidden Risk of Legacy Corporate Assets
Summary for readers: Organizations evolve through mergers, acquisitions, and rebranding. Old domains get retired, but what happens when those domains can still receive password resets or act as the login email for third-party services for the previous owner? This post reveals an overlooked vulnerability we've seen through Defend Iceland's bug bounty platform: expired corporate domains that remain deeply embedded in third-party SaaS accounts. When these domains become available for registration, attackers can inherit access to SaaS accounts that still use the retired email domain for login or recovery. We'll show you exactly how this happens and why "just let it expire" is a dangerous domain retirement strategy.
The Legacy Domain Problem
Here's a scenario: Company A acquires Company B. They migrate the email infrastructure, update the website, and rebrand everything under Company A's domain. Company B's old domain name is retired, left to expire and not renewed, and everyone assumes that chapter is closed.
What many fail to account for is that dozens of Company B employees had signed up for third-party services using their old @companyb.is email addresses. Those project management tools, CI/CD platforms, vendor portals, documentation sites, and countless other Software-as-a-Service (SaaS) platforms? They're all still there, waiting for someone to claim the expired domain and potentially take control.
Through Defend Iceland's bug bounty platform, we've seen this pattern emerge as an overlooked attack vector in organizational security. The vulnerability isn't in your code or your infrastructure. It's in the assumption that an expired domain is a dead domain. In reality, it can become a skeleton key that can unlock years of access across countless SaaS accounts.
How Domain Expiry Becomes an Attack Vector
When a domain expires and returns to the registration pool, it doesn't just disappear. It becomes available for anyone to purchase. In Iceland, domains cycle back through ISNIC's registration system, where they can be claimed by anyone.
Here's what typically happens in these attacks:
- Discovery Phase: Attackers use OSINT techniques, DNS history lookups, and archived web pages to identify previously active corporate domains. They look for patterns that indicate old company names from mergers, acquisitions, or rebrands.
- Acquisition: The attacker registers the expired domain through ISNIC or other registrars.
- Email Configuration: They set up email forwarding or catch-all mailboxes to receive any messages sent to @expired-domain.is addresses.
- Service Enumeration: Using captured emails, mailing list notifications, and other DNS signals, they identify which services still reference the old domain.
- Account Takeover: They trigger password resets for discovered accounts, intercept the reset links, and gain access to the services.
The attacker now owns the domain and controls the email addresses. While the password reset flows work exactly as designed, the attacker is accessing data and accounts they have no right to touch.
The Technical Reality of Account Takeover
Let's break down exactly what an attacker can and can't do once they control an expired corporate domain:
Password-Based Accounts
Employee accounts on third-party SaaS that use email/password authentication become vulnerable. The attacker triggers a password reset, receives the link at the old domain they now control, and takes over the account. Where a service allows password reset by email link alone (no enforced second factor), compromise is typically immediate.
Single Sign-On (SSO) Considerations
SSO-protected accounts work differently. If an employee's account was federated through the company's active identity provider, the retired domain alone won't grant access. The existing SSO setup remains tied to the company's infrastructure, not the domain name itself.
However, some services have weak implementations. If a service routes authentication based solely on email domain without proper verification, or accepts any IdP claiming to own that domain, then an attacker might slip through. But this is the exception, not the rule. Most modern services require admin configuration and proper domain verification before trusting an IdP. Owning the retired domain later doesn't automatically unlock an existing SSO setup that was previously configured in the company's tenant.
What Security Researchers Have Found
Based on actual reports through Defend Iceland's platform, security researchers testing expired Icelandic corporate domains have discovered:
Email Activity: After configuring email forwarding, researchers observed various automated emails still being sent to the old domain. System alerts, mailing list messages, and service notifications revealed which platforms still had active connections.
SaaS Account Access: Researchers could reset passwords and access project tracking tools, CI/CD platforms, documentation sites, support desks, and vendor portals. In edge cases where a cloud provider root or admin login still used the retired email and lacked MFA, compromise was possible.
Collaboration Platform Exposure: Various collaboration and project management tools remained accessible through password resets, providing visibility into historical projects and internal discussions.
Supply Chain Connections: Vendor portals and B2B platforms where the old email domain still functioned as a valid credential for accessing partner systems.
Why Traditional Domain Retirement Falls Short
The standard approach to domain retirement is simple: stop renewing the domain, remove the DNS records, update the references you know about, and move on. This approach has gaps in today's SaaS-heavy environment.
Consider these challenges:
Shadow IT remains invisible: When employees independently sign up for services, there might be no central record. A developer's test environment or a project manager's client portal could exist outside official asset inventories.
Password resets bypass current controls: Modern controls at the acquiring company won't stop email-only resets for local accounts sent to the old, attacker-controlled domain.
Third parties don't track your organizational changes: External services continue treating user@old-domain.is as valid indefinitely, unaware of mergers or rebrands.
Moving Forward
This vulnerability exists at the intersection of identity management, domain ownership, and third-party services. It's not something that traditional security scans will catch, and it's easy to overlook during merger and acquisition planning.
For organizations that have retired domains previously used for employee email, the safest approach is often the simplest: keep the domain. The annual registration cost is minimal compared to the potential exposure. While you could technically audit all third-party services, monitor inbound emails (especially reset notices), and manually close every account, the complexity of that process and the risk of missing something makes domain retention the sensible choice for most organizations that have gone through rebrands, mergers, or acquisitions. Understanding which domains you've retired and who currently controls them is the first step in assessing your exposure.
About Defend Iceland
The vulnerabilities described in this post are based on findings reported through Defend Iceland's bug bounty platform. We're sharing these details to help organizations understand this vulnerability class and evaluate their own domain retirement practices. If your organization has retired domains that were once used for employee accounts, reviewing those decisions with this attack vector in mind could help identify and close potential security gaps.
Defend Iceland continues to work with security researchers and organizations to identify and responsibly disclose vulnerabilities. This collaborative approach helps strengthen the security posture of Iceland's digital infrastructure.
