{
	"id": "bc61bb55-2a01-46f0-bb6c-cbb4abdf652f",
	"created_at": "2026-04-06T02:10:35.655465Z",
	"updated_at": "2026-04-10T03:31:46.324049Z",
	"deleted_at": null,
	"sha1_hash": "d3f2411a8b960479fcdfdbd502527a6bb83367bd",
	"title": "A Deep Dive on the Recent Widespread DNS Hijacking Attacks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 513736,
	"plain_text": "A Deep Dive on the Recent Widespread DNS Hijacking Attacks\r\nPublished: 2019-02-18 · Archived: 2026-04-06 01:57:58 UTC\r\nThe U.S. government — along with a number of leading security companies — recently warned about a series of\r\nhighly complex and widespread attacks that allowed suspected Iranian hackers to siphon huge volumes of email\r\npasswords and other sensitive data from multiple governments and private companies. But to date, the specifics of\r\nexactly how that attack went down and who was hit have remained shrouded in secrecy.\r\nThis post seeks to document the extent of those attacks, and traces the origins of this overwhelmingly successful\r\ncyber espionage campaign back to a cascading series of breaches at key Internet infrastructure providers.\r\nBefore we delve into the extensive research that culminated in this post, it’s helpful to review the facts disclosed\r\npublicly so far. On Nov. 27, 2018, Cisco’s Talos research division published a write-up outlining the contours of a\r\nsophisticated cyber espionage campaign it dubbed “DNSpionage.”\r\nThe DNS part of that moniker refers to the global “Domain Name System,” which serves as a kind of phone book\r\nfor the Internet by translating human-friendly Web site names (example.com) into numeric Internet address that\r\nare easier for computers to manage.\r\nTalos said the perpetrators of DNSpionage were able to steal email and other login credentials from a number of\r\ngovernment and private sector entities in Lebanon and the United Arab Emirates by hijacking the DNS servers for\r\nthese targets, so that all email and virtual private networking (VPN) traffic was redirected to an Internet address\r\ncontrolled by the attackers.\r\nTalos reported that these DNS hijacks also paved the way for the attackers to obtain SSL encryption certificates\r\nfor the targeted domains (e.g. webmail.finance.gov.lb), which allowed them to decrypt the intercepted email and\r\nVPN credentials and view them in plain text.\r\nOn January 9, 2019, security vendor FireEye released its report, “Global DNS Hijacking Campaign: DNS Record\r\nManipulation at Scale,” which went into far greater technical detail about the “how” of the espionage campaign,\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 1 of 10\n\nbut contained few additional details about its victims.\r\nAbout the same time as the FireEye report, the U.S. Department of Homeland Security issued a rare emergency\r\ndirective ordering all U.S. federal civilian agencies to secure the login credentials for their Internet domain\r\nrecords. As part of that mandate, DHS published a short list of domain names and Internet addresses that were\r\nused in the DNSpionage campaign, although those details did not go beyond what was previously released by\r\neither Cisco Talos or FireEye.\r\nThat changed on Jan. 25, 2019, when security firm CrowdStrike published a blog post listing virtually every\r\nInternet address known to be (ab)used by the espionage campaign to date. The remainder of this story is based on\r\nopen-source research and interviews conducted by KrebsOnSecurity in an effort to shed more light on the true\r\nextent of this extraordinary — and ongoing — attack.\r\nThe “indicators of compromise” related to the DNSpionage campaign, as published by CrowdStrike.\r\nPASSIVE DNS\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 2 of 10\n\nI began my research by taking each of the Internet addresses laid out in the CrowdStrike report and running them\r\nthrough both Farsight Security and SecurityTrails, services that passively collect data about changes to DNS\r\nrecords tied to tens of millions of Web site domains around the world.\r\nWorking backwards from each Internet address, I was able to see that in the last few months of 2018 the hackers\r\nbehind DNSpionage succeeded in compromising key components of DNS infrastructure for more than 50 Middle\r\nEastern companies and government agencies, including targets in Albania, Cyprus, Egypt, Iraq, Jordan, Kuwait,\r\nLebanon, Libya, Saudi Arabia and the United Arab Emirates.\r\nFor example, the passive DNS data shows the attackers were able to hijack the DNS records for mail.gov.ae,\r\nwhich handles email for government offices of the United Arab Emirates. Here are just a few other interesting\r\nassets successfully compromised in this cyber espionage campaign:\r\n-nsa.gov.iq: the National Security Advisory of Iraq\r\n-webmail.mofa.gov.ae: email for the United Arab Emirates’ Ministry of Foreign Affairs\r\n-shish.gov.al: the State Intelligence Service of Albania\r\n-mail.mfa.gov.eg: mail server for Egypt’s Ministry of Foreign Affairs\r\n-mod.gov.eg: Egyptian Ministry of Defense\r\n-embassy.ly: Embassy of Libya\r\n-owa.e-albania.al: the Outlook Web Access portal for the e-government portal of Albania\r\n-mail.dgca.gov.kw: email server for Kuwait’s Civil Aviation Bureau\r\n-gid.gov.jo: Jordan’s General Intelligence Directorate\r\n-adpvpn.adpolice.gov.ae: VPN service for the Abu Dhabi Police\r\n-mail.asp.gov.al: email for Albanian State Police\r\n-owa.gov.cy: Microsoft Outlook Web Access for Government of Cyprus\r\n-webmail.finance.gov.lb: email for Lebanon Ministry of Finance\r\n-mail.petroleum.gov.eg: Egyptian Ministry of Petroleum\r\n-mail.cyta.com.cy: Cyta telecommunications and Internet provider, Cyprus\r\n-mail.mea.com.lb: email access for Middle East Airlines\r\nThe passive DNS data provided by Farsight and SecurityTrails also offered clues about when each of these\r\ndomains was hijacked. In most cases, the attackers appear to have changed the DNS records for these domains\r\n(we’ll get to the “how” in a moment) so that the domains pointed to servers in Europe that they controlled.\r\nShortly after the DNS records for these TLDs were hijacked — sometimes weeks, sometimes just days or hours\r\n— the attackers were able to obtain SSL certificates for those domains from SSL providers Comodo and/or Let’s\r\nEncrypt. The preparation for several of these attacks can be seen at crt.sh, which provides a searchable database of\r\nall new SSL certificate creations.\r\nLet’s take a closer look at one example. The CrowdStrike report references the Internet address 139.59.134[.]216\r\n(see above), which according to Farsight was home to just seven different domains over the years. Two of those\r\ndomains only appeared at that Internet address in December 2018, including domains in Lebanon and — curiously\r\n— Sweden.\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 3 of 10\n\nThe first domain was “ns0.idm.net.lb,” which is a server for the Lebanese Internet service provider IDM. From\r\nearly 2014 until December 2018, ns0.idm.net.lb pointed to 194.126.10[.]18, which appropriately enough is an\r\nInternet address based in Lebanon. But as we can see in the screenshot from Farsight’s data below, on Dec. 18,\r\n2018, the DNS records for this ISP were changed to point Internet traffic destined for IDM to a hosting provider in\r\nGermany (the 139.59.134[.]216 address).\r\nSource: Farsight Security\r\nNotice what else is listed along with IDM’s domain at 139.59.134[.]216, according to Farsight:\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 4 of 10\n\nThe DNS records for the domains sa1.dnsnode.net and fork.sth.dnsnode.net also were changed from their\r\nrightful home in Sweden to the German hosting provider controlled by the attackers in December. These domains\r\nare owned by Netnod Internet Exchange, a major global DNS provider based in Sweden. Netnod also operates one\r\nof the 13 “root” name servers, a critical resource that forms the very foundation of the global DNS system.\r\nWe’ll come back to Netnod in a moment. But first let’s look at another Internet address referenced in the\r\nCrowdStrike report as part of the infrastructure abused by the DNSpionage hackers: 82.196.11[.]127. This address\r\nin The Netherlands also is home to the domain mmfasi[.]com, which Crowdstrike says was one of the attacker’s\r\ndomains that was used as a DNS server for some of the hijacked infrastructure.\r\nAs we can see in the screenshot above, 82.196.11[.]127 was temporarily home to another pair of Netnod DNS\r\nservers, as well as the server “ns.anycast.woodynet.net.” That domain is derived from the nickname of Bill\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 5 of 10\n\nWoodcock, who serves as executive director of Packet Clearing House (PCH).\r\nPCH is a nonprofit entity based in northern California that also manages significant amounts of the world’s DNS\r\ninfrastructure, particularly the DNS for more than 500 top-level domains and a number of the Middle East top-level domains targeted by DNSpionage.\r\nTARGETING THE REGISTRARS\r\nContacted on Feb. 14 by KrebsOnSecurity, Netnod CEO Lars Michael Jogbäck confirmed that parts of\r\nNetnod’s DNS infrastructure were hijacked in late December 2018 and early January 2019 after the attackers\r\ngained access to accounts at Netnod’s domain name registrar.\r\nJogbäck pointed to a statement the company published on its Web site on Feb. 5, which says Netnod learned of its\r\nrole in the attack on January 2 and has been in contact with all relevant parties and customers throughout this\r\nprocess.\r\n“As a participant in an international security co-operation, Netnod became aware on 2 January 2019 that we had\r\nbeen caught up in this wave and that we had experienced a MITM (man-in-the-middle) attack,” the statement\r\nreads. “Netnod was not the ultimate goal of the attack. The goal is considered to have been the capture of login\r\ndetails for Internet services in countries outside of Sweden.”\r\nIn an interview with this author on Feb. 15, PCH’s Woodcock acknowledged that portions of his organization’s\r\ninfrastructure were compromised after the DNSpionage hackers abused unauthorized access to its domain name\r\nregistrar.\r\nAs it happens, the registrar records for both pch.net and dnsnode.net point to the same sources: Key-Systems\r\nGmbH, a domain registrar based in Germany; and Frobbit.se, a company in Sweden. Frobbit is a reseller of Key\r\nSystems, and the two companies share some of the same online resources.\r\nWoodcock said the hackers phished credentials that PCH’s registrar used to send signaling messages known as\r\nthe Extensible Provisioning Protocol (EPP). EPP is a little-known interface that serves as a kind of back-end for\r\nthe global DNS system, allowing domain registrars to notify the regional registries (like Verisign) about changes\r\nto domain records, including new domain registrations, modifications, and transfers.\r\n“At the beginning of January, Key-Systems said they believed that their EPP interface had been abused by\r\nsomeone who had stolen valid credentials,” Woodcock said.\r\nKey-Systems declined to comment for this story, beyond saying it does not discuss details of its reseller clients’\r\nbusinesses.\r\nNetnod’s written statement on the attack referred further inquiries to the company’s security director Patrik\r\nFältström, who also is co-owner of Frobbit.se.\r\nIn an email to KrebsOnSecurity, Fältström said unauthorized EPP instructions were sent to various registries by\r\nthe DNSpionage attackers from both Frobbit and Key Systems.\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 6 of 10\n\n“The attack was from my perspective clearly an early version of a serious EPP attack,” he wrote. “That is, the goal\r\nwas to get the right EPP commands sent to the registries. I am extremely nervous personally over extrapolations\r\ntowards the future. Should registries allow any EPP command to come from the registrars? We will always have\r\nsome weak registrars, right?”\r\nDNSSEC\r\nOne of the more interesting aspects of these attacks is that both Netnod and PCH are vocal proponents and\r\nadopters of DNSSEC (a.k.a. “DNS Security Extensions”), which is a technology designed to defeat the very type\r\nof attack that the DNSpionage hackers were able to execute.\r\nImage: APNIC\r\nDNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for\r\na given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address\r\nrecord for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If,\r\nhowever, that record has been modified in some way or doesn’t match the domain requested, the name server\r\nblocks the user from reaching the fraudulent address.\r\nWhile DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about\r\n20 percent of the world’s major networks and Web sites have enabled it, according to measurements gathered by\r\nAPNIC, the regional Internet address registry for the Asia-Pacific region.\r\nJogbäck said Netnod’s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two\r\noccurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were\r\nnot protected by DNSSEC.\r\nHowever, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was protected by\r\nDNSSEC and serving its own internal email network. Yet, because the attackers already had access to its\r\nregistrar’s systems, they were able to briefly disable that safeguard — or at least long enough to obtain SSL\r\ncertificates for two of Netnod’s email servers.\r\nJogbäck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the\r\ncompany’s targeted servers while apparently preparing to launch the second stage of the attack — diverting traffic\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 7 of 10\n\nflowing through its mail servers to machines the attackers controlled. But Jogbäck said that for whatever reason,\r\nthe attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting\r\nto siphon Internet traffic.\r\n“Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack,” he said. “If they\r\nhad been more skilled they would have removed DNSSEC on the domain, which they could have done.”\r\nWoodcock says PCH validates DNSSEC on all of its infrastructure, but that not all of the company’s customers —\r\nparticularly some of the countries in the Middle East targeted by DNSpionage — had configured their systems to\r\nfully implement the technology.\r\nWoodcock said PCH’s infrastructure was targeted by DNSpionage attackers in four distinct attacks between\r\nDecember 13, 2018 and January 2, 2019. With each attack, the hackers would turn on their password-slurping\r\ntools for roughly one hour, and then switch them off before returning the network to its original state after each\r\nrun.\r\nThe attackers didn’t need to enable their surveillance dragnet longer than an hour each time because most modern\r\nsmartphones are configured to continuously pull new email for any accounts the user may have set up on his\r\ndevice. Thus, the attackers were able to hoover up a great many email credentials with each brief hijack.\r\nOn Jan. 2, 2019 — the same day the DNSpionage hackers went after Netnod’s internal email system — they also\r\ntargeted PCH directly, obtaining SSL certificates from Comodo for two PCH domains that handle internal email\r\nfor the company.\r\nWoodcock said PCH’s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare\r\nemail credentials for two employees who were traveling at the time. Those employees’ mobile devices were\r\ndownloading company email via hotel wireless networks that — as a prerequisite for using the wireless service —\r\nforced their devices to use the hotel’s DNS servers, not PCH’s DNNSEC-enabled systems.\r\n“The two people who did get popped, both were traveling and were on their iPhones, and they had to traverse\r\nthrough captive portals during the hijack period,” Woodcock said. “They had to switch off our name servers to use\r\nthe captive portal, and during that time the mail clients on their phones checked for new email. Aside from that,\r\nDNSSEC saved us from being really, thoroughly owned.”\r\nBecause PCH had protected its domains with DNSSEC, the practical effect of the hijack against its mail\r\ninfrastructure was that for roughly an hour nobody but the two remote employees received any email.\r\n“For essentially all of our users, what it looked like was the mail server just wasn’t available for a short period,”\r\nWoodcock said. “It didn’t resolve for a while if they happened to be checking their phone or whatever, and each\r\nperson thought well that’s funny, I’ll check it back in a while. And by the time they checked again it was working\r\nfine. A bunch of our staff noticed a brief outage in our email service, but nobody thought enough of it to discuss it\r\nwith anyone else or open a ticket.”\r\nBut the DNSpionage hackers were not deterred. In a letter to its customers sent earlier this month, PCH said a\r\nforensic investigation determined that on Jan. 24 a computer which holds its Web site user database had been\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 8 of 10\n\ncompromised. The user data stored in the database included customer usernames, bcrypt password hashes, emails,\r\naddresses, and organization names.\r\n“We see no evidence that the attackers accessed the user database or exfiltrated it,” the message reads. “So we are\r\nproviding you this information as a matter of transparency and precaution, rather than because we believe that\r\nyour data was compromised.”\r\nIMPROVEMENTS\r\nMultiple experts interviewed for this story said one persistent problem with DNS-based attacks is that a great deal\r\nof organizations tend to take much of their DNS infrastructure for granted. For example, many entities don’t even\r\nlog their DNS traffic, nor do they keep a close eye on any changes made to their domain records.\r\nEven for those companies making an effort to monitor their DNS infrastructure for suspicious changes, some\r\nmonitoring services only take snapshots of DNS records passively, or else only do so actively on a once-daily\r\nbasis. Indeed, Woodcock said PCH relied on no fewer than three monitoring systems, and that none of them\r\nalerted his organization to the various one-hour hijacks that hit PCH’s DNS systems.\r\n“We had three different commercial DNS monitoring services, none of which caught it,” he said. “None of them\r\neven warned us that it had happened after the fact.”\r\nWoodcock said PCH has since set up a system to poll its own DNS infrastructure multiple times each hour, and to\r\nalert immediately on any changes.\r\nJogbäck said Netnod also has beefed up its monitoring, as well as redoubled efforts to ensure that all of the\r\navailable options for securing their domain infrastructure were being used. For instance, the company had not\r\npreviously secured all of its domains with a “domain lock,” a service that requires a registrar to take additional\r\nauthentication steps before making any modifications to a domain’s records.\r\n“We are really sad we didn’t do a better job of protecting our customers, but we are also a victim in the chain of\r\nthe attack,” Jogbäck said. “You can change to a better lock after you’ve been robbed, and hopefully make it more\r\ndifficult for someone to do it again. But I can truly say we have learned a tremendous amount from being a victim\r\nin this attack, and we are now much better off than before.”\r\nWoodcock said he’s worried that Internet policymakers and other infrastructure providers aren’t taking threats to\r\nthe global DNS seriously or urgently enough, and he’s confident the DNSpionage hackers will have plenty of\r\nother victims to target and exploit in the months and years ahead.\r\n“The Iranians are not just trying to do these attacks to have an immediate effect. They’re trying to get\r\ninto the Internet infrastructure deeply enough so they can get away with this stuff whenever they want\r\nto.\r\n“All of this is a running battle,” he said. “The Iranians are not just trying to do these attacks to have an immediate\r\neffect. They’re trying to get into the Internet infrastructure deeply enough so they can get away with this stuff\r\nwhenever they want to. They’re looking to get as many ways in as possible that they can use for specific goals in\r\nthe future.”\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 9 of 10\n\nRECOMMENDATIONS\r\nJohn Crain is chief security, stability and resiliency officer at ICANN, the non-profit entity that oversees the\r\nglobal domain name industry. Crain said many of the best practices that can make it more difficult for attackers to\r\nhijack a target’s domains or DNS infrastructure have been known for more than a decade.\r\n“A lot of this comes down to data hygiene,” Crain said. “Large organizations down to mom-and-pop entities are\r\nnot paying attention to some very basic security practices, like multi-factor authentication. These days, if you have\r\na sub-optimal security stance, you’re going to get owned. That’s the reality today. We’re seeing much more\r\nsophisticated adversaries now taking actions on the Internet, and if you’re not doing the basic stuff they’re going\r\nto hit you.”\r\nSome of those best practices for organizations include:\r\n-Use DNSSEC (both signing zones and validating responses)\r\n-Use registration features like Registry Lock that can help protect domain names records from being changed\r\n-Use access control lists for applications, Internet traffic and monitoring\r\n-Use 2-factor authentication, and require it to be used by all relevant users and subcontractors\r\n-In cases where passwords are used, pick unique passwords and consider password managers\r\n-Review accounts with registrars and other providers\r\n-Monitor certificates by monitoring, for example, Certificate Transparency Logs\r\nSource: https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nhttps://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/"
	],
	"report_names": [
		"a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks"
	],
	"threat_actors": [
		{
			"id": "8d76e350-dfb5-4733-800d-876de41f690d",
			"created_at": "2023-01-06T13:46:38.841887Z",
			"updated_at": "2026-04-10T02:00:03.119083Z",
			"deleted_at": null,
			"main_name": "DNSpionage",
			"aliases": [
				"COBALT EDGEWATER"
			],
			"source_name": "MISPGALAXY:DNSpionage",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "4632103e-8035-4a83-9ecb-c1e12e21288c",
			"created_at": "2022-10-25T16:07:23.542255Z",
			"updated_at": "2026-04-10T02:00:04.64888Z",
			"deleted_at": null,
			"main_name": "DNSpionage",
			"aliases": [],
			"source_name": "ETDA:DNSpionage",
			"tools": [
				"Agent Drable",
				"AgentDrable",
				"CACTUSPIPE",
				"DNSpionage",
				"DropperBackdoor",
				"Karkoff",
				"MailDropper",
				"OILYFACE"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "67b2c161-5a04-4e3d-8ce7-cce457a4a17b",
			"created_at": "2025-08-07T02:03:24.722093Z",
			"updated_at": "2026-04-10T02:00:03.681914Z",
			"deleted_at": null,
			"main_name": "COBALT EDGEWATER",
			"aliases": [
				"APT34 ",
				"Cold River ",
				"DNSpionage "
			],
			"source_name": "Secureworks:COBALT EDGEWATER",
			"tools": [
				"AgentDrable",
				"DNSpionage",
				"Karkoff",
				"MailDropper",
				"SideTwist",
				"TWOTONE"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775441435,
	"ts_updated_at": 1775791906,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d3f2411a8b960479fcdfdbd502527a6bb83367bd.pdf",
		"text": "https://archive.orkl.eu/d3f2411a8b960479fcdfdbd502527a6bb83367bd.txt",
		"img": "https://archive.orkl.eu/d3f2411a8b960479fcdfdbd502527a6bb83367bd.jpg"
	}
}