Matt Thomas

PRINCIPAL ENGINEER.

Matt Thomas is a Principal Engineer in Verisign’s CSO Applied Research division. His research focuses on numerous aspects of internet security, stability and resiliency including but not limited to: DDoS attacks, domain name abuse, miscreant behavior within the DNS, and large-scale measurements and evolving trends in internet architectures.

Thomas is responsible for supporting an array of activities across the company that include data driven analytical functions for Verisign’s value-added services, supporting internal research initiatives, external engagement, and supporting critical data analysis efforts. Thomas has over 15 years of experience working with large distributed data collection and analysis systems.

Prior to joining Verisign in 2008, Matt worked as a Software Engineer at AT&T. He was responsible for designing and implementing a distributed data collection system that measured and analyzed the operational performance of systems and services hosted by AT&T throughout the world. Thomas received his Bachelor of Science in Computer Science and Master of Science in Information Systems and Technology from The Johns Hopkins University. He has authored more than 10 peer-reviewed publications and he has been awarded 11 patents from the USPTO. He is in good standing as a Certified Information Systems Security Professional (CISSP) and Certified Hadoop Developer (CDH).


Recent posts by Matt Thomas:

Revisiting How Registrants Can Reduce the Threat of Domain Hijacking

Recent events1,2 have shown the threat of domain hijacking is very real; however, it is also largely preventable. As Verisign previously noted3, there are many security controls that registrants can utilize to help strengthen their security posture. Verisign would like to reiterate this advice within the context of the recent domain hijacking reports.

Domains are an important element of internet infrastructure; their functionality and security rely upon many factors such as their delegated name servers. Name server delegations introduce complex and subtle inter-dependencies between domains and their authoritative name servers. Compromise of any name server in the delegation hierarchy can lead to a potential hijacking scenario. Targeted name server compromises in the delegation hierarchy can facilitate a complete hijack of a domain or set of domains, while name server compromises deeper in the delegation hierarchy may result in partial hijacking, since not all name servers in the hierarchy are involved in every DNS resolution request. A compromised name server is capable of diverting DNS requests to malicious servers controlled by threat actors and can be weaponized for phishing attacks or other nefarious purposes.

Over the past several weeks, security professionals have issued reports1, 2 about the hijacking of various domains via their name server delegations. These changes were likely made using compromised registrar credentials and are believed to be backed by a foreign nation state entity1, 2. During the attacks, the threat actors used the traffic directed to their infrastructure to launch spear phishing campaigns against various government entities in northern Africa and the Middle East. These targeted spear phishing attempts were facilitated by the transitive trust4 placed on the compromised domains and their delegated name servers.

Several of the compromised domains contained hosts that were specified as name servers for numerous top-level domains (TLDs) including country code TLDs5 in the northern African and Middle East regions. Subsequently, DNS traffic resolution for corresponding reliant zones were partially/completely routed to the threat actors’ infrastructure. This redirection of DNS traffic facilitated their ability to target specific government and industry entities in the targeted countries. While the domains did not employ a domain locking tool, some were DNSSEC6 signed, which helped mitigate the attack for resolving parties that perform validation.

As part of the response to this incident, the Department of Homeland Security issued Emergency Directive 19-017 requiring federal civilian agencies to address the risks presented by this activity. The order mandated four actions to be taken: 1) Audit DNS records, 2) Change DNS account passwords, 3) Add multi-factor authentication to DNS accounts and 4) Monitor Certificate Transparency logs.

Verisign is engaged with various industry and government entities regarding this incident and has provided technical insights into the DNS ecosystem regarding the complex mechanisms and system-to-system interactions/dependencies involved. To date, there is no evidence that the scope of compromise extends beyond the sets of credentials at various registrars.

Verisign encourages registrants to research their registrar’s security offerings and to take advantage of the tools and services they offer. Techniques such as locking services offered by registrars and registries8, two-factor authentication, password strengthening, and other common security hygiene practices9 are all best practice security recommendations that Verisign encourages and promotes.

Additional security recommendations are available in the following ICANN SSAC reports:

  • SAC04010: “Measures to Protect Domain Name Registration Service Against Exploitation or Misuse”
  • SAC04411: “A Registrant’s Guide to Protecting Domain Name Registration Accounts”
  • SAC07412: “Best Practices for Preserving Security and Stability in the Credential Management Lifecycle”

1 https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html

2 https://www.crowdstrike.com/blog/widespread-dns-hijacking-activity-targets-multiple-sectors/

3http://www.circleid.com/posts/20130722_how_registrants_can_reduce_the_threat_of_domain_hijacking/ 

4https://www.usenix.org/legacy/events/imc05/tech/full_papers/ramasubramanian/ramasubramanian_html/dns.html

5 https://www.internic.net/domain/root.zone

6 https://www.verisign.com/en_US/domain-names/dnssec/how-dnssec-works/index.xhtml

7 https://cyber.dhs.gov/ed/19-01/

8 https://www.verisign.com/en_US/channel-resources/domain-registry-products/registry-lock/index.xhtml

9https://www.markmonitor.com/download/checklist/MarkMonitor_Domain_Security_Best_Practices.pdf

10 https://www.icann.org/en/system/files/files/sac-040-en.pdf

11 https://www.icann.org/en/system/files/files/sac-044-en.pdf

12 https://www.icann.org/en/system/files/files/sac-074-en.pdf