![\"\"](\"https:\/\/krebsonsecurity.com\/wp-content\/uploads\/2019\/02\/mideastglobe.jpg\")
<\/a><\/p>\nBefore we delve into the extensive research that culminated in this post, it\u2019s helpful to review the facts disclosed publicly so far. On Nov. 27, 2018, Cisco\u2019s Talos<\/strong> research division published a write-up<\/a> outlining the contours of a sophisticated cyber espionage campaign it dubbed \u201cDNSpionage<\/strong>.\u201d<\/p>\n The DNS part of that moniker refers to the global \u201cD<\/strong>omain N<\/strong>ame S<\/strong>ystem<\/a>,\u201d which serves as a kind of phone book for the Internet by translating human-friendly Web site names (example.com) into numeric Internet address that are easier for computers to manage.<\/p>\n Talos said the perpetrators of DNSpionage were able to steal email and other login credentials from a number of government and private sector entities in Lebanon and the United Arab Emirates by hijacking the DNS servers for these targets, so that all email and virtual private networking (VPN) traffic was redirected to an Internet address controlled by the attackers.<\/p>\n Talos reported that these DNS hijacks also paved the way for the attackers to obtain SSL encryption certificates for the targeted domains (e.g. webmail.finance.gov.lb), which allowed them to decrypt the intercepted email and VPN credentials and view them in plain text.<\/p>\n On January 9, 2019, security vendor FireEye<\/strong> released its report<\/a>, \u201cGlobal DNS Hijacking Campaign: DNS Record Manipulation at Scale,\u201d which went into far greater technical detail about the \u201chow\u201d of the espionage campaign, but contained few additional details about its victims.<\/p>\n About the same time as the FireEye report, the U.S. Department of Homeland Security<\/strong> issued a rare emergency directive ordering<\/a> all U.S. federal civilian agencies to secure the login credentials for their Internet domain records. As part of that mandate, DHS published a short list of domain names and Internet addresses that were used in the DNSpionage campaign, although those details did not go beyond what was previously released by either Cisco Talos or FireEye.<\/p>\n That changed on Jan. 25, 2019, when security firm CrowdStrike<\/strong> published a blog post<\/a> listing virtually every Internet address known to be (ab)used by the espionage campaign to date. The remainder of this story is based on open-source research and interviews conducted by KrebsOnSecurity in an effort to shed more light on the true extent of this extraordinary \u2014 and ongoing \u2014 attack.<\/p>\n The \u201cindicators of compromise\u201d related to the DNSpionage campaign, as published by CrowdStrike.<\/p>\n<\/div>\n I began my research by taking each of the Internet addresses laid out in the CrowdStrike report and running them through both Farsight Security<\/a> and SecurityTrails<\/a>, services that passively collect data about changes to DNS records tied to tens of millions of Web site domains around the world.<\/p>\n Working backwards from each Internet address, I was able to see that in the last few months of 2018 the hackers behind DNSpionage succeeded in compromising key components of DNS infrastructure for more than 50 Middle Eastern companies and government agencies, including targets in Albania, Cyprus, Egypt, Iraq, Jordan, Kuwait, Lebanon, Libya, Saudi Arabia and the United Arab Emirates.<\/p>\n For example, the passive DNS data shows the attackers were able to hijack the DNS records for mail.gov.ae<\/strong>, which handles email for government offices of the United Arab Emirates. Here are just a few other interesting assets successfully compromised in this cyber espionage campaign:<\/p>\n -nsa.gov.iq:<\/strong> the National Security Advisory of Iraq The passive DNS data provided by Farsight and SecurityTrails also offered clues about when each of these domains was hijacked. In most cases, the attackers appear to have changed the DNS records for these domains (we\u2019ll get to the \u201chow\u201d in a moment) so that the domains pointed to servers in Europe that they controlled.<\/p>\n Shortly after the DNS records for these TLDs were hijacked \u2014 sometimes weeks, sometimes just days or hours \u2014 the attackers were able to obtain SSL certificates for those domains from SSL providers Comodo<\/a> and\/or Let\u2019s Encrypt<\/a>. The preparation for several of these attacks can be seen at cert.sh<\/a>, which provides a searchable database of all new SSL certificate creations.<\/p>\n Let\u2019s take a closer look at one example. The CrowdStrike report references the Internet address 139.59.134[.]216<\/strong> (see above), which according to Farsight was home to just seven different domains over the years. Two of those domains only appeared at that Internet address in December 2018, including domains in Lebanon and \u2014 curiously \u2014 Sweden.<\/p>\n The first domain was \u201cns0.idm.net.lb<\/strong>,\u201d which is a server for the Lebanese Internet service provider IDM<\/a>. From early 2014 until December 2018, ns0.idm.net.lb pointed to 194.126.10[.]18<\/strong>, which appropriately enough is an Internet address based in Lebanon. But as we can see in the screenshot from Farsight\u2019s data below, on Dec. 18, 2018, the DNS records for this ISP were changed to point Internet traffic destined for IDM to a hosting provider in Germany (the 139.59.134[.]216 address).<\/p>\n Source: Farsight Security<\/p>\n<\/div>\n Notice what else is listed along with IDM\u2019s domain at 139.59.134[.]216, according to Farsight:<\/p>\n The DNS records for the domains sa1.dnsnode.net<\/strong> and fork.sth.dnsnode.net<\/strong> also were changed from their rightful home in Sweden to the German hosting provider controlled by the attackers in December. These domains are owned by\u00a0Netnod Internet Exchange<\/a>, a major global DNS provider based in Sweden. Netnod also operates one of the 13 \u201croot\u201d name servers,<\/a>\u00a0a critical resource that forms the very foundation of the global DNS system.<\/p>\n We\u2019ll come back to Netnod in a moment. But first let\u2019s look at another Internet address referenced in the CrowdStrike report as part of the infrastructure abused by the DNSpionage hackers: 82.196.11[.]127<\/strong>. This address in The Netherlands also is home to the domain mmfasi[.]com<\/strong>, which Crowdstrike says was one of the attacker\u2019s domains that was used as a DNS server for some of the hijacked infrastructure.<\/p>\n As we can see in the screenshot above, 82.196.11[.]127 was temporarily home to another pair of Netnod DNS servers, as well as the server \u201cns.anycast.woodynet.net<\/strong>.\u201d That domain is derived from the nickname of\u00a0Bill Woodcock<\/a>, who serves as executive director of\u00a0Packet Clearing House (PCH)<\/a>.<\/p>\n PCH is a nonprofit entity based in northern California that also manages significant amounts of the world\u2019s DNS infrastructure, particularly the DNS for more than 500 top-level domains and a number of the Middle East top-level domains targeted by DNSpionage.<\/span><\/p>\n Contacted on Feb. 14 by KrebsOnSecurity, Netnod CEO Lars Michael Jogb\u00e4ck<\/strong> confirmed that parts of Netnod\u2019s DNS infrastructure were hijacked in late December 2018 and early January 2019 after the attackers gained access to accounts at Netnod\u2019s domain name registrar.<\/p>\n Jogb\u00e4ck pointed to a statement<\/a> the company published on its Web site on Feb. 5, which says Netnod learned of its role in the attack on January 2 and has been in contact with all relevant parties and customers throughout this process.<\/p>\n \u201cAs a participant in an international security co-operation, Netnod became aware on 2 January 2019 that we had been caught up in this wave and that we had experienced a MITM (man-in-the-middle) attack,\u201d the statement reads. \u201cNetnod was not the ultimate goal of the attack. The goal is considered to have been the capture of login details for Internet services in countries outside of Sweden.\u201d<\/p>\n In an interview with this author on Feb. 15, PCH\u2019s Woodcock acknowledged that portions of his organization\u2019s infrastructure were compromised after the DNSpionage hackers abused unauthorized access to its domain name registrar.<\/p>\n As it happens, the registrar records for both pch.net and dnsnode.net point to the same sources: Key-Systems GmbH<\/strong>, a domain registrar based in Germany; and Frobbit.se<\/strong>, a company in Sweden. Frobbit is a reseller of Key Systems, and the two companies share some of the same online resources.<\/p>\n Woodcock said the hackers phished credentials that PCH\u2019s registrar used to send signaling messages known as the\u00a0Extensible Provisioning Protocol (EPP)<\/a>. EPP is a little-known interface that serves as a kind of back-end for the global DNS system, allowing domain registrars to notify the regional registries (like Verisign) about changes to domain records, including new domain registrations, modifications, and transfers.<\/p>\n \u201cAt the beginning of January, Key-Systems said they believed that their EPP interface had been abused by someone who had stolen valid credentials,\u201d Woodcock said.<\/p>\n Key-Systems declined to comment for this story, beyond saying it does not discuss details of its reseller clients\u2019 businesses.<\/p>\n Netnod\u2019s written statement<\/a> on the attack referred further inquiries to the company\u2019s security director Patrik F\u00e4ltstr\u00f6m<\/strong>, who also is co-owner of Frobbit.se.<\/p>\n In an email to KrebsOnSecurity,\u00a0F\u00e4ltstr\u00f6m said unauthorized EPP instructions were sent to various registries by the DNSpionage attackers from both Frobbit and Key Systems.<\/p>\n \u201cThe attack was from my perspective clearly an early version of a serious EPP attack,\u201d he wrote. \u201cThat is, the goal was to get the right EPP commands sent to the registries. I am extremely nervous personally over extrapolations towards the future. Should registries allow any EPP command to come from the registrars? We will always have some weak registrars, right?\u201d<\/p>\n One of the more interesting aspects of these attacks is that both Netnod and PCH are vocal proponents and adopters of DNSSEC<\/a> (a.k.a. \u201cDNS Security Extensions\u201d), which is a technology designed to defeat the very type of attack that the DNSpionage hackers were able to execute.<\/p>\n Image: APNIC<\/p>\n<\/div>\n DNSSEC protects applications from using forged or manipulated DNS data, by requiring that all DNS queries for a given domain or set of domains be digitally signed. In DNSSEC, if a name server determines that the address record for a given domain has not been modified in transit, it resolves the domain and lets the user visit the site. If, however, that record has been modified in some way or doesn\u2019t match the domain requested, the name server blocks the user from reaching the fraudulent address.<\/p>\n While DNSSEC can be an effective tool for mitigating attacks such as those launched by DNSpionage, only about 20 percent of the world\u2019s major networks and Web sites have enabled it, according to measurements<\/a> gathered by APNIC<\/strong>, the regional Internet address registry for the Asia-Pacific region.<\/p>\n Jogb\u00e4ck said Netnod\u2019s infrastructure suffered three separate attacks from the DNSpionage attackers. The first two occurred in a two-week window between Dec. 14, 2018 and Jan. 2, 2019, and targeted company servers that were not<\/em> protected by DNSSEC.<\/p>\n However, he said the third attack between Dec. 29 and Jan. 2 targeted Netnod infrastructure that was<\/em> protected by DNSSEC and serving its own internal email network. Yet, because the attackers already had access to its registrar\u2019s systems, they were able to briefly disable that safeguard \u2014 or at least long enough to obtain SSL certificates for two of Netnod\u2019s<\/a> email servers<\/a>.<\/p>\n Jogb\u00e4ck told KrebsOnSecurity that once the attackers had those certificates, they re-enabled DNSSEC for the company\u2019s targeted servers while apparently preparing to launch the second stage of the attack \u2014 diverting traffic flowing through its mail servers to machines the attackers controlled. But Jogb\u00e4ck said that for whatever reason, the attackers neglected to use their unauthorized access to its registrar to disable DNSSEC before later attempting to siphon Internet traffic.<\/p>\n \u201cLuckily for us, they forgot to remove that when they launched their man-in-the-middle attack,\u201d he said. \u201cIf they had been more skilled they would have removed DNSSEC on the domain, which they could have done.\u201d<\/p>\n Woodcock says PCH validates DNSSEC on all of its infrastructure, but that not all of the company\u2019s customers \u2014 particularly some of the countries in the Middle East targeted by DNSpionage \u2014 had configured their systems to fully implement the technology.<\/p>\n Woodcock said PCH\u2019s infrastructure was targeted by DNSpionage attackers in four distinct attacks between December 13, 2018 and January 2, 2019. With each attack, the hackers would turn on their password-slurping tools for roughly one hour, and then switch them off before returning the network to its original state after each run.<\/p>\n The attackers didn\u2019t need to enable their surveillance dragnet longer than an hour each time because most modern smartphones are configured to continuously pull new email for any accounts the user may have set up on his device. Thus, the attackers were able to hoover up a great many email credentials with each brief hijack.<\/p>\n On Jan. 2, 2019 \u2014 the same day the DNSpionage hackers went after Netnod\u2019s internal email system \u2014 they also targeted PCH directly, obtaining SSL<\/a> certificates<\/a> from Comodo for two PCH domains that handle internal email for the company.<\/p>\n Woodcock said PCH\u2019s reliance on DNSSEC almost completely blocked that attack, but that it managed to snare email credentials for two employees who were traveling at the time. Those employees\u2019 mobile devices were downloading company email via hotel wireless networks that \u2014 as a prerequisite for using the wireless service \u2014 forced their devices to use the hotel\u2019s DNS servers, not PCH\u2019s DNNSEC-enabled systems.<\/p>\n \u201cThe two people who did get popped, both were traveling and were on their iPhones, and they had to traverse through captive portals during the hijack period,\u201d Woodcock said. \u201cThey had to switch off our name servers to use the captive portal, and during that time the mail clients on their phones checked for new email. Aside from that, DNSSEC saved us from being really, thoroughly owned.\u201d<\/p>\n Because PCH had protected its domains with DNSSEC, the practical effect of the hijack against its mail infrastructure was that for roughly an hour nobody but the two remote employees received any email.<\/p>\n \u201cFor essentially all of our users, what it looked like was the mail server just wasn\u2019t available for a short period,\u201d Woodcock said. \u201cIt didn\u2019t resolve for a while if they happened to be checking their phone or whatever, and each person thought well that\u2019s funny, I\u2019ll check it back in a while. And by the time they checked again it was working fine. A bunch of our staff noticed a brief outage in our email service, but nobody thought enough of it to discuss it with anyone else or open a ticket.\u201d<\/p>\n But the DNSpionage hackers were not deterred. In a letter to its customers sent earlier this month, PCH said a forensic investigation determined that on Jan. 24 a computer which holds its Web site user database had been compromised. The user data stored in the database included customer usernames, bcrypt<\/a> password hashes, emails, addresses, and organization names.<\/p>\n \u201cWe see no evidence that the attackers accessed the user database or exfiltrated it,\u201d the message reads. \u201cSo we are providing you this information as a matter of transparency and precaution, rather than because we believe that your data was compromised.\u201d<\/p>\n Multiple experts interviewed for this story said one persistent problem with DNS-based attacks is that a great deal of organizations tend to take much of their DNS infrastructure for granted. For example, many entities don\u2019t even log their DNS traffic, nor do they keep a close eye on any changes made to their domain records.<\/p>\n Even for those companies making an effort to monitor their DNS infrastructure for suspicious changes, some monitoring services only take snapshots of DNS records passively, or else only do so actively on a once-daily basis. Indeed, Woodcock said PCH relied on no fewer than three monitoring systems, and that none of them alerted his organization to the various one-hour hijacks that hit PCH\u2019s DNS systems.<\/p>\n \u201cWe\u00a0had three different commercial DNS monitoring services, none of which caught it,\u201d he said. \u201cNone of them even warned us that it had happened after the fact.\u201d<\/p>\n Woodcock said PCH has since set up a system to poll its own DNS infrastructure multiple times each hour, and to alert immediately on any changes.<\/p>\n Jogb\u00e4ck said Netnod also has beefed up its monitoring, as well as redoubled efforts to ensure that all of the available options for securing their domain infrastructure were being used. For instance, the company had not previously secured all of its domains with a \u201cdomain lock<\/a>,\u201d a service that requires a registrar to take additional authentication steps before making any modifications to a domain\u2019s records.<\/p>\n \u201cWe are really sad we didn\u2019t do a better job of protecting our customers, but we are also a victim in the chain of the attack,\u201d Jogb\u00e4ck said. \u201cYou can change to a better lock after you\u2019ve been robbed, and hopefully make it more difficult for someone to do it again. But I can truly say we have learned a tremendous amount from being a victim in this attack, and we are now much better off than before.\u201d<\/p>\n Woodcock said he\u2019s worried that Internet policymakers and other infrastructure providers aren\u2019t taking threats to the global DNS seriously or urgently enough, and he\u2019s confident the DNSpionage hackers will have plenty of other victims to target and exploit in the months and years ahead.<\/p>\n \u201cAll of this is a running battle,\u201d he said. \u201cThe Iranians are not just trying to do these attacks to have an immediate effect. They\u2019re trying to get into the Internet infrastructure deeply enough so they can get away with this stuff whenever they want to.<\/span> They\u2019re looking to get as many ways in as possible that they can use for specific goals in the future.\u201d<\/p>\n John Crain<\/strong> is chief security, stability and resiliency officer at ICANN<\/a>, the non-profit entity that oversees the global domain name industry. Crain said many of the best practices that can make it more difficult for attackers to hijack a target\u2019s domains or DNS infrastructure have been known for more than a decade.<\/p>\n \u201cA lot of this comes down to data hygiene,\u201d Crain said. \u201cLarge organizations down to mom-and-pop entities are not paying attention to some very basic security practices, like multi-factor authentication. These days, if you have a sub-optimal security stance, you\u2019re going to get owned. That\u2019s the reality today. We\u2019re seeing much more sophisticated adversaries now taking actions on the Internet, and if you\u2019re not doing the basic stuff they\u2019re going to hit you.\u201d<\/p>\n Some of those best practices for organizations include:<\/p>\n -Use DNSSEC (both signing zones and validating responses)<\/p>\n -Use registration features like Registry Lock that can help protect domain names records from being changed<\/p>\n -Use access control lists for applications, Internet traffic and monitoring<\/p>\n -Use 2-factor authentication, and require it to be used by all relevant users and subcontractors<\/p>\n -In cases where passwords are used, pick unique passwords and consider password managers<\/p>\n -Review accounts with registrars and other providers<\/p>\n -Monitor certificates by monitoring, for example, Certificate Transparency Logs<\/a><\/p>\n Tags: APNIC<\/a>, Bill Woodcock<\/a>, Cisco Talos<\/a>, Comodo<\/a>, CrowdStrike<\/a>, DHS<\/a>, DNSpionage<\/a>, DNSSEC<\/a>, EPP<\/a>, extensible provisioning protocol<\/a>, Farsight Security<\/a>, FireEye<\/a>, Frobbit<\/a>, ICANN<\/a>, John Crain<\/a>, Key Systems<\/a>, Lars Michael Jogb\u00e4ck<\/a>, LetsEncrypt<\/a>, Netnod<\/a>, Packet Clearing House<\/a>, Patrik F\u00e4ltstr\u00f6m<\/a>, PCH<\/a>, SecurityTrails<\/a>, U.S. Department of Homeland Security<\/a><\/p>\n<\/p>\nPASSIVE DNS<\/h4>\n
-webmail.mofa.gov.ae:<\/strong> email for the United Arab Emirates\u2019 Ministry of Foreign Affairs
-shish.gov.al:<\/strong> the State Intelligence Service of Albania
-mail.mfa.gov.eg:<\/strong> mail server for Egypt\u2019s Ministry of Foreign Affairs
-mod.gov.eg:<\/strong> Egyptian Ministry of Defense
-embassy.ly:<\/strong> Embassy of Libya
-owa.e-albania.al:<\/strong> the Outlook Web Access portal for the e-government portal of Albania
-mail.dgca.gov.kw:<\/strong> email server for Kuwait\u2019s Civil Aviation Bureau
-gid.gov.jo:<\/strong> Jordan\u2019s General Intelligence Directorate
-adpvpn.adpolice.gov.ae:<\/strong> VPN service for the Abu Dhabi Police
-mail.asp.gov.al:<\/strong> email for Albanian State Police
-owa.gov.cy:<\/strong> Microsoft Outlook Web Access for Government of Cyprus
-webmail.finance.gov.lb:<\/strong> email for Lebanon Ministry of Finance
-mail.petroleum.gov.eg:<\/strong> Egyptian Ministry of Petroleum
-mail.cyta.com.cy:<\/strong> Cyta telecommunications and Internet provider, Cyprus
-mail.mea.com.lb:<\/strong> email access for Middle East Airlines<\/p>\n<\/p>\n<\/p>\n<\/p>\nTARGETING THE REGISTRARS<\/h4>\n
DNSSEC<\/h4>\n
<\/p>\nIMPROVEMENTS<\/h4>\n
RECOMMENDATIONS<\/h4>\n
<\/a><\/p>\n