{"id":15537,"date":"2019-03-29T11:23:59","date_gmt":"2019-03-29T15:23:59","guid":{"rendered":"https:\/\/www.kaspersky.co.in\/blog\/grand-theft-dns-rsa2019\/15537\/"},"modified":"2020-04-02T16:07:44","modified_gmt":"2020-04-02T10:37:44","slug":"grand-theft-dns-rsa2019","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.in\/blog\/grand-theft-dns-rsa2019\/15537\/","title":{"rendered":"RSAC 2019: Grand Theft DNS"},"content":{"rendered":"<p>At RSA Conference 2019, the SANS Institute reported on several new types of attack that they consider to be highly dangerous. This post looks at one of them.<\/p>\n<p>An attack highlighted by SANS instructor Ed Skoudis can potentially be used to take full control of a company\u2019s IT infrastructure\u00a0\u2014 and no complex tools are required, just relatively simple DNS manipulations.<\/p>\n<h2>Manipulating enterprise DNS infrastructure<\/h2>\n<p>Here\u2019s how the attack works:<\/p>\n<ol>\n<li>Cybercriminals harvest (by whatever means) username\/password pairs for compromised accounts, of which there are currently <a href=\"https:\/\/www.kaspersky.com\/blog\/collection-numba-one\/25403\/\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">hundreds of millions, if not billions<\/a> in known databases alone.<\/li>\n<li>They use these credentials to log into the services of DNS providers and domain registrars.<\/li>\n<li>Next, the intruders modify the DNS records, substituting the corporate domain infrastructure with their own.<\/li>\n<li>In particular, they modify the <a href=\"https:\/\/en.wikipedia.org\/wiki\/MX_record\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">MX record<\/a> and intercept messages by redirecting all corporate mail to their own mail server.<\/li>\n<li>The cybercriminals register TLS certificates for the stolen domains. At this stage, they are already in a position to intercept corporate mail and can provide proof of domain ownership, which in most cases is all that\u2019s required to have a certificate issued.<\/li>\n<\/ol>\n<p>After that, the attackers can redirect traffic bound for the target corporation\u2019s servers to their own machines. As a result, visitors to the company website are taken to fake resources that look authentic to all filters and protection systems. We encountered this scenario for the first time back in 2016, when researchers at our Brazilian branch of GReAT uncovered an attack allowing intruders to <a href=\"https:\/\/www.wired.com\/2017\/04\/hackers-hijacked-banks-entire-online-operation\/\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">hijack the infrastructure of a large bank<\/a>.<\/p>\n<p>What is especially dangerous about this attack is that the victim organization loses contact with the outside world. Mail is hijacked, and typically phones as well (the vast majority of companies use IP telephony). This greatly complicates both internal response to the incident and communication with external organizations \u2014 DNS providers, certification authorities, law enforcement agencies, and so on. And imagine if it all happens on a weekend, as in the case of the Brazilian bank!<\/p>\n<h3>How to prevent hijacking of IT infrastructure through DNS manipulation<\/h3>\n<p>What in 2016 was an innovation in the world of cybercrime became common practice a couple of years later; by 2018, IT security gurus at many leading companies were logging its use. So it is no airy-fairy threat, but a very specific attack that could be used to seize your IT infrastructure.<\/p>\n<p>Here\u2019s what Ed Skoudis thinks should be done to safeguard against attempts to manipulate the infrastructure of domain names:<\/p>\n<ul>\n<li>Use multifactor authentication in IT infrastructure management tools.<\/li>\n<li>Use DNSSEC, making sure to apply not only DNS signing, but also validation.<\/li>\n<li>Keep track of all DNS changes that might affect your company\u2019s domain names; one option is to use SecurityTrails, which allows up to 50 requests per month free.<\/li>\n<li>Keep track of residual certificates duplicating your domains and send requests to revoke them immediately. For details of how to do this, see the post: <a href=\"https:\/\/www.kaspersky.com\/blog\/residual-certificates-mitm-dos\/23661\/\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">MitM and DoS attacks on domains through the use of residual certificates<\/a>.<\/li>\n<\/ul>\n<p>From our side we can add only one piece of advice \u2014 keep your passwords secure. They should be unique and complex enough at least to withstand a <a href=\"https:\/\/encyclopedia.kaspersky.com\/glossary\/dictionary-attack\/?utm_source=kdaily&amp;utm_medium=blog&amp;utm_campaign=termin-explanation\" target=\"_blank\" rel=\"noopener noreferrer\">dictionary attack<\/a>. For generating passwords and storing them securely, you can use Kaspersky Password Manager, which is a part of our Kaspersky Small Office Security solution.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"ksos-generic\">\n","protected":false},"excerpt":{"rendered":"<p>At RSAC 2019, a SANS Institute instructor talked about how DNS manipulations can be used to hijack a company\u2019s IT infrastructure.<\/p>\n","protected":false},"author":421,"featured_media":15538,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2036,5,2610],"tags":[2533,2237,1941,2606,1026,2731,1027,2466],"class_list":{"0":"post-15537","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-news","9":"category-smb","10":"tag-certificates","11":"tag-cyberattacks","12":"tag-dns","13":"tag-domains","14":"tag-rsa-conference","15":"tag-rsa2019","16":"tag-rsac","17":"tag-tls"},"hreflang":[{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/grand-theft-dns-rsa2019\/15537\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/grand-theft-dns-rsa2019\/13082\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/grand-theft-dns-rsa2019\/17460\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/grand-theft-dns-rsa2019\/15609\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/grand-theft-dns-rsa2019\/14290\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/grand-theft-dns-rsa2019\/18155\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/grand-theft-dns-rsa2019\/17119\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/grand-theft-dns-rsa2019\/22528\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/grand-theft-dns-rsa2019\/5853\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/grand-theft-dns-rsa2019\/26255\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/grand-theft-dns-rsa2019\/11655\/"},{"hreflang":"pl","url":"https:\/\/plblog.kaspersky.com\/grand-theft-dns-rsa2019\/10568\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/grand-theft-dns-rsa2019\/18904\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/grand-theft-dns-rsa2019\/22928\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/grand-theft-dns-rsa2019\/18188\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/grand-theft-dns-rsa2019\/22390\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/grand-theft-dns-rsa2019\/22326\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.co.in\/blog\/tag\/rsac\/","name":"RSAC"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/posts\/15537","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/users\/421"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/comments?post=15537"}],"version-history":[{"count":7,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/posts\/15537\/revisions"}],"predecessor-version":[{"id":20163,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/posts\/15537\/revisions\/20163"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/media\/15538"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/media?parent=15537"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/categories?post=15537"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.co.in\/blog\/wp-json\/wp\/v2\/tags?post=15537"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}