CompTIA Pentest+ PT0-002 – Section 4: Passive Reconnaissance Part 4

30. DNS Information (OBJ 2.1)

There is a lot of information you can gather from the domain name system. Now, we’re going to talk about each of the different record types that we have inside of DNS and the purpose of DNS, but we’re not going to do a really deep, deep dive here because you should already know this information from back in your network plus studies. If you don’t, please go back and review this type of information because, again, information from Network+ and Security+ is considered assumed knowledge at this level when you’re taking PenTest+ and you’re getting ready for your exam.

Now, when we talk about the domain name system, or DNS, it’s really a system that’s used to allow you to access a network client by using a human readable host name instead of using its numeric IP address. For example, if you want to visit my website, you can simply type in diontraining.com into your web browser, and in the background, your computer is going to translate that into whatever IP address is hosting my server right now.

Now, that’s all done because there’s an A record that is associated with diontraining.com and that is spread around the internet, through all of the DNS servers, so everybody can know how to access it. Now, when we talk about domain names, there is a lot of critical information in here that you can get. As you look at the domain names, you’re going to be able to see a lot of different records and a lot of sub domains and domains that are associated with a particular domain name, like diontraining.com. For example, if you go and look at all of the DNS records that are out there for diontraining.com, you’ll see we have a bunch of different types, starting with an A record.

Now, an A record stands for an address record, and an A record is used to link a host name to an IPv4 address. If you’re using IPv6, we have what’s called a four A record, and it’s written as A-A-A-A, and this links directly to an IPv6 address instead of an IPv4 address. Either way, when you’re using an A record or a AAAA record, you are linking a human readable name to an IP address, either in IPv4 or IPv6. Now, another way that we can link a human readable address to a server is by you using a CNAME record.

Now, a CNAME record stands for the canonical name record, and this is used instead of an A record or a AAAA record if you want to point a domain name to another domain name or sub domain, instead of having to point it to an actual IP address. For example, I have many different website domains that I’ve bought and used over the years, and some of them we don’t use anymore, but we still link them back to our main Dion Training website, so that way, if somebody uses the old domain name, it’ll redirect them automatically to our new, current domain name. And to do this, we use CNAME records. For example, I own a website domain called itil4exam.com. If you type in itil4exam.com, it will redirect you right back to diontraining.com because I have a CNAME record set up at itil4exam.com that points directly to diontraining.com.

The next type we have is known as an MX record. Now, an MX record is a mail exchange record, and we use this to direct emails to a mail server. This can be used to indicate how email messages should be routed around the internet when you’re using the simple mail transfer protocol, or SMTP. When we use a mail exchange record, we’re actually pointing to another domain name and not an IP address.

For example, if you look up diontraining.com and you look at our mail records, you’re going to see they’re actually pointing to Google’s mail servers because they run the email for diontraining.com. Next, we have an SOA record, which stands for the start of authority. Now this record is used to store important information about a domain name or a zone, and a zone is really all of the information about a given domain name, including its A records, CNAME records, MX records, and other types of records.

When we’re talking about an SOA record, we’re basically saying, “Who is responsible for this domain name?” in the case of my website, diontraining.com, we are responsible for it, and so our start of authority record tells everybody that our server is going to be the authoritative server for the domain name at any of the records.

The way DNS works, if you think back to your earlier studies, is that there is a central server for any domain name, but that one server doesn’t make all the requests for everyone in the world. So instead, it creates the official records and the distributes those out to other places. And so we have to know who is the person who’s authorized to make changes and distribute the original new copy that goes out to everybody else around the world? And that’s what an SOA record does.

Next, we have pointer records, which are written as P-T-R. Now, a pointer record is used to correlate an IP address with a domain name. And this is basically the opposite of an A record. With an A record, we went from host name to IP address, but with a pointer record, we’re going from IP address to host name. This is always stored under the format of .arpa, which is the top level domain we use when we’re dealing with these pointer records. The next type of record we have is known as a text record, or TXT record. Now, a text record is used by domain administrators to add text into the domain name system.

Now, this allows us to have machine readable data that’s added into records, and we do this for all sorts of different reasons, including be able to say that this domain is authorized by me to allow some other service to use my domain name. For example, if you send an email to support@diontraining.com, it’s actually not going to my email servers. It’s actually going into my support system. And that support system has been given permission to send emails on behalf of diontraining.com by having a special text record that shows I authoritatively own this domain, and I’ve given permission to that service to send emails on my behalf. Next, we have a service record, which is known as an SRV record.

These are used to specify a host and a port for a specific service. For example, I can specify a port and an IP address that’s going to be used for a chat server by using a service record. Or if I want to set up something for VoIP services, I can do that with a service record as well. Finally, we have an NS record. This is the last record we’re going to talk about. Now, an NS record is a name server record. This is used to indicate which DNS name server is going to be the accurate one for the domain.

Let’s say, for example, you decide to host a new blog, and you decide to buy a new website with a new domain name. Wherever you bought that will normally serve as your name server. But you may want to switch out to a different provider later on. And so you might go from GoDaddy to Google Domains, and you’ll have to change your NS records to say Google Domains is now the correct place for my domain names.

Now that we’ve covered the basics of DNS and the different record types we have, we need to talk a little bit more about DNS and how you’re going to use it as a penetration tester. Now, as a penetration tester, in the reconnaissance phase, one of the things I want to do is pull up all of your DNS records and look at them because that’s going to give me addresses for servers, whether in the host name form or an IP address, as well as being able to see what kind of services you may be using.

For example, if you looked up diontraining.com, you’re going to be able to see what type of web server we have, what type of email server we have; what type of record server we’re using for all of our domain names; what kind of services we might be using that are third party to us, like software as a service, cloud-based tools, like Freshdesk for our support desk Slack for our communications, and other things like that.

All of this can be found from those different records types. Specifically, you want to focus on the MX records for any kind of email services, as well as the text records and service records, to be able to see any third party, software as a service type solutions that that person may be using. Now, when you look at these DNS records, you’re going to find all sorts of great additional targets that you can actually look at that you may not have discovered otherwise. So it’s a good place to do your reconnaissance at.

Now, to look at these DNS records, you have to use a tool to do that, and you’re going to query those records and be able to see the information inside of them by using these different tools. Now, one of the most common tools that’s used is known as nslookup.

Nslookup is a cross-platform tool that operates on Windows, Linux, and Mac systems and allows you to query a domain name server and then get information back in the form of those different record types. Some other tools you can use for this purpose are things like dig and host. Like I said, there’s lots of different ways to query these records, but these are some of the most common command line tools.

Now, when you’re querying these records, you do want to gather that information as part of your open source intelligence and add it into your wiki or your spreadsheet for all the data you’ve been collecting because these are all potential targets, depending on the size and scope of your engagement. Now, in addition to finding out this technical information inside of your DNS records, you can also find out information about the domain and who owns it. To do this, we’re going to use a tool known as whois.

Now, whois is a command line tool on Linux systems, but it also exists as a website that you can go and use to actually pull this information. Now, when you pull up a typical whois record, you’re going to get a lot of information in there, including who registered that domain name, the name and address of the organization who owns that domain, the email address and phone numbers of the person who registered that domain, as well as the technical points of contacts, billing points of contacts, and other administrative points of contacts.

Additionally, you’re going to be able to figure out who the domain’s registrar is, which could be something you might want to use inside of a spear phishing campaign or a phishing campaign because you can send emails pretending to be that registrar. In addition to all this, you’ll also find out the status of the domain, which means you’ll be able to figure out when it is up for renewal, deletion, transfer, or other related information.

And finally, you’ll figure out what are the named servers that are being used by that domain? With those name server records, you can actually conduct a zone transfer of the DNS records from the name server onto your local machine, so you can analyze them offline as well. This is another way that people do this in reconnaissance, but that is more of an active phase than a passive phase because you’re now touching somebody else’s server.

Now, one of the things I do want to mention about the whois information is that it’s not nearly as valuable these days as it used to be. In the old days, there was no privacy protections for the information in a whois database. It was all public source open knowledge that anybody could look at. But these days, people can pay a little bit extra to have their information kept private. And by doing that, the organization will have it say “Privacy blocked” when you’re looking for the email, phone number, or names associated with a given record. Even though that’s the case, it’s still a good idea to look at the whois records because some people are too cheap to pay for that privacy, and there’s other ways to find that information out, by linking with other sources of open source intelligence that you can then find online.

31. Reconnaissance with CentralOps (OBJ 2.1)

CentralOps.net and sites like it are a wonderful resource for the hacker, as it helps to provide some anonymity during our assessments. CentralOps allows us to create a domain dossier or email dossier on our victims, gathering openly available information, such as the owner of the domain names, the technical contacts, technical details, and the network ranges involved. This is key information that’s required for us to gather as we attempt to understand the victim network and plan our attacks. We can use CentralOps from any computer with a web browser. And since we already have our Cali machine connected to the internet, that’s what we’re going to use. So from our Cali machine we’re going to open up Firefox. From here, we’re going to go to CentralOps.net. So once we get to CentralOps.net, we’re going to go to the domain dossier. So now we need to pick a domain to look up or an IP address. For our example, I’m going to use AVG. So AVG is an antivirus company located in the Netherlands. So we’re going to look them up and we’re going to choose all five options. We want the traceroute, the service scan, the DNS records, the whois of both network and domain.

And then hit go. So the first thing we’re going to see is our address look-up. And this is just going to do a basic check of the name to the IP address. In this case, AVG will resolve to two different IP addresses as displayed here on the screen. After that, we’re going to see the domain whois record. Now with a large company like AVG or a Yahoo or a Google or somebody like that, you’re not going to get as much detailed information as you would if you had a small business. So in this case, we can look at who they registered their domain through, which in this case was Mark Monitor, Incorporated. So we can see that and that might play into a spear phishing campaign but it’s probably not real helpful for us right now. We’re going to go ahead and scroll down even further. The next thing we’re going to come to is the detailed whois record. And in here we’re going to see the registration information, we’re going to see who the person is registered to. In our case, since it’s a large company they just put in Domain Administrator. If it’s a small business, you’ll usually see the owner of the business’ name or their technical support people. You also will get information such as where they are. In this case, they are located in Amsterdam with the street name listed there.

You also get phone numbers. This can be useful as part of a pretexting campaign as well. And you’ll get an email address. In the case of a large company like this, they probably are not monitoring this address but it’s domainadministration@avg.com. If we had somebody’s username in there, for instance, Jason.Dion@avg.com, that could tell us the naming structure for email addresses that could be useful in a spear phishing campaign or a good point of contact to use as part of a spear phishing campaign, such as the technical registration point of contact. If we had that information we can use that as a way into the network. We’re going to continue scrolling down, see what else we can find. Again, Domain Administrator, Domain Administrator. Not the most helpful thing, cause again, this is a large company. One of the things I noticed that’s kind of interesting is their Name Servers. If you notice they’re using akam.net. Akam is actually a large network service provider. They actually can help prevent denial-of-service attacks from occurring. So if that was going to be our strategy to take down this network, it may not work as well. If they’re a small business they’re probably not using Akam, and that may be a way that you can take down their network. But again, a denial-of-service is never used in ethical hacking, there’s really no reason for it. But it’s something we can consider using our research here. We’re going to go down to the network record. Now the network whois is a little bit different. You’ll notice here, it actually gives us a range, 93.184.217.0, up through .31 is actually being owned and operated by AVG.

That means they have 31 IP addresses, 30 of which are routable on the internet. That is 30 possible targets, whether they’re routers, firewalls, or actual servers tied to internet, that we could be looking at. If that is within the scope of our assessment. As we go down a little bit further, you can notice who actually registered for these IP addresses, Derek Sawyer. So again, that can be a name that we can use as part of a pretexting campaign. It might be a name that we use as part of an email phishing campaign. Lots of different uses when we find good names and good email addresses for people. We’re going to go down into our DNS records next. So in our DNS records, you’ll see the DNS records for avg.com. There’s two address records, as we saw earlier, we see 93.184.217.9 and then we see 93.184.211.28. These are two different servers that are answering up for the name avg.com. This is probably being done because AVG is such a large company. One server couldn’t handle the load so they have two servers that are acting as content switches to provide that service to their customers.

And then again, we see akam.net as the name servers answering up. So again, it’s going to be load-sharing and helping to handle a large amount of load that would come against those servers. Next, we’re going to look at traceroute. So it starts out from the servers at CentralOps and goes out across the internet until it finds where it’s going. In this case, once we get to the star, star, stars in line 10 through 13, that’s usually where it hits firewalls and some companies will not respond to pings or traceroutes. And the reason why is they don’t don’t want you mapping their network. So we know they have at least some firewalls and some border security there. Again, we already figured that out because of the akam.net being the ones answering up for their domain name, so we know that they’re pretty secure. Now we’ll move on to the service scan. And here in the service scan you’ll see that FTP timed out, SMTP timed out, web-browsing port 80 is open, pop servers, IMAP server and HTTPS all have timed out. And this is pretty typical using a large company like AVG. So let’s do another domain dossier. This time, we’re going to use a small business. From domain dossier, I’m going to go to TitanCipher.com. And I’m going to use service scan and traceroute and then hit go.

Now TitanCipher.com is a domain that I own. It’s hosted on a small server. It’s used on a WordPress platform, which is actually hosted by Bluehost. And as we go through, you’re going to see that. It’s going to look a lot different than the AVG answers we got last time. So in this case, we have a single IP address which is answering up for TitanCipher. If we go into the domain records, you’ll see that it’s Bluehost.com, that tells me who they’re using. And the fact that they’re using Bluehost tells you they’re probably using WordPress as their platform because Bluehost is known for that. So if you can find vulnerabilities in WordPress, you can then use those against that particular domain. Next we’re going to scroll down and you’ll see more information about the actual person who owns it. Their name, their address, their phone numbers, their email addresses, all information that could be useful. Again, for a spear phishing campaign or something of that nature. Network whois.

So network whois, again, that’s going to show us who owns the IP addresses. In this case, it’s actually owned by Unified Layer Networks. They own a large block, then they’ve given part of that block to Bluehost, who then gave a single IP to TitanCipher.com. So if you notice here, they have a class A address. So with a slash-16, they’re going to have over 64,000 IPs. You don’t want to just go in there blindly and scan 64,000 IPs if you’re targeting one, TitanCipher.com. It wouldn’t make any sense. So this is going to help you identify who owns the network and what parts of the network there are. We’re going to scroll down a little further. And we’re going to find the DNS records. Now the DNS records here are going to show us that there’s a name server answering up, Bluehost.com. TitanCipher is being answered up by Bluehost, who is their provider. They do have a mail server, mail.TitanCipher.com. They do have a second name server on Bluehost. We also see their A records, which is their IP address. Next, we can look at the traceroute. This traceroute, you see, looks a lot different than the traceroute we saw with AVG. In this case, everybody has answered up.

We get both the IP addresses and the fully qualified domain names. So we know every single piece between CentralOps and that particular server that’s answering up. Now notice the last server that answers up, that .193. Something quite interesting here. When it resolved it didn’t resolve to TitanCipher.com. Can you guess why? Well, the reason why is that this shows us that it’s a shared server. It’s not owned exclusively by TitanCipher. In fact, it’s owned by Unified Layer, who owns Bluehost. So there may be 20, 30, 40, 50 different websites on this particular server. TitanCipher is just one of them. Now that’s important to know because if you try to hack TitanCipher.com, you may not be hitting TitanCipher.com. You may be hitting some of these other servers in there. And if you do that, you’d now be breaking the law because you were only hired for an assessment by this one company. So you have to be very careful when you start looking at where they’re hosted. This is really important information when we look at the domain dossier. Next, we’re going to go down to our service scan. In the service scan, you’ll see that they’re using FTP. That’s a known vulnerability for us.

And it even tells us what type of FTP. In this case, Pure-FTPd server. That’s an important piece of information that we could use if we were going to hack this company. SMTP times out, therefore it’s not answering up for SMTP. That’s good to know. Don’t throw any SMTP attacks. They are running a web server. They’re running nginx 1.10.2. We now know the version number and the software they’re using. That’s useful to find vulnerabilities. Again, all we’re doing here is information-gathering at this point. Pop3 server does answer up, so there is something listening there. IMAP-143, another mail server. It’s answering up as well. Things that we need to take note of. If we get into their secure site, we see port 443 secure HTTP server. So a secure HTTPS, we can see their SSL certificate here. They’re using a sha256RSA token as their server validation. That is information that can be useful. Bluehost.com is the ones who gave them that information. So we might be able to use that as part of a spear phishing campaign again. You can see the fact that we have Apache running as the server.

You see that there at the bottom, HTTP/1.1 200 OK. Server: Apache. Again, more information that we want to take note of. They also have a PHP session ID. That’s something else that we could take note of. We see JasonDion.com/wp. WP usually stands for WordPress, so that can be vulnerabilities we could take care of. So these are all different things that we can look at as we move forward in our exploitation later on. The next thing we’re going to look at is our email dossier. And we’ll just click on that. And then we’re going to give an email address that we want to test out. If we had email.test@hotmail.com, for instance, let’s see if that’s a valid email address. Click go. We find out that it is a bad email address because it was rejected by the server. Now instead, if I use an email address that I think is valid, for instance, TitanCipher@gmail.com. Hit go. We’ll see that this passed the validation test. As we scroll down, we’ll see that it actually found the MX records for Google for that particular address. And when it tried to make a connection of our SMTP to Google to say does this email address exist, we can see that it did come back and say that it was successful.

Right here, showing us that that was a good, valid email address. Let’s try another one. What if we had one like… TitanCipher23@gmail.com? Let’s see if that’s a valid email address. We hit go. Bad address, does not exist. So if we tried to start sending spear phishing emails towards TitanCipher23@gmail.com, they would just get rejected. But TitanCipher@gmail.com does exist and it would be a valid address to use. Where this becomes helpful is when we start looking up information on the company. For instance, if we go back to AVG. If we think their naming scheme was first name.last name, and we found a name of someone who we think is an employee, John Smith, we can try in here, John.Smith@avg.com and see if it comes back as a valid or invalid address. This will help us know what is good addresses and what are bad addresses. If you start sending a lot of emails to a server with bad email addresses, that server will start realizing that it is spam coming from your address and they’ll block you down. You always want to be targeted in your approach.

You don’t want to just shotgun things. You want to be precise like a sniper. This is just one of the tools that you can use during your reconnaissance phase. There’s literally hundreds of different tools available out there, but this is just one that I particularly happen to like. I recommend that you try out various tools to figure out which one works for you and your style. This lesson was to show you the process that an attacker goes through in collecting some of the basic information they need in order to develop their attacks.

• Category: Uncategorized