Product1 distinct publisher3 min readUpdated
Astrolavos Lab counted 27,758 blacklisted and 238,279 malware-resolved domains that expired and were then maliciously re-registered, including an expired APT name.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Astrolavos Lab, in a study titled "28 Registrations Later: Measuring the Exploitation of Residual Trust in Domains," measured six years of expired-domain turnover and identified 27,758 domains from public blacklists and 238,279 domains resolved by malware that expired and were then maliciously re-registered [10][4][5][6]. The reason this matters more than a fresh-registration statistic: whoever re-registers an expired name implicitly inherits the residual trust attached to its prior use [1], and the researchers report that adversaries can and do exploit those ownership changes to undermine the security of users and systems [2].
The two counts sum to 266,037 domains over the measurement window, an average of roughly 44,340 per year if you spread them evenly [11][13]. The malware-resolved figure outnumbers the blacklisted one by about 8.6 to 1 [12], and it is the number operators should read twice. A blacklisted domain carries reputational baggage that a re-registrant has to work around. A domain that malware resolves carries an installed base: hosts that will keep calling out to it on schedule regardless of who now answers. Acquiring one is not buying a name, it is acquiring a callback list you did not have to build. The paper's sharpest single instance is exactly that case, an expired APT domain that, by the researchers' account, could be used to revive existing infections [8].
The lab's framing is that a set of security problems that look unrelated in a ticket queue share one root cause in residual domain trust abuse [3], and that the problem had gone largely unnoticed [14]. Their proposed technical remedy is Alembic, described as a lightweight algorithm that uses only passive DNS observations to flag potential domain ownership changes [7]; they used it to surface several instances of abuse, including the APT case [8]. They also discuss policy remedies alongside the technical one [9].
Two honest limits. The study measures inherited trust, not price, and does not compare what a re-registered domain costs an attacker against a newly registered one [1][2]. And the counts are historical, covering the six years before the work was published [4], so treat them as evidence that the mechanism works at scale rather than as this quarter's volume.
The operational read is unglamorous. Most organisations have a list of names that are load-bearing and unowned: a marketing domain from a campaign that ended, an SPF include for a vendor that got acquired, a hardcoded update or telemetry host in a shipped device, an old corporate domain kept alive only by an MX record. Expiry converts each of those into an asset someone else can buy. The trust does not lapse with the registration, which is the whole point of the finding [1].
What to watch: whether your reputation and allowlist tooling treats a detected ownership change as a reset of history, or keeps scoring the new registrant on the old owner's record [1]; whether passive-DNS ownership-change signals of the kind Alembic produces show up in the feeds you already pay for [7]; and whether registries and registrars move on any of the policy remedies the paper raises rather than the technical one alone [9]. In the meantime, an inventory of every domain your systems trust but do not renew is a cheap piece of work with a known failure mode attached [5][6].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The study finds that many seemingly disparate security problems share a root cause in residual domain trust abuse.
The researchers identified 27,758 domains from public blacklists that expired and were then maliciously re-registered.
The researchers identified 238,279 domains resolved by malware that expired and were then maliciously re-registered.
The authors developed Alembic, described as a lightweight algorithm that uses only passive observations from the Domain Name System to flag potential domain ownership changes.
Using the algorithm, the authors identified several instances of residual trust abuse, including an expired APT domain that could be used to revive existing infections.
The authors propose a technical remedy and discuss several policy remedies.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Quantified but single-source and author-reported
The core numbers are specific and internally consistent, and the derived total and ratio follow directly from them. But everything rests on one self-published abstract with no methodology, dataset description, overlap handling, or Alembic accuracy figures, and no second publisher in the cluster corroborates any figure. That supports the direction of the finding more firmly than its precision.
Attacker-side scale documented, defender uptake unevidenced
Adoption evidence is asymmetric. On the attacker side the study documents re-registration of hundreds of thousands of expired domains, which is real-world usage at scale. On the defender side there is nothing: no reported deployment of Alembic, no registrar or registry policy change, no third-party integration, and no named organization acting on the findings. The score reflects the documented exploitation with no offsetting evidence of remediation uptake.
Mildly overstated novelty, sound underlying numbers
The counts and the APT example are concrete and modestly framed, so the quantitative core is not inflated. The overhang comes from framing: calling residual domain trust a seemingly unnoticed problem and a shared root cause of many disparate security issues is a broad claim carried entirely by the authors' own abstract, and the cluster headline sharpens it further. No source in the cluster contradicts the framing, which is why the gap is small rather than large.
Author-published study promoting its own tool and framing
The single source is the research lab's own announcement of its own study, so it benefits from emphasizing the problem's novelty and the value of the algorithm it built. That is a normal academic-visibility incentive rather than a commercial one: no pricing, product, funding round, or customer relationship appears in the supplied material, and no vendor is positioned to sell a remedy here.
Plausible mechanism, weak corroboration and unclear dating
The mechanism is straightforward and the figures are stated precisely, which supports moderate confidence in the substance. Confidence is held down by three things: a single publisher with no independent check, abstract-level detail that omits methodology and detection performance, and a date conflict between the 2016 URL path and the 2026 ingest timestamp that leaves the recency of the measurement window unresolved.
build
Two browsers, one laptop, two answers: identify the resolver before blaming the VPN1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.