The Cost of Expiration

Generally, at a stratospheric level, the people who need to know a domain has expired are the people responsible for managing the domain.

Let's dig into some consequences of a domain becoming available to buy, i.e. expired.

We're looking at a few things here, the first one is in the context of Application Security, under the guise of dependencies being hosted on an external domain, in appsec threat modeling you should be covering questions like 'what are our 3rd party dependencies and what does it mean if we cant depend on them ?' there are some quick wins here for attackers, if you rely on trustmebro.com/coolthing.js and it has a new owner that wants to use your browser to mine things, or actually push a beef.js (homage) in the place of cloolthing.js then all parties involved in pulling that resource are going to have a bad time.

The second view is in the context of Infrastructure, thematically with the same path to consequence that is 'Mal-inheritence' this one is closer to domain relationships and trusts, from AD/AAD to allow-lists, so on and so-fourth the consequence is still the same, there was a trust under the assumption that the owning body of the (trusted) domain was what it now isn't, and that comes at a cost of sending data to places you shouldn't, and having a assumed trust, Orgs if they have the time should absolutely revisit trusted domains on a program level and on an org wide level, those trusts should be time-boxed and revised.

The third view is similar but on a more focused level, this is identity related, my original stirrings of 'Mal-inheritance' began with the twitter leak in 2022 https://thecontractor.io/malinheritance/ and the focus translates well, if an organization's JML process isn't locked in then they're aligning an attack path that consists of two failings, one within their gift and another out of their control, first one obviously is leaving dormant accounts available on infrastructure, the second part is the domains to those accounts become available [email protected] is no longer contracting, domain expires, evil Steve buys the domain (because he's allowed too) and creates the bob email address, explores what access might be available either with focus (and some intelligence/osint) or blindly with inference, asking for password resets where ever he see's fit. - rebuilding account access, from an expired domain, inheriting trusts.

Lastly with the same optic, but a different view running this process over your customer database to see what customers have expired domains, and reacting to that, that's a great layer of added value.

I don't think this could be a dedicated service offering but it could be something integrated with partners who do DNS security or are conscious of DNS related risks (they might also enjoy the intelligence provided that is given to them from customers of such a service ;)

Here's what I managed to put together - it's not great but you get the idea

Domain Owners

• Concerns: Loss of ownership/control, service disruption, potential security risks (such as domain hijacking or phishing).
• Actions: Promptly renew the domain or coordinate with relevant teams for a recovery plan if renewal isn’t possible.
• Responsibilities: Notify internal stakeholders (security, infrastructure, identity management) and relevant customers of the domain expiration and any service impacts.

2. Application Security Teams

• Concerns: Risk of untrusted resources, potential vulnerabilities if expired domain is repurposed by third parties.
• Actions: Identify and disable trust relationships with the expired domain, especially in security policies or access controls.
• Responsibilities: Alert dependent systems and services about the change in the domain’s status to prevent untrusted interactions.

3. Infrastructure Teams

• Concerns: Dependence on the domain for DNS resolution, SSL certificates, and network trust policies.
• Actions: Reconfigure infrastructure components (e.g., load balancers, firewalls) that rely on the domain, and update or remove certificates or dependencies.
• Responsibilities: Communicate domain changes to other technical teams and ensure that infrastructure no longer depends on the expired domain.

4. Identity Management

• Concerns: Email services and authentication mechanisms tied to the domain may fail, affecting users who rely on domain-linked identities.
• Actions: Update identity records and authentication settings, and inform users with affected email addresses.
• Responsibilities: Ensure continuity for identity services and secure authentication methods independent of the expired domain.

5. Customer Support Teams

• Concerns: Customer accounts or services dependent on the domain for communication or access may be disrupted.
• Actions: Notify customers about potential email or account access issues if their accounts are tied to the domain.
• Responsibilities: Provide alternative communication channels or account management solutions to maintain customer trust and minimize service disruptions.

6. Customers/Users with Domain-Linked Emails

• Concerns: Loss of access or communication due to domain expiration affecting associated email accounts.
• Actions: Seek guidance from customer support on securing their accounts and migrating to an alternative email if necessary.
• Responsibilities: Update personal and professional contacts with new contact information if needed.

If you want to play along with my questionable code, the requirements.txt the python and the front end are in the zip

uvicorn splinter2b:app --reload will get you running on a localhost.

Other Reading material:

https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/

Identity Inheritance via expired domains

I wonder if any of these leaked email address domains are expired, and I wonder if I can buy them and inherit the identities associated with them via password resets

The Contractor 🏴‍☠️🧯John Carroll