I’ve spent the past two years working on incident response and threat intelligence, and the pattern I’m about to describe is one I keep seeing show up in cases that should have been caught at the email gateway. The kit families change. The lure templates change. The constant is that phishing-as-a-service operators are buying aged legitimate domains and redeploying them to steal credentials from enterprise and government targets.
The most recent incident I worked involved a Sneaky2FA deployment running on 117 origin servers in Kansas City, Missouri, split across two hosting providers. The operator has been on the same infrastructure for over two years and runs lures against a mix of UK and US government, energy companies and US healthcare SMBs. The aged-domain tradecraft I’m about to walk through is one way this operator stays inside enterprise environments that should be filtering them out. The certificate transparency logs tell the whole story, and they explain why the reputation classifier didn’t catch it.
How age-weighted reputation became the blind spot
Most enterprise mail filters from major vendors, including Microsoft Defender for Office 365, Proofpoint, Mimecast and Cisco Talos, factor domain age heavily into their classification decisions. A freshly registered .com triggers immediate reputation penalties. A domain with years of stable hosting, consistent certificate issuance and clean DNS history gets treated as low risk. The logic made sense ten years ago, when newly minted abuse domains dominated phishing infrastructure and aged domains usually meant established small businesses.
I work with several enterprise environments that pay for the most expensive tiers of email security and still see phishing lures land in users’ inboxes. When I trace those lures back to their parent domains, an increasing percentage show the same pattern. Long-stable cert history through some point in 2024 or 2025. A several-month gap with no new certs issued. Then certs start appearing again for subdomains that have nothing to do with the original brand. The reputation score on these domains is high. The infrastructure behind them is criminal. The filter doesn’t know the difference.
What aged-domain acquisition actually looks like
There are two reasonable ways for an operator to acquire an aged domain. They can drop-catch an expired registration, or they can hijack an active one through credential theft against the owner’s registrar account. Drop-catching is cheaper and lower-risk. Services like DropCatch, SnapNames and GoDaddy Auctions exist precisely to acquire domains the moment they expire, and a determined operator can pay $50 to $500 for a domain with a decade of clean history.
The domain I want to walk through is one I documented in detail during the Sneaky2FA case: digitalscrapbookingfreebies.com. The certificate transparency record shows the takeover in full. From 2016 through July 2025, the cert history reads like a normal small-business cPanel-hosted blog. cPanel Inc. issued ECC certs every 60 to 90 days for the standard cpanel., mail., webdisk. and webmail. subdomains. Let’s Encrypt R3 issued certs for the apex and www. every 90 days. The subjects stayed stable across nine years. Someone was running a hobby blog providing free scrapbooking assets to a small audience, and the cert pattern reflects that.
In April 2025, GoDaddy certs appear in the record. A new certificate authority showing up after eight uninterrupted years of cPanel-plus-Let’s-Encrypt is the first hard signal that something changed at the registrar or hosting level. By July 2025, the last legitimate-pattern cert will be issued. Then six months of silence, no new certs, no renewals. In December 2025, fresh Let’s Encrypt R13 certs surfaced for subdomains the original blog never had: beds, footboard, haushafin and locklear. By January 2026, another subdomain appeared: nativems-mfl09093004.digitalscrapbookingfreebies.com. That subdomain was the one I caught being actively used in phishing against a US state health agency.
The original owner of the scrapbooking blog is almost certainly a victim, too. They probably let the registration lapse, the operator drop-caught it and the domain entered criminal use under a privacy WHOIS that obscures the new ownership. Their nine years of reputation-building goodwill now serve as a credential-theft operation.
What made this case generalizable is that the same operator also runs a second-tier-2 lure domain acquired through fresh registration. The two strategies serve different targeting profiles. The operator uses fresh registrations when the subdomain itself can carry the credibility, like an SSO-themed subdomain mimicking a corporate authentication endpoint where the parent domain isn’t doing much work. The operator uses aged-domain acquisitions when the domain reputation itself has to do the work, when the lure is going through an enterprise mail filter that scores by age. The selection is contextual.
Why your reputation classifier won’t catch this
Reputation scoring assumes that domain history reflects domain ownership. When ownership transfers through drop-catch or hijack, that assumption breaks. The score doesn’t reset. The new operator inherits the trust without inheriting any of the work that built it. Most reputation systems also weigh the length of clean history more heavily than recent changes to ownership patterns, which makes the problem worse. A nine-year-old domain that changes hands quietly stays scored as a nine-year-old domain.
The signals that would actually catch the takeover (a CA issuer change, a six-month cert gap, a sudden wordlist of new subdomains that has nothing to do with the original brand) aren’t features in most age-weighted classifiers.
A better detection approach has to weigh hosting-pattern stability. A domain whose hosting infrastructure changes abruptly is more suspicious than a domain whose pattern continues uninterrupted, and the events you want to fire on are concrete: a new CA appearing after years of stable issuance, a gap in cert renewals followed by new issuance or a CDN change with no legitimate ownership reason. Most reputation systems don’t track any of this because the score is a single number rather than a stability metric.
Subdomain wordlist anomaly is the second axis. When a long-stable domain about scrapbooking suddenly issues certs for a subdomain named nativems-mfl09093004, the disconnect between the original brand and the new naming is detectable behaviorally, even when every other signal fails.
The third piece is certificate transparency monitoring. CT logs are public, queryable and updated within hours. I reconstructed the entire digitalscrapbookingfreebies.com takeover timeline from public CT data alone. No commercial threat feed was required. Security teams who subscribe to CT log feeds for their blocklist candidates can surface operator-deployed subdomains within hours of issuance, which is often well before they show up in any commercial threat feed.
If I were running enterprise email security tomorrow, the first thing I’d change is to stop treating domain age as a primary signal. Aged-domain acquisition is documented tradecraft now. Sekoia has surfaced it. Centripetal has surfaced it. My own research on this Sneaky2FA case adds another example. Any reputation system that weights age heavily has a known bypass, which means age should be one signal among several, not the dominant one.
The detection logic that does work is the one I described above: hosting-pattern stability, subdomain wordlist anomaly and CT log monitoring. A nine-year-old hobby blog suddenly hosting Microsoft-themed authentication pages is detectable behaviorally, even when domain age fails the analyst. Several CTI vendors are starting to surface this as a capability. Ask yours where they are on it and get a real answer, not a marketing one. CT log monitoring is cheap and surfaces operator infrastructure within hours of issuance, which is one of the higher leverage moves a small security team can make.
The operators figured out the blind spot. They’re going to keep buying aged domains for as long as those domains keep working. Closing the gap doesn’t take a new product line. It takes treating the signals we already collect with appropriate weight.
The full research from the Sneaky2FA case, including methodology, IOCs and the detection rules I wrote, is available on my GitHub.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?