Hello and welcome back to this course. In this video, we're going to be talking about the domain name system or DNS and its use for reconnaissance. So the domain name system or DNS, if you're not familiar with it, is essentially the address book of the Internet. Most of us, when we're browsing the web, prefer to type in a domain name, something like google.com, and we want to get to a particular website. However, the computers, routers etc, that we're using prefer IP addresses, something like 127.0.0.1, which is your local IP address. And so the job of DNS is to translate that domain name to an IP address. And so we have top level domains like google.com that are, I guess, the top level domain is technically the .com. However, we have, within an organization, a domain like google.com that refers to most or all of the sites under that organization's umbrella. A lot of times, there're subdomains, things like mail.google.com or vpn.google.com, etc, that are a special service within an organization. And so the reason why we care about these subdomains in particular is because they're useful for learning about a particular organization and what it does with its infrastructure. For example, if you have something that's called mail.example.com, you're probably running a mail server there. And that's useful information for an ethical hacker. Alternatively, ftp.example.com has an FTP server, etc. And so, we're going to be using these subdomains in our reconnaissance because the DNS infrastructure is a fairly low touch way fork and allow to collect information in an engagement. While you're interacting with the DNS server, that's all you're interacting with. You're not having to, say, scan a particular computer and look up which ports it has to have a guess at what port they have. For example, if you're visiting www.example.com, odds are it's port 443 that you're connecting to, possibly port 80 if they're using the HTTP instead of HTTPS. But just by knowing the domain and the subdomain, we've already learned something about a target computer. And so, probably guessed from a screen here, our Python file we'll be looking at today is called DNSExploration.py. And we're going to be taking advantage of DNS to learn a little bit about a target organization's infrastructure. So, one of the great things about Python is that it has a lot of libraries to make things easy. And so we're not going to bother trying to build DNS requests by hand, parsed, or responses, etc. We're just going to use the DNS library, which makes it very easy for us to make our requests. Also take advantage of dns.resolver and then the socket library as well. So how this code is structured is, as I mentioned a moment ago, we're focused on subdomains here. It's great to know that google.com belongs to Google. But what we'd really like to know is maybe IP addresses for mail.google.com or for drive.google.com. So those subdomains that tell us a little bit about what the system that they're running on is actually doing. And so alongside this program, we've got a file called subdomains.txt, that has a list of a few of the most common subdomains. So you're used to seeing www, maybe mail, ftp etc. And so we're going to read those in and use those in our code here. I'm going to scroll all the way down to the bottom and we'll start down here with our mean function. And so what we need to run this code is a base domain. So, in this case, we're going to use google.com for our example. And then, we'll call this DNSSearch function, which is really just a helper function for when we're integrating this program with the rest of our reconnaissance infrastructure. So when we call this, it'll take the domain and a value called nums, which we're going to set to true, more on that in a moment, and it will call subdomain search with those two. And what it's going to return is a global dictionary that's going to map IP addresses to the subdomains associated with them. So once we maybe learn that there's a DNS server 8.8.8.8, we're going to say 8.8.8.8 is mapped to whatever the official name of that DNS server, something like ns.google.com. And so if we go to SubdomainSearch, this is what really runs our program here. So we saw up above, we have a list of subdomains and a text file. We're going to read through those and loop over them. And for each one of them, we're going to make a request for that particular subdomain. And this is also where that nums variable comes in. And so the thing is that safe, I just said a moment ago, we might have a name server called ns.google.com. And that's pretty standard for DNS server, but some organizations have multiple DNS servers. And so they might name them ns, ns1, ns2, etc. And so an easy way to identify some of those additional ones is to take that base subdomain of ns and append 1, 2, 3, etc, and see if those servers exist as well. And so that's what we're doing here with this optional nums value. We're going to loop over the range from 0 to 9 and just do, say, ns1, ns2, etc, .google.com, to see if those exist as well. And so up here, we're actually going to start taking advantage of our DNS infrastructure. So we've got our subdomain and our domain, we're going to stick them together so that instead of mail and .google.com, we have mail.google.com. And then with a call to DNS.resolver.resolve, we can get the DNS response for that particular request. And so this has a few different pieces of information in it. But what's most important to us is that there's going to be an IP address in there if the domain that we're requesting exists. If not, we're going to have an exception and we'll just give up because the server that we looked for doesn't exist. And this really isn't a problem for us, because we're essentially blindly guessing that an organization has named their servers in a particular way, and they actually have a particular server. So if we're looking for ns.google.com, and Google doesn't have a name server, then that's not going to exist. We'll get an exception, no big deal, we just struck out on that particular one. If we do get a result, then we need to loop over the answers in that result, because the DNS response can have multiple different answers to our query and we're going to pull out the IP addresses there. So each one of those answers in an IP address, we're going to convert it to text. So this will take it from a structure to or an object to the actual text or something like 8.8.8.8 as a string. And so, already we've learned something. We've learned that, say, 8.8.8.8 exists and it's ns.google.com or something like that. However, we can learn more from this as well, and the reason why is that it's not uncommon for you to use the same server for multiple things. For example, if you're a small organization and you need to have a mail server, a Web server etc, then a single computer can probably run all of those, especially for a small business. So you might be running your WWW and your mail subdomains on the same computer. And so it's possible that we didn't guess every subdomain for that computer. And so what we can do is perform a ReverseDNS lookup. And so as we said, we're going from domain to IP normally, now we're going IP to domain. And so with our ReverseDNS lookups, we'll provide an IP, and using socket.gethostbyaddr, we'll be able to get a list of domain names from there. And so the way this is structured, we're going to have a couple of lists and we need to put those two together to create what we actually want, is a list of all of the host names for that computer. And then, again, there's potential that will get an error, so we'll have an exception handler there, just tag an empty list. So by the time we've reached this point here, we've got a list of host names that we've extracted for this particular system. And of these, we know that most or at least the ones were interested in are going to end in .google.com. Certainly possible the other ones will be produced for there, but we're going to focus on that right now. And that's just for simplicity. We could look at every single hostname for a computer, and we might find that other types of domains are associated with that organization as well. But to narrow our focus and make sure that we're only looking at the section we care about, we're going to stick with our current hostname. So if everything ends with .google.com, all we really have to store for these computers is their subdomains, and again, that's going to become relevant later. So we'll loop over our hostnames that we've extracted from getting our original search and then also this ReverseDNS lookup. We'll test to make sure that they all end with .google.com. If so, we're going to use the rstrip function to strip off that .google.com and give us just our subdomain. And so then at the end, we're going to have a list of those subdomains associated with a particular computer. And we like that because if we know, say, that this computer has a www subdomain, we should probably check out ports 80 and 443 because there's probably a service running at those locations. And potentially, it might be worth checking 8080 and 8443, the common alternative Web servers. In contrast, if we have mail subdomain, then we want to look at something like 25 etc. And so once we have our list of subdomains, we're going to store that list of sub domains in our host variable up here. And in the case where this IP address has already shown up once and we've already added it once, we're going to merge our lists. Otherwise, we're just going to add our list of subdomains for this new IP. And so when we return from DNSRequest, we've got a dictionary built up here that has all of the IP addresses we've been able to discover and their corresponding subdomains. So we returned from that, we return here, and we make it back to DNSSearch, where we're going to return that global dictionary. And so in this case, for our demo, we're going to run this using our little mean function down here. When we start linking this into automate our reconnaissance process, this mean function will go away and we'll call DNSSearch directly. But now, let's take a look at how this works out in practice. So in the correct directory, so if I do python DNSExploration.py, hit Enter, we're currently querying that DNS infrastructure for all the various permutations of our subdomains. And so in just a moment, we're going to get results back showing us what we've learned. And here we go. So we've got a few different options here. So we've got several different WWW subdomains. And so it's a good sign that we activated that nums variable here, because, apparently, www.google.com is different than www4.google.com, is different from five, six, and nine. We also see a mail.google.com, a blog.google.com. And then we've got a few different DNS servers here. If we look further down, we've got a few more. And so every time I've said ns.google.com, it's 8.8.8.8. I'm wrong, it's dns.google.com. Got a couple of SMTP servers, an admin.google.com, that's interesting, some VPN endpoints, and a few other subdomains down here. And so, in the end here, we've got a fair amount of information about google.com's infrastructure based off of just talking to the DNS server. However, this isn't going to be an exhaustive list. Obviously, Google has a lot more than the couple dozen of IP addresses we see here. Their infrastructure includes a lot of systems that are in their back-end network that they're not going to advertise publicly. There could be DNS records for google.com that we didn't look up here because we didn't guess the subdomains, etc. However, at the end of this, we've got a good starting point for our investigations because we know what a few of their computers are and what they're supposed to do, which helps us target our future reconnaissance on these systems. Thank you.
