Network Reconnaissance: A Key Function of Your Ongoing Security Strategy

This article was originally published on Pokerfuse Pro.  The goal was to make iGaming operators aware of tools and techniques they could use to strengthen their security posture. Protecting your data and information technology assets from hackers is of the utmost importance for all companies, and in particular, companies that participate in the iGaming industry. Before devising a security strategy to protect these assets, it is important to understand the location and function of potential targets. This process is referred to as network reconnaissance.

There are several ways to perform reconnaissance functions. By performing these activities you will learn a lot about a company’s network presence. This is something that security testers and malicious users will do, but it is also something that I recommend organizations do to assess themselves. Often when conducting vulnerability assessments we discover systems that the company is not even aware of or thought were decommissioned; by performing this analysis a company can better protect themselves.

Procedures to Identify Assets that May be At Risk

You can use operating system command line tools such as dig (a DNS lookup utility) to enumerate IP address and name server information, then use the IP address information to perform a reverse DNS query on the address range to discover other hosts on the same network block. A reverse DNS query is the determination of a domain name that is associated with a given IP address.

As you can see in the figure below, this provides some interesting information: You are able to identify systems that belong to the target company, but also others on the same segment. Some names are discovered that might be interesting to a security tester or attacker.

recon-testingThere are also web resources that can be accessed to assist in discovering useful information. Netcraft is a site that performs monitoring and analysis of web sites on the Internet. By querying their database, additional web sites can be identified.

When I first started performing vulnerability testing around the year 2000, there was not a single tool that could be used to perform all of the reconnaissance techniques; to do them all manually would take some time and could lead to some data being missed. Luckily for us tools have been created to automate the process.


My favorite recon tool is Recon-ng written by Tim Tomes. Recon-ng basically takes all these various sources of information that you would have to query on your own and automates it. From his site:

Recon-ng is a full-featured Web Reconnaissance framework written in Python. Complete with independent modules, database interaction, built in convenience functions, interactive help, and command completion, Recon-ng provides a powerful environment in which open source web-based reconnaissance can be conducted quickly and thoroughly.

Some of the sources the tool queries require you to obtain an API key; in most cases they are free, but in some there is a charge. That said the majority of the tool’s functionality can be used without spending any money. The tool is comprised of various modules that you select, provide the domain name target and then run. The figure below shows some of these modules.


The next figure shows the google_site module being used to perform advanced search functions to locate domain names.


As you run the various modules it stores the information in a database that can be queried for reporting purposes including resolving the IP addresses for the hosts in the database.

Although we only went over a couple of quick examples, there are a number of different methods that could be used to perform these reconnaissance activities. The tasks described in this article are activities that the operators IT team should be performing on a regular basis. In order to fully protect your network you first must know where all the key assets are located.

It should be noted that the majority of these techniques illustrated in this article are passive in nature; active testing should only be performed with explicit permission.