{
	"id": "5b30fc91-b1a9-49bf-bd69-9d9daaa273ea",
	"created_at": "2026-04-06T02:11:48.317124Z",
	"updated_at": "2026-04-10T03:22:08.462845Z",
	"deleted_at": null,
	"sha1_hash": "d77dfb3322b5faf674576875c40cf0e52251b527",
	"title": "Domain Name Hijacking: Incidents, Threats, Risks and Remediation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 40351,
	"plain_text": "Domain Name Hijacking: Incidents, Threats, Risks and\r\nRemediation\r\nArchived: 2026-04-06 01:54:53 UTC\r\nDocument 007 Version 1\r\nExecutive Summary\r\nThis report by the Security and Stability Advisory Committee (SSAC) describes incidents where domain names\r\nwere \"hijacked\". Domain hijacking refers to the wrongful taking of control of a domain name from the rightful\r\nname holder. The common use of the term encompasses a number of attacks and incidents. Incidents\r\nrepresentative of common forms of attacks are discussed and analyzed in the report. The Committee then presents\r\nits findings and recommendations.\r\nAs the report illustrates, domain hijacking can have a lasting and material impact on a registrant. The registrant\r\nmay lose an established online identity and be exposed to extortion by name speculators. Domain hijacking can\r\ndisrupt or severely impact the business and operations of a registrant, including (but not limited to) denial and\r\ntheft of electronic mail services, unauthorized disclosure of information through phishing web sites and traffic\r\ninspection (eavesdropping), and damage to the registrant's reputation and brand through web site defacement. The\r\nreport further illustrates how incidents often affect more parties than the rightful name holder: customers, business\r\npartners, consumers of services provided by the name holder, and even parties wholly unrelated to the name\r\nholder are often \"collateral damage\" to hijacking incidents.\r\nThe Committee finds that domain name hijacking incidents are commonly the result of flaws in registration and\r\nrelated processes, failure to comply with the transfer policy, and poor administration of domain names by\r\nregistrars, resellers, and registrants.\r\nFinding (1) Failures by registrars and resellers to adhere to the transfer policy have contributed to hijacking\r\nincidents and thefts of domain names.\r\nFinding (2) Registrant identity verification used in a number of registrar business processes is not sufficient to\r\ndetect and prevent fraud, misrepresentation, and impersonation of registrants.\r\nFinding (3) Consistent use of available mechanisms (Registrar-Lock, EPP authInfo, and notification of a pending\r\ntransfer issued to a registrant by a losing registrar) can prevent some hijacking incidents.\r\nFinding (4) ICANN Policy on Transfer of Registrations between Registrars specifies that \"consent from an\r\nindividual or entity that has an email address matching the Transfer Contact email address\" is an acceptable form\r\nof identity. Transfer Contact email addresses are often accessible via the Whois service and have been used to\r\nimpersonate registrants.\r\nhttps://www.icann.org/en/ssac/registration-services/documents/sac-007-domain-name-hijacking-incidents-threats-risks-and-remediation-12-07-2005-en\r\nPage 1 of 3\n\nFinding (5) Publishing registrant email addresses and contact information contributes to domain name hijacking\r\nand registrant impersonation. Hijacking incidents described in this report illustrate how attackers target a domain\r\nby gathering contact information using Whois services and by registering expired domains used by administrative\r\ncontacts.\r\nFinding (6) Accuracy of registration records and Whois information are critical to the transfer process. The\r\nICANN Whois Data Reminder Policy requires that registrars annually request registrants to update Whois data,\r\nbut registrars have no obligation to take any action except to notify registrants. Registrants who allow registration\r\nrecords to become stale appear to be more vulnerable to attacks.\r\nFinding (7) ICANN and registries have business relationships with registrars, but no relationship with resellers\r\n(service providers). Resellers, however, may operate with the equivalent of a registrar's privileges when\r\nregistering domain names. Recent hijacking incidents raise concerns with respect to resellers. The current situation\r\nsuggests that resellers are effectively \"invisible\" to ICANN and registries and are not distinguishable from\r\nregistrants. The responsibility of assuring that policies are enforced by resellers (and are held accountable if they\r\nare not) is entirely the burden of the registrar.\r\nFinding (8) ICANN requires that registrars maintain records of domain name transactions. It does not appear that\r\nall registrars are working closely enough with their resellers to implement this requirement.\r\nFinding (9) The Inter-Registrar Transfer Policy incorporates formal dispute mechanisms. These were not designed\r\nto prevent incidents requiring immediate and coordinated technical assistance across registrars. Specifically, there\r\nare no provisions to resolve an urgent restoration of domain name registration information and DNS configuration.\r\nFinding (10) Changes to transfer processes introduced with the implementation of the ICANN Inter-Registrar\r\nTransfer Policy have not been the cause of any known attacks against domain names. There is no evidence to\r\nsupport reverting to the earlier policy.\r\nOn the basis of these findings, the Committee makes the following recommendations:\r\nRecommendation (1): Registries should ensure that Registrar-Lock and EPP authInfo are implemented according\r\nto specification. In particular, registries should confirm that registrars comply with the transfer policy and do not\r\nuse the same EPP authInfo code for all domains they register.\r\nRecommendation (2): Registries and registrars should provide resellers and registrants with Best Common\r\nPractices that describe appropriate use and assignment of EPP authInfo codes and risks of misuse when the\r\nuniqueness property of this domain name password is not preserved.\r\nRecommendation (3): Under the current transfer policy, a losing registrar notifies a registrant upon receiving a\r\npending transfer notice from the registry at its option.\r\nRegistrars should investigate whether making this notice a mandatory action would reduce hijacking incidences.\r\nRecommendation (4): Registrars should make contact information for emergency support staff available to other\r\nregistrars, agents of registrars (resellers), and registry operators. Specifically, registrars should provide an\r\nemergency action channel. The purpose of this channel is to provide 24 x 7 access to registrar technical support\r\nhttps://www.icann.org/en/ssac/registration-services/documents/sac-007-domain-name-hijacking-incidents-threats-risks-and-remediation-12-07-2005-en\r\nPage 2 of 3\n\nstaff that are authorized to assess an emergency situation, establish the magnitude and immediacy of harm, and\r\ntake measures to restore registration records and DNS configuration in circumstances which merit such\r\nintervention.\r\nRecommendation (5): Registrars should identify evaluation criteria a registrant must provide to obtain immediate\r\nintervention and restoration of domain name registration information and DNS configuration. Registrars should\r\ndefine emergency procedures and policy based on these criteria. This policy would complement the Transfer\r\nDispute Resolution Policy (TDRP) and must not undermine or conflict with those policies.\r\nRecommendation (6): ICANN, the registries, and the registrars should conduct a public awareness campaign to\r\nidentify the criteria and the procedures registrants must follow to request intervention and obtain immediate\r\nrestoration of a domain name and DNS configuration.\r\nRecommendation (7): Registrars should investigate additional methods to improve accuracy and integrity of\r\nregistrant records. More frequent or alternate communications might assist registrants in keeping their information\r\nup to date. Registrars should also acquire emergency contact information from registrants for technical staff who\r\nare authorized and able to assist in responding to an urgent restoration of domain name incident.\r\nRecommendation (8): Registrars should improve registrant awareness of the threats of domain name hijacking\r\nand registrant impersonation and fraud, and emphasize the need for registrants to keep registration information\r\naccurate. Registrars should also inform registrants of the availability and purpose of the Registrar-Lock, and\r\nencourage its use. Registrars should further inform registrants of the purpose of authorization mechanisms (EPP\r\nauthInfo), and should develop recommended practices for registrants to protect their domains, including routine\r\nmonitoring of domain name status, and timely and accurate maintenance of contact and authentication\r\ninformation.\r\nRecommendation (9): ICANN should investigate whether stronger and more publicly visible enforcement\r\nmechanisms are needed to deal with registrars that fail to comply with the transfer policy, and to hold registrars\r\naccountable for the actions of their resellers.\r\nRecommendation (10): ICANN should consider whether to strengthen the identity verification requirements in\r\nelectronic correspondence to be commensurate with the verification used when the correspondence is by mail or in\r\nperson.\r\nSource: https://www.icann.org/en/ssac/registration-services/documents/sac-007-domain-name-hijacking-incidents-threats-risks-and-remediatio\r\nn-12-07-2005-en\r\nhttps://www.icann.org/en/ssac/registration-services/documents/sac-007-domain-name-hijacking-incidents-threats-risks-and-remediation-12-07-2005-en\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.icann.org/en/ssac/registration-services/documents/sac-007-domain-name-hijacking-incidents-threats-risks-and-remediation-12-07-2005-en"
	],
	"report_names": [
		"sac-007-domain-name-hijacking-incidents-threats-risks-and-remediation-12-07-2005-en"
	],
	"threat_actors": [],
	"ts_created_at": 1775441508,
	"ts_updated_at": 1775791328,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d77dfb3322b5faf674576875c40cf0e52251b527.pdf",
		"text": "https://archive.orkl.eu/d77dfb3322b5faf674576875c40cf0e52251b527.txt",
		"img": "https://archive.orkl.eu/d77dfb3322b5faf674576875c40cf0e52251b527.jpg"
	}
}