Yacin Nadji, Georgia Institute of Technology
Any individual that re-registers an expired domain implicitly inherits the residual trust associated with the domain’s prior use. We find that adversaries can, and do, use malicious re- registration to exploit domain ownership changes—undermining the security of both users and systems. In fact, we find that many seemingly disparate security problems share a root cause in residual domain trust abuse. With this study we shed light on the seemingly unnoticed problem of residual domain trust by measuring the scope and growth of this abuse over the past six years. During this time, we identified 27,758 domains from public blacklists and 238,279 domains resolved by malware that expired and then were maliciously re-registered. To help address this problem, we propose a technical remedy and discuss several policy remedies. For the former, we develop Alembic, a lightweight algorithm that uses only passive observations from the Domain Name System (DNS) to flag potential domain ownership changes. We identify several instances of residual trust abuse using this algorithm, including an expired APT domain that could be used to revive existing infections.
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
BlueHat v17 || 28 Registrations Later: Measuring the Exploitation of Residual Trust in Domains
1. Domain-Z: 28 Registrations Later
Measuring the Exploitation of Residual Trust In Domains
Chaz Lever*, Robert Walls†, Yacin Nadji*,
Dave Dagon*, Patrick McDaniel†, Manos Antonakakis*
Georgia Institute of Technology*
Pennsylvania State University†
Chaz Lever
2. Residual Trust
▪ Definition
• The historical reputation of a domain that is implicitly
transferred with changes in ownership.
▪ Positive Residual Trust
• Results from a change of ownership for a domain with
positive historical reputation.
▪ Negative Residual Trust
• Results from a change of ownership for a domain with
negative historical reputation.
3. Expired Nameserver Domains
▪ What happened?
• A secondary nameserver used by Benedictine University
expired.
▪ What’s the big deal?
• It was re-registered by an SEO company that wildcarded
the MX record causing mail to be sent to them.
4. Expired E-mail Domains
▪ What happened?
• Expired domains used as the e-mail point-of-contact (PoC)
information associated with Regional Internet Registries
(RIR).
• E-mail was used as a trust anchor for the RIR login portal
to the administration interface.
▪ What’s the big deal?
• Registering one of the expired domains allows the
purchaser of the expired domain to request a password
reset from the RIR!
5. Expired Browser-Related Domains
▪ What happened?
• Analyzed approximately 41K plugins (many with different
versions) from the Mozilla store and found about 2.9K
unique domains for all analyzed plugins from the store.
• Almost 5% (159) of those domains were expired and
available for immediate registration and some had 10K+
installs.
▪ What’s the big deal?
• Anyone that re-registers the domain now has the
potential to take over developer account to hijack
current installs.
6. Expired OSS Domains
▪ What happened?
• A third party was operating a popular, unofficial Debian
repository of multimedia applications.
• Per request of Debian distribution maintainers, the site
owner changed the name.
• It was subsequently re-registered by a third party unknown
to the Debian community.
▪ What’s the big deal?
• Purchaser could have used domain to push
updates for system packages including the kernel
or base system.
7. Where’s the data?
▪ Expired Domains (DG)
• Expired domains spanning from November 2008 to July
2015
• Contains 179,326,265 unique domains
▪ Malware Domains (DM)
• Domains contacted by malware from early 2009 and July
2015
• Contains 6,112,964 unique domains
▪ Blacklist Domains (DB)
• Domains from multiple public blacklists collected
from December 2009 through through July 2015
• Contains 320,009 unique domains
9. By The Numbers
▪ Abused Before Expiration
• 123,396 total abusive domains
• 54,215 (43.9%) associated with malware communication
• 73,564 (59.6%) appeared on public blacklists
▪ Abused After Expiration
• 263,847 total abusive domains
• 238,279 (90.3%) associated with malware communication
• 27,758 (10.5%) appeared on public blacklists
12. What Is Alembic?
▪ Alembic is a fast, lightweight algorithm to help locate
potential domain ownership changes using only DNS.
▪ Alembic is not a fully automated detector for domain
ownership change events.
▪ Alembic only relies on several DNS components to
compute a single change of ownership score.
▪ Alembic does not rely on expensive WHOIS lookups
to help locate potential ownership changes.
13. How Does Alembic Work?
▪ Infrastructure Changes
• Measure the changes in hosts a domain points two
between different temporal windows.
▪ Lookup Volume Distribution Changes
• Analyze the different in lookup distributions between
different temporal windows.
▪ Start of Authority (SOA) Changes
• Measure the changes to RNAME and MNAME
fields between different temporal windows.
16. Alembic Discoveries
▪ Buying “Whitewashed” Domains
• Example of positive residual trust being leveraged for
abuse.
• Observed several domains involved involved in malware
communication after change of ownership event.
▪ APT Leftovers
• Discovered domain previously registered by PLA Unit
61486 (a.k.a., Putter Panda).
• We reanimated the domain and started receiving
connection attempts to our sinkhole.
17. Brief Summary
▪ Residual trust in domains is the underlying cause of a
number of different problems.
▪ In a study of expired domain abuse dating back to 2008,
we observed a trend of increasing residual trust abuse.
▪ We propose a lightweight algorithm to help identify
potential domain ownership changes using only DNS.
▪ Need better policies to help address this probem.
19. Policy Considerations
▪ Provide restricted zones for critical domains
• What is the criteria for a critical domain?
• How do we identify existing critical domains?
• Who is responsible for managing these zones?
▪ Registrars or registries manage critical domains
• What is the criteria for a critical domain?
• How are domains reported to registrar/registry?
• Would registrars/registries be willing participants?
▪ Dealing with non-critical domains
• Can we augment with technical solutions?