[MUSIC PLAYING]
DNS zone transfers-- welcome to the active information
gathering phase or section of this course.
We're going to be starting off by taking a look at the DNS
zone transfers.
Now, before we do that, we need to get an understanding as
to what DNS is, and how DNS servers or name servers work,
and more specifically, how they can
be abused by attackers or penetration testers
to obtain more records from said DNS server
for a specific domain or target, if you will, but more
specifically, a domain.
All right, so what is DNS?
And there's a good reason why I'm
covered I'm covering this now, as opposed
to when we were performing passive DNS reconnaissance.
Well, DNS stands for Domain Name System.
It is a protocol that is used to resolve domain names or host
names to IP addresses.
Now, why is that important?
Well, during the early days of the internet,
users would have to remember the IP addresses of the sites
that they wanted to visit.
Because when you type in google.com into your browser--
into a modern web browser--
your web browser really doesn't know what google.com is,
because the actual server that's hosting the website
doesn't have a domain name or cannot be natively accessed via
a domain name.
It has an IP address.
And that's how you typically interact with it
on a network level.
Well, this is where DNS comes into play.
So DNS was essentially created to solve this issue,
among many other issues.
But it essentially allows your browser
to resolve an IP address or a domain name to an IP address.
So when you type in google.com in your browser,
your browser says, OK, google.com.
It then makes a request to the DNS server
that your system has been configured to use.
And it says, hey, this user here is trying to access google.com.
Could you please tell me the IP address of google.com
so that I can make a request to that IP address?
And then, the DNS service says, OK, google.com--
I have that here.
Here's the IP address.
And the browser then makes the request.
The web server then responds with the web page,
and it's then rendered in your browser.
So as I said, during the early days,
when you had to type in IP addresses--
IP addresses are very difficult to remember,
because they're numbers.
And human beings remember names instead of numbers,
so that's why we have domain names.
So google.com is a domain name.
Easy to remember.
You'll pretty much never forget it for the rest of your life.
It's much easier to remember an address like google.com
instead of 172.56.91.2, or whatever the case.
So what is a DNS server, also known as a name server?
Well, a DNS server is essentially
like a telephone directory that contains
domain names and their corresponding IP addresses
amongst or among many other records.
So believe it or not, you currently use a DNS server.
Right now, where or what DNS server
you use is primarily based--
or is primarily dependent on your internet service provider.
So if you ever log in to your router,
you should see that a DNS server IP address
has been provided there.
So that means that all requests going through that router
will essentially go through-- or all requests will
be made to that DNS server.
Now, there are a plethora of public DNS servers
that have been set up by companies like Cloudflare.
Their DNS server address is 1.1.1.1.
And Google, for example, their DNS server is 8.8.8.8.
These DNS servers are very popular,
primarily because they contain records of almost all domains
on the internet.
So again, the domain--
the actual DNS service provided to you
by your ISP pretty much contained most or all of the--
they contain records of almost all
of the domains on the internet.
But individuals typically utilize
Cloudflare, like myself.
So within your operating system, you
can actually configure what DNS server
you want to use for requests.
So on Windows, you can click on the Networking options
and modify your adaptor options to essentially make
requests to any of these public DNS
servers provided to you by Cloudflare or by Google,
for example.
Or you can use the default ones set or configured
within your default gateway or your router,
which I'm going assume is going to be the case for most of you.
All right, so what is typically contained
on a DNS server or a name server,
for lack of a better word?
Well, we have records.
So I've mentioned these records previously
during the passive information gathering
section of this course.
So we typically-- these are a list of DNS records.
It's not by any means exhaustive,
but we typically have A records, which resolve
a hostname to a domain name--
or sorry-- resolve a hostname or domain name to an IPv4 address.
So when we were utilizing DNS recon or a tool like host
can be typed in, for example, hosthackersploit.org.
It would essentially provide us with the A record
for that domain name, which is the IPv4 address.
When you see the AAAA record, that resolves the hostname
to an IPv6 address.
When you see NS, that's essentially
reference to the domain--
the actual domain name server.
You then have the MX record, which resolves the domain
to a mail server.
We then have CNAME, which is used for domain aliases.
TXT is a text record.
The HINFO-- that's used for host information.
And then you have SOA--
the SOA record, which is very important.
That is the domain authority.
You also have the SRV record, which is the service records.
And then, of course, you have PTR, which resolves an IP
address to a host name.
So these are records that are typically-- that you typically
find whenever you're dealing with DNS
or whenever you're performing DNS reconnaissance,
regardless of whether it's passive or active.
So what is DNS interrogation?
Because what we are primarily doing here
is performing DNS interrogation.
Now, remember, this is an active reconnaissance technique.
DNS interrogation is the process of enumerating DNS records
for a specific domain.
Now, we had done this previously with tools or sites
like DNSdumpster.
However, the process with that--
the problem with that is that will only give you so much
with regards to A records or MX records.
The objective of DNS interrogation
is to probe a DNS server to provide us
with DNS records for a specific domain,
more specifically, additional records that we might not
have had access to previously.
Now, this process can provide us with important information
like the IP address of a domain, subdomains,
or mail server addresses, et cetera, et cetera.
Now, how can this--
how can we obtain more records from a DNS server
with regards to a particular domain?
This is where DNS zone transfers come into play.
So in certain cases, DNS server admins
may want to copy or transfer zone files from one DNS server
to another.
A zone file is essentially a file
that contains records pertinent to a particular domain.
And when they want to do this, they
utilize a functionality called a zone transfer.
Now, if this is left misconfigured and unsecured,
this functionality can be abused by attackers
to copy the zone file from the primary DNS server
to another DNS server, typically our own.
And a DNS zone transfer can provide penetration testers
or provide us with a holistic view of an organization's
network layout.
Furthermore, in certain cases, internal network addresses
may be found on an organization's DNS servers.
So we may be able to find additional subdomains
for the company's internal network, et cetera, et cetera.
This is something that you'll see.
We will be targeting the zonetransfer.me website.
So again, you can do this on your own Kali Linux
VM or your own penetration testing distribution.
I'm just going to switch over to my Kali Linux VM,
and we can get started.
This will make sense as we actually
go through the process, and I'll just
show you the difference between performing passive DNS recon
and active DNS recon.
And then, we'll take a look at how
to perform a DNS zone transfer to obtain
more information or more records from a DNS server regarding
a particular domain.
So I'll just switch over.
All right, so I'm back on my Kali Linux VM.
And I'm currently on the zonetransfer.me website.
So as you can see, this website was set up
to teach students about DNS security
and, more specifically, problems related to DNS zone transfers.
So again, this is a really, really cool resource
that you can use.
It's publicly available, and they've provided you
with permission to use it.
So you should be good on that front.
So again, this will give you a rundown
as how to perform a DNS zone transfer with a utility called
a Dig, which we will be exploring.
Now, if we go to dnsdumpster.com and we type in zonetransfer.me,
which is the target website--
so zonetransfer.me.
And I'll just click on Search there.
You'll see that it's going to provide us
with the DNS servers, or the name servers, if you will.
So this is the primary one, and then there is a secondary one.
And it provides us with both of the name server or DNS server
IP addresses.
And then it provides us with records like the MX records,
which is used to resolve mail servers, and then TXT records
and the hostrecords, which are A records here.
So you can see passively, this really doesn't give us
much information.
And the same can be obtained with a tool like DNSrecon.
So we say, dnsrecon, d, zonetransfer.me.
We'll give this a couple of seconds.
And I'll just zoom in here.
So you can see, this will give us more records.
But you'll actually see what I'm talking
about in a couple of seconds.
So this will try and enumerate all of the DNS records
that I mentioned.
And in this case, it looks like we
have an error when it's enumerating SRV records, which
is perfectly fine.
That's a problem with the tool.
But you can see, we get the SOA record here.
So as you can see here, that's the SOA record.
The SOA record is the domain authority.
And then, of course, we have the primary name server here
and then, of course, the secondary name server.
So we have nsztm1.digi.ninja and then
the corresponding IP address for that particular name server.
And then, we have the MX--
the MX records here.
This is the mail server for this particular domain.
And then, of course, we have the A record,
which points to the IP address of the web server
if it's not being protected by a proxy or web application
firewall, which we covered in the previous section
of this course.
Now, again, you can also utilize other tools like, for example,
Dnsenum, which we'll get to in a second.
So we type in dnsenum and then help--
the reason why it did not cover Dnsenum
is primarily because this also performs
active DNS reconnaissance which, again, is valid now
but was not valid when we were performing passive DNS
reconnaissance.
So Dnsenum can essentially enumerate the records
that are publicly available.
And in addition to doing that, it
can also be used to perform a DNS zone
transfer automatically, which is really great.
And it can also be used to perform
a DNS brute force, which can be used to identify records--
more specifically, subdomains, at least from my experience--
by performing a brute force and trying
to identify records that way.
But that's not something that we'll
be exploring in this video because it's
beyond the scope of what we are covering.
Now, one thing that I wanted to point out that's very important
is before DNS, your computer would typically
utilize the hosts file.
Now, the hosts file is present on all operating systems.
On Linux, it's stored under the--
let me just open it up with Vim.
It's stored under the etc, and it's the hosts file here.
So if I open this up-- and I'll just provide my password
with Kali-- this contains a list of host names, firstly,
and their corresponding IP addresses,
as well as domain names and their corresponding IP
addresses.
Now, because we don't really need the host file
in this case, you can see that we don't have any mapped domain
names to IP addresses.
But that's one way that users or individuals who are typically
navigating around the issue of not having
a system to automatically resolve domain names to IP
addresses.
So this is sort of like your local DNS server, if you will.
But it's good not to think about it in that way.
So I'll give you an example.
So let's say on my local network,
the IP address of my router is 192.168.1.1, which it is.
You can see it redirects me to the admin panel of my router.
I need to remember this IP address to access the admin
panel.
But I can also, within my hosts file,
map this IP address to a local domain.
Remember, this is local, which means it cannot be accessed
on the internet because this record is not present on public
DNS servers.
So in order to do this, I would say 192.168.1.1,
and you can try this on your own network.
And I can say--
I can map it to the following local domain.
So I can say router.admin.
All right, so I'll right and quit.
And now, if I open up a new tab here and I say router.admin,
you can see it resolves to that local IP address.
So you can now see how DNS works.
And this is something that I just wanted to point out.
So fairly simple to understand, and we can actually
perform a few tests on it before we take a look at how
to perform a DNS zone transfer.
So again, you can utilize the hosts file whenever
you want to add custom--
or whenever you want to map a specific domain to an IP
address.
So I'll just get rid of that there,
because I don't really require it, and I'll right and quit.
All right, so let's talk about zone transfer.
So I'm just going to go back to zonetransfer.me.
And you can see that the domain is zonetransfer.me,
and the two name servers are nsztm1.digi.ninja and
nsztn2.digi.ninja.
Feel free to use this domain in your training,
et cetera, et cetera.
So we can easily perform a DNS zone transfer.
Now, in order for this to work as I mentioned in the slides,
the DNS zone transfer functionality
must be enabled on any one of those name servers, primarily,
the primary DNS server, or name server, if you will.
Now, as I said, we can do this automatically using
a tool called Dnsenum.
And we can say dnsenum zonetransfer.me and hit Enter.
All right, so we'll give this a couple of seconds
and the reason for that is very important.
All right, so it's performing a brute force automatically,
which is not something that I wanted to do.
But I'll explain a couple of things.
So you can see that, firstly, it'll
give you what we could publicly access previously
or passively access.
We have the host address.
This is the A record, which points to the IP
address of the web server.
You then have the name servers here and their respective IP
addresses.
And then you have the mail servers.
Now, it's going to try and perform a zone transfer
and will get the bind versions.
Now, you can see the zone transfer is successful,
and it performs it on this particular name server.
And it provides us with all the records
that were stored on that name server.
So now, in addition to getting just this information
like these A records and MX records,
you can see we get other records here.
So for example, we have a few TXT records that we could not
access previously.
We also get a PTR record.
We get a subdomain here.
And in this case, we'll actually get into that.
But for example, this one looks potentially interesting.
So it looks like they had a subdomain called canberra
office.zonetransfer.me.
The A record points to this particular IP.
So that's something that we couldn't identify previously,
and that's something that we also could not
identify by performing subdomain enumeration
with a tool like Sublist3r, which was doing it passively.
So you can see that we aren't able to access this
on the internet, which pretty much means that this
is an internal DNS record.
So this could possibly be referring to--
or this could possibly be pointing to an IP address
within the company's internal network,
which is a huge security issue.
We also have the following record,
which is a TXT record, which essentially just provides us
with the following information.
In this case, it's cmdexec.zonetransfer.me.
We can try and access that.
And of course, this is-- you can see, server not found, which
makes sense, because that's a TXT record.
And you can see there are a couple of interesting pieces
of information that have been added in the TXT records here.
So for example, Hi.
As I said, this was set up to show you how
to perform a DNS zone transfer.
So you can see that we have a few--
these are the actual name servers here.
And these are their corresponding domains--
so internal.zonetransfer.me, me which pretty much confirms what
we were already saying that some of these subdomains may be--
some of these records may be pointing or resolving
subdomains to internal network addresses and vise versa.
And then, of course, you can see we
have a couple of other subdomains that point to A--
that our A records here, or IPv6 addresses, or AAA records,
and so on and so forth.
We can also see that, for example,
staging.zonetransfer.me has an alias of sydneyoperahouse.com,
which means if we try and access staging.zonetransfer.me--
and I think that this will work.
Because it's a CNAME record, it'll redirect to--
let's see.
It will redirect to sydneyoperahouse.com,
which in this case, it looks like it failed.
But that could primarily be because this
is an internal record.
Most of them appear to be--
that appears to be the case for most of them.
And then, of course, you can see there's a couple of other ones.
It also then performs zone transfer
on this particular name server here.
And in this case, it looks like we
get a couple of other records that we
weren't able to get previously from this one.
Or it actually looks like it's pretty much the same thing.
So nothing new there.
Or we can try and maybe access office.zonetransfer.me.
But you get the idea.
This is very important information, because,
as I said, if we are able to get internal IP addresses,
then we pretty much are getting a very good idea
as to what the internal network infrastructure looks like.
And we're identifying subdomains that
might be useful once we gain access to the target network.
So that is how to perform a DNS zone transfer with Dnsenum.
Now, you can also perform a zone transfer with Dig.
If you're not familiar with what Dig is, I can just type in,
for example, what is Dig?
And you can see, Dig is a DNS lookup utility.
So you can take a look at the usage instructions here.
We need to specify the name server and then
the actual domain, which is our target.
So we can essentially type in dig and then axfr--
that is the zone transfer switch.
And then, we specify the actual name server here,
which in this case, let's see if we can identify that there.
So let's try this one first.
And then, we have zonetransfer.me.
All right, and as you can see, we
have performed the DNS zone transfer with Dig.
And I really like using Dig, because the problem with a tool
like Dnsenum is it performs a lot of checks and most of which
you can really control and then goes ahead
and performs a DNS brute force.
But in this case, you can see we get different types of records
that, firstly, we were able to get publicly and then,
of course, internal ones here.
So yeah, that's how to perform a DNS zone transfer.
And some of these may be public.
These domains may be--
some of these domains may be accessible on the internet,
which means you can also target them or add them
to the scope of the systems that you're testing.
So you can test them out for yourself.
So for example, vpn.zonetransfer.me.
Let's see if that works.
Some of these servers may not be hosting anything,
primarily because that's not really
the objective of this project.
But yeah, that's how to perform a DNS zone transfer.
Now, one thing I want to point out
is, let's say we say a dnsrecon d hackersploit.org.
Now, in my case, I'm using Cloudflare as my--
I'm using Cloudflare.
So the name server will point to--
the name servers will essentially
be the Cloudflare name server.
So for example, if I wanted to perform a DNS zone transfer
on hackersploit.org, maybe with a tool like Dnsenum,
I could just specify that here.
And of course, this will fail, because zone transfers have
been disabled or the Cloudflare, name servers, or DNS servers
do not have that option configured,
because they know how to secure things correctly.
But if I type that here, you can see
that the zone transfers fail.
And then, it'll start performing a DNS brute force.
And you can actually view the actual file or the word
list that is it is using.
And let me explain what's happening on that front.
So if I cut out the content of this file,
you can see that it's going to--
in this case, there's quite a few words here.
And in my case--
in most cases, the DNS brute force
can be used to identify different types of records,
primarily subdomains, as that makes the most sense.
And of course, you can utilize a tool like Dnsenum,
or you can utilize a tool like Fierce,
which I'll cover right now.
So let me just clear my terminal.
And if I type in fierce, you can see
that it doesn't give us any information regarding the tool.
Does it have a main page?
No, it doesn't.
If I say fierce and I open up the Help menu here,
you can see that Fierce is a semi-lightweight scanner that
helps locate non-contagious IP space in hostnames
against specific domains.
It is really meant as a precursor
to Nmap, Unicorn scan, Nessus, Nikto, et cetera.
Since all of those require that you already
know what IP space you're looking for,
this does not perform exploitation
and does not scan the whole internet indiscriminately.
It is meant specifically to locate likely targets
both inside and outside a corporate network.
Because it utilizes DNS primarily,
you'll often find a misconfigured networks
that leak internal address space,
as we were able to do with the zone
transfer-- for zonetransfer.me.
And that's specifically useful in targeted malware.
So to perform the brute force with Fierce,
it really is very, very simple.
You simply specify-- you simply type in fierce and then dns,
and you can then say, for example, example--
or in this case, we can type in zonetransfer.me.
And this will not perform a DNS zone transfer
and then specify the word list.
So if I hit Enter, it performs the zone transfer,
but you can also disable that if you wanted to.
So I believe there is a switch for that.
So for example, if I wanted to perform a DNS brute force
on hackersploit.org in order to identify other records that we
might have missed and, more specifically, subdomains,
you can see that the DNS zone transfer fails.
And it's going to check for wildcard DNS.
That, of course, fails, and then it's
going to perform the following amount of tests
based on the entries contained within the default word list.
Now, this is going to take a while.
And this is definitely active information gathering,
because you're now actively engaging with the target.
And you can see in this case, it's already
been able to obtain subdomains.
And this is something that we had
trouble with when we were performing passive DNS
reconnaissance.
So it provides us with the--
in this case, it looks like we have two A records
for community.hackersploit.org, which probably means
that it is behind a Cloudflare again
and that this isn't being protected by a proxy.
So that is going to conclude the practical demonstration
site of this video.
All right, so that concludes the active DNS recon section
of this course.
We have covered DNS reconnaissance quite a bit.
We're now going to turn our attention
to performing scanning.
And more specifically, we're going
to be starting off by taking a look at how
to perform host discovery on a network
that you've gained access to.
So we're now going to assume that you have gained access
to a target network.
And this is pretty much the case for when
you're performing a penetration test on an internal network
and you're provided with access to the internal network.
So your first objective is to identify all systems
on the network.
And we're going to be taking a look
at how to do this with Nmap.
So I'll be seeing you in the next video.