{ "id": "ab290b85-0ea0-4652-925f-511b6bf3c37f", "created_at": "2026-04-06T00:21:12.146093Z", "updated_at": "2026-04-10T03:23:51.438434Z", "deleted_at": null, "sha1_hash": "20ac85f1e2e7b0b3763148adb1fb78e1e0e64e46", "title": "Scanning Alexa's Top 1M for AXFR - Internetwache - A secure internet is our concern", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 91677, "plain_text": "Scanning Alexa's Top 1M for AXFR - Internetwache - A secure internet is\r\nour concern\r\nBy Internetwache.org\r\nPublished: 2015-03-29 · Archived: 2026-04-05 15:44:23 UTC\r\nIn this blogpost we will discuss a simple information disclosure problem called unauthorized AXFR. This can be used to\r\nleak DNS settings of a particular target, thus revealing internal / private considered DNS entries.\r\nWe’ve checked Alexa’s Top 1M for this kind of issue and came to some interesting results.\r\nWhat is AXFR?\r\nAsynchronous Xfer Full Range is a mechanism used by the DNS system to transfer zone information for a domain from a\r\nmaster (primary) DNS server to several slave (secondary) DNS servers. A slave sends an AXFR-request to the master which\r\nreplies with all DNS information associated to a domain (zone).\r\nWhat could possibly go wrong?\r\nIf the master server does not validate the source of an AXFR request, anyone will be able to download the DNS zone file\r\nfrom this server. Usually only the secondary servers should be allowed to download the zone information from the master\r\nserver.\r\nOne could argue that all the information in a zone file is publicly available, because you can request it “easily”:\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n\u003e dig NS google.com\r\n;; ANSWER SECTION:\r\ngoogle.com. 21599 IN NS ns3.google.com.\r\ngoogle.com. 21599 IN NS ns2.google.com.\r\ngoogle.com. 21599 IN NS ns1.google.com.\r\ngoogle.com. 21599 IN NS ns4.google.com.\r\nWe request information about the nameservers of google.com first. There are four nameservers which are answering DNS-requests for the domain.\r\n1\r\n2\r\n3\r\n4\r\n5\r\n6\r\n7\r\n8\r\n9\r\n10\r\n11\r\n12\r\n13\r\n\u003e dig A google.com @ns4.google.com\r\n;; ANSWER SECTION:\r\ngoogle.com. 300 IN A 173.194.32.196\r\ngoogle.com. 300 IN A 173.194.32.201\r\ngoogle.com. 300 IN A 173.194.32.198\r\ngoogle.com. 300 IN A 173.194.32.199\r\ngoogle.com. 300 IN A 173.194.32.194\r\ngoogle.com. 300 IN A 173.194.32.193\r\ngoogle.com. 300 IN A 173.194.32.200\r\ngoogle.com. 300 IN A 173.194.32.206\r\ngoogle.com. 300 IN A 173.194.32.195\r\ngoogle.com. 300 IN A 173.194.32.192\r\ngoogle.com. 300 IN A 173.194.32.197\r\nNow, we asked the fourth nameserver ( ns4.google.com ) to list us all A (IPv4) entries for the domain google.com .\r\nThe same works for other request types (AAA/TXT/MX/CNAME/…), but you will need to know the DNS entry to ask for.\r\nIt’s not possible to ask something like “List me all subdomains for google.com in your zone”. There are tools like Subbrute\r\nwhich brute-force the entries.\r\nFrom a security perspective this information is the most valuable, because you are probably going to find some entries\r\npointing to unprotected/vulnerable software.\r\nhttps://en.internetwache.org/scanning-alexas-top-1m-for-axfr-29-03-2015/\r\nPage 1 of 3\n\nFor example an admin sets up a monitoring system at the subdomain monitoring.internal.server1.domain.tld . He\r\nthinks that it is hard for an attacker to guess this subdomain and that he does not need to set up additional layers of security\r\nto protect the system from unauthorized access.\r\nIf one of his nameservers is misconfigured, an attacker can send an AXFR request, download the zone and get access to the\r\nmonitoring system.\r\nScanning Alexa’s top 1M\r\nWe wanted to see how many misconfigured nameservers can be found in Alexa’s top 1M websites. We used a small python\r\nscript to do the work. You can find it on GitHub.\r\nThe results were a bit astonishing:\r\n132854 AXFRs were made\r\n72401 unique domains are affected\r\n48448 unique nameservers are affected\r\nSome domains had multiple misconfigured nameservers, thus there have been more transfers than domains affected or the\r\nother way round that one nameserver served more than one zonefile.\r\nSo on average every 20th website of the top Alexa 1M runs a misconfigured webserver.\r\nTLDs of the affected domains:\r\nTLDs of the affected nameservers:\r\nWe were very disappointed to see some well and not so well known hosting companies running misconfigured nameservers.\r\nGrabbing some random samples from the data lead to the conclusion that information of the companies or it’s customers\r\ncould be accessed unauthenticated (similar to the scenario described above).\r\nAll other kind of websites could be found in our research results, too: Ranging from (huge) news portals over shopping sites\r\nto small personal websites.\r\nHow to fix?\r\nThe easiest way to fix this issue is to re-check your dns server’s configuration file. Make sure that the nameservers only\r\nallow AXFR to subsidiary nameservers and that these aren’t allowed to answer AXFR requests.\r\nIf you want to check if your nameservers are misconfigured, you can use the following one-liner directly on your bash shell:\r\n1\r\n2\r\n#!/bin/bash\r\n# You need to have dnsutils installed\r\nhttps://en.internetwache.org/scanning-alexas-top-1m-for-axfr-29-03-2015/\r\nPage 2 of 3\n\n3\r\n4\r\nDOMAIN=\"YOURDOMAIN.TLD\"\r\ndig NS $DOMAIN +short | sed -e \"s/\\.$//g\" | while read nameserver; do echo \"Testing $DOMAIN @ $nameserver\"; dig AXFR $DOMAIN \"@$n\r\nIf you don’t want to use the shell, you can use the following website: https://hackertarget.com/zone-transfer/\r\nWe deeply recommend you to do so :)\r\nIf you get the following output for all nameservers then you’re safe.\r\n1 ; Transfer failed.\r\nOtherwise you’re probably running a misconfigured server. In case it’s the popular BIND DNS-server you can use the\r\nfollowing option to limit the IP addresses:\r\n1 allow-transfer { 192.168.1.1; };\r\nWhere 192.168.1.1 is the IP address of the secondary DNS server.\r\nConclusion\r\nIt’s interesting to see that such ‘easy’ configuration mistakes, which had already been discussed around the 90’s, are still\r\nhappening.\r\nThe US CERT picked up on the topic and publised an alert about it.\r\nStay safe,\r\nthe team of internetwache.org\r\nUpdates\r\n#1: 29/03/15: Changed URL for the AXFR testing website. Added configuration option for BIND.\r\n#2: 08/01/16: Added link to US CERT Alert.\r\nSource: https://en.internetwache.org/scanning-alexas-top-1m-for-axfr-29-03-2015/\r\nhttps://en.internetwache.org/scanning-alexas-top-1m-for-axfr-29-03-2015/\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://en.internetwache.org/scanning-alexas-top-1m-for-axfr-29-03-2015/" ], "report_names": [ "scanning-alexas-top-1m-for-axfr-29-03-2015" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434872, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/20ac85f1e2e7b0b3763148adb1fb78e1e0e64e46.pdf", "text": "https://archive.orkl.eu/20ac85f1e2e7b0b3763148adb1fb78e1e0e64e46.txt", "img": "https://archive.orkl.eu/20ac85f1e2e7b0b3763148adb1fb78e1e0e64e46.jpg" } }