Sun Zu said in The Art of War: “Know yourself and know your enemy.” There is no better way to defend a company from possible cyberattacks than to know its real level of security by simulating an attack on its information systems, to detect the weakest parts of its defenses, the points of possible malicious access and take appropriate measures. They are called intrusion tests. On this occasion, Javi Echeverrría introduces us with a case study to one of the most common scenarios, in which the intruder has no prior knowledge of the information system to be reviewed. These are the Black Box tests.
The world of ethical hacking, intrusion tests, etc., is huge and unattainable with a few blog posts. Therefore, we only intend to provide a small summary for the reader not familiar with computer security, which serves as a first starting point for those who want some initial information. First of all we do want to emphasize that I use a Kali virtual machine, which incorporates a lot of useful tools in computer security. If you discover any command you don’t recognize, that’s why; Before you start compiling commands, I strongly recommend that you download an image of Kali from your favorite hypervisor and use it.
First, we must emphasize that with an intrusion test we do not seek to hack anyone (in the first place, because it is illegal), but to try to detect potential vulnerabilities that we have in our company or in that of our client, and the impact that these can have.
We will also narrow down the scope of this type of analysis, limiting ourselves to simulating what an attacker can do from the internet to our company.
What will an attacker who wants to hack our company do? First, an inventory of machines we have should be made; try to obtain IPs, domains, contact emails to try social attacks (in many cases more effective than machines), the services we have exposed, open ports, versions, technologies … trying to be as exhaustive as possible to locate the vulnerability that allows him to attack us. This is something relatively simple and can also be done in many cases without the attacker being detectable, since it can be done through consultations to services outside our company. Let’s see some examples.
Suppose the attacker wants to analyze the services of a “random” website, for example, Ford. If we start for example from ford.com, our first attacker will easily get a first IP with a ping: 22.214.171.124 (which we already put in our inventory).
PING ford.com (126.96.36.199)
Later he will probably try to see if a whois gives him some information. With a whois we could find data of the registrant (and put it in our inventory to make a possible social attack), or, for example, data of DNS servers that could be of the company, so they would be part of the inventory. For example, in a whois to ford.com several company DNS servers appear:
DNS005.FORD.COM – 188.8.131.52
DNS006.FORD.COM – 184.108.40.206
EXTDNS001.FORD.COM – 220.127.116.11
EXTDNS002.FORD.COM – 18.104.22.168
EXTDNS007.FORD.COM – no parece resolver
EXTDNS008.FORD.COM – no parece resolver
EXTDNS009.FORD.COM – 22.214.171.124
EXTDNS010.FORD.COM – 126.96.36.199
Making pings, we have been getting IPs to put in our inventory. In addition, for example, Ford has its website in Spain, ford.es. If we use the nic.es tool we can also obtain domain information, and see if we can locate more DNS servers. This is not the case, because the DNS servers (extdns002.ford.com, extdns001.ford.com, dns006.ford.com, dns005.ford.com) we had already obtained them from the previous list.
If you look, there are quite similar IPs, that is, it seems that Ford has reserved ranges of IPs, which could be added to our inventory. There are also similar DNSs, so if there is a dns005.ford.com, you can try to see if there are other servers by changing the numbers, iteratively.
Having these first IPs, it can be interesting to do searches on the website of ripe (ripe.net), which could provide us with information about ranges of IPs reserved by the company, adding them to our inventory, or netnames. For example, searching for “FORD”:
We can obtain new ranges of IPs to add to our inventory, for example:
Other ranges of IPs reserved for the company appear, as you can see by doing the search. All this we would add to our “buchaca” of IPs that we will then analyse by scanning ports, etc.
We have more tools to discover domains and subdomains of a brand, which in the end point to different IPs that we can add to our list. For example, a very useful tool included in Kali is dnsrecon. You can find many specific posts on how to make an enumeration using dnsrecon. In our case:
dnsrecon -t tld -d ford
It gives us a huge list of Ford domains, many of which are quite recognizable IPs, for which we can compare whether we had them already identified or should be added. It is also possible that there are domains detected that are not really of the company (for example, ford.xxx) and we should discard them.
The DNS servers themselves are also an important source of information, since they can provide us with new IPs, for example, from mail servers that may be vulnerable. It is easy to find posts that explain how to obtain information from the different associated records.
Dnsrecon also allows us to detect other services using the ranges detected in RIPE, running: dnsrecon -r -t rvl
For example, using one of the IPs of the principle, 188.8.131.52, I include a wider range:
dnsrecon -r 184.108.40.206-220.127.116.11 -t rvl
And I locate new services:
What can we add to our list of IPs. Thus, we can run dnsrecon with different segments of IPs that we locate in the analysis to increase our list of IPs of the company.
A next step may be to try to detect subdomains. There are several ways to detect subdomains, and you can also find a lot of documentation about it. A very useful one is Sublist3r, a Python script (https://github.com/aboul3la/Sublist3r) that makes queries to different public sites such as Google, DNSDumpster, VirusTotal, Netcraft … to locate subdomains, saving us the manual work of going to these different websites to locate subdomains.
For example, we could launch:
python sublist3r.py -d ford.com
python sublist3r.py -d ford.es
To locate subdomains registered in this tool of those domains. The recommended in a complete intrusion test would be to do that with each and every one of the domains located at the beginning, and add the different IPs to our list iteratively.
The list of subdomains we found is very extensive; for example, from ford.es we obtain 35 subdomains that are added to our list, also giving us options to continue finding new ranges of IPs and other servers associated with dnsrecon, etc.:
This same search on ford.com gives us 637 new subdomains!… among which it is easy to detect endpoints of VPN connections, web servers outside https://www.ford.com/, email servers, authentication services…
Another additional way to find subdomains is to use brute force, for example with the Kali Fierce tool (use a default word dictionary but we can add custom dictionaries):
fierce -dns ford.es
fierce -dns ford.com
Although the first one only locates a www1.ford.es server, on ford.com there are many subdomains from which to bring new IPs to our list, in addition to recognizable IPs within the ranges we have been seeing.
There are other tools such as Aquatone, Spiderfoot … with which we can iterate to locate the different IPs of the company.
I recommend that you do this process with your own company, and it will surprise you (at least it did to me) to find things that you didn’t even know or remember were there. Well, think that once we have the IPs, with more or less automatic tools it is easy to first find the ports that we have on those IPs and, for example, the vulnerabilities associated with the exposed services. Never trust “no one will find this subdomain” or “who will know that we have left this port open”. A machine can find all that in seconds, and there are bot armies dedicated to it.