Information Gathering
Last updated
Was this helpful?
Last updated
Was this helpful?
The Idea of recon is to gather as much information as possible without attempting to gain unauthorized access or exploiting a vulnerability. Recon happens at many different stages and has unlimited targets. In a way, attackers are always in the recon phase even if it is not the main focus at the time. However, when it is the main focus it needs to be the sole focus of an attacker efforts.
The main objective of recon is to identify the potential vulnerabilities of the target. At this stage, we are not validating those vulnerabilities just identifying potential vulnerabilities. This means that when an attacker notice a possible vulnerability an attacker take note of it and keep looking. Have a list titled "Things to Try" to help keep track of all the possible vulnerabilities that could be attempted.
Having a list of possible vulnerabilities to test can help reduce the amount of time spent on rabbit holes. This is because if an attacker gets stuck, it is much easier to go to the list and try another possible vulnerability.
How recon is conducted is based on many factors but the main factor is what an attacker is gathering information on: domain, host, service, user, email, person, company, etc.
The amount of information that can be gathered also changes by access level. For instance, the amount of information that can be gathered on a host is much different depending on if an attacker has shell access or not. Even when an attacker has shell access, the amount of information gained about the host is different based on the user's permissions.
The purpose for an attacker during recon needs to be clear. Is the attacker attempting to get an initial foothold or escalate privileges on a specific system or group of systems? Maybe an attacker is trying to create a phishing campaign against a target. Every time an attacker engages in recon they need to have a clear goal in mind of what they are attempting to accomplish. Keep an open mind though. a goal may need to change.
When an attacker is performing recon, question everything that is found. Look into it. Even if it is something that initially does not seem to be worth looking into. The attacker should record it because if they get stuck they can look back at it and dig into it. That one thing may very well be the golden ticket an attacker are looking for. For example, jquery-file-upload is something I over looked on a box and got stuck. Come to find out it was vulnerable...
Organization (Entity)
Domain
Network
Node (Network Device)
Port Scans
Os Finger Printing
Service Version Scans
Vulnerability Scans
Website
Person
There are two types of recon: active and passive.
Passive Recon
Passive recon is when an attacker are gathering information on a target without interacting with that target directly. Usually, this this type of recon uses open source intelligence (OSINT). While passively gathering intelligence, the attacker does not send any type of request to any of the target systems or personnel.
an attacker can gather a lot of information before sending the first packet to the target.
Passive Tools
Active Recon
Active recon is when an attacker are interacting with the target directly in some manner. This could be calling, emailing, browsing their website, scanning, etc. Some argue that interacting with public services provided by the organization is not considered active recon. I am not one of them.
Port Scanners
Web Scrapers
Vulnerability Scanners
Web Proxies
Google Dorking Website Social Media
Google Dorking DNS Records whois records recon-ng
During this portion of recon the attacker is performing network sweeps and network tracing to find target nodes, other possible networks, and other possible domains.
During this portion of recon the attacker is looking at the attack surface of a node to identify any possible attack vectors.
This portion of recon is broken down into different sections.
Port scanning
OS Fingerprinting
Service Version Scans
Vulnerability Scans
OS
User(s)
Group(s)
Before an attacker can start poking around at services, an attacker need to decide what host an attacker want to target first. I would suggest searching for any services an attacker are comfortable with first.
For example, if an attacker are comfortable testing SMB:
From here an attacker can either look at all of the nmap scans to see what other interesting ports are opened or start running more scan s on the entire list. To continue with the SMB example, an attacker may want to see if any of the servers allow for anonymous logon to shares.
or
From there an attacker can create a list of hosts an attacker would like to look at further to see what information an attacker can gather by connecting to the shares.
If an attacker have not followed the process over there, then I would highly suggest running the following scan on all target IP addresses. Note: If an attacker only have one IP address, an attacker might consider moving to a full port scan.
That scan should also bridge us into the services recon as well. The main purpose of this initial scan is to help identify a target to start off with. Instead of selecting a target base on it's IP number or something arbitrary it would be good to select a target using a little recon. This way is not fast, but it is not as slow as scanning an entire subnet and all the ports on each host. This way an attacker can identify services that an attacker are better at exploiting and start with those systems.
After an attacker have gone through and identified a system an attacker want to target, start a full port scan as an attacker start manually poking at a service an attacker already identified as interesting (from the initial scan).
Get a list of all those open ports and scan them using the -sV
and -sC
options to get the service version and to run the default scripts on the services.
I have burned myself countless times focusing on the top 1000 and not going back and looking at the all ports port scan that I did after the top 1000. It is true that scanning the top 1000 will get an attacker the port an attacker need most of the time; however, getting into the habit of relying on and expecting the path to be in those top 1000 is a great way to get caught up in and stuck on red herring.
Once that completes, scan each of those ports for versions and with default scripts.
When it comes to scanning UDP ports, I follow a little bit of a different rule. I will start off by scanning the top 20 port with version checking and running default scripts. I will have this running while I am starting to dive a bit deeper into TCP ports.
Once an attacker have a list of open ports and services running on those ports an attacker can move on to recon on specific services.
Now that an attacker have a reasonable idea of what services the system has running and are listening, an attacker can start poking at them to learn more about them.
Each service will have it's own method and set of things to do to get the most information from that service. That being said, there are some things an attacker should attempt for almost all services.
If the service is completely new to an attacker, google the service and read it's documentation. The idea is to get a general sense of what the service does and why it may be on the system.
Try and connect to the service to see if an attacker can interact with it. To this point an attacker may not know what tool(s) an attacker can use to connect or how the service communicates. It still may be beneficial to attempt to connect to the service with Netcat or Telnet.
Note that by default Netcat only sends a Line Feed "\n, 0x0a" instead of the full CRLF (carriage return "\r, 0x0A" ) that telnet does by default. an attacker can change this with the -C
options.
BTW why is it CRLF when the line feed usually comes first. Shouldn't it be LFCR?
Another suggestion would be to run a vulnerability scan on the system against all open ports. an attacker could use a vulnerability assessment tool for this. However, if that is not an option, an attacker could just use nmap's scripts for this purpose.
Research NSE scripts. an attacker need to know what the NSE scripts do and what arguments they have. For example, if an attacker are looking into SMB vulnerabilities:
It is possible to get OS information by scanning. You can use nmap
with the -O
flag to attempt to get the OS. Another way to get OS information is based on the ports that are opened and what services and service version is listening on those ports. With some crafty googling you may be able to deduce what OS is on the target system
The way in which an attacker gather information about the OS is, as an attacker would imagine, different based on the OS an attacker are on. However, there are some very specific things that an attacker should look for each time an attacker are able to get on a system.
Are there any executables that run in a privileged context?
What users are on the system?
What groups are on the system?
What is the current user?
What scheduled tasks/cron jobs are running?
What binaries do they use?
What are the privileges of the binaries?
What shells/terminals are on the system?
Are there any mounted drives?
What ports are listening?
Are there any new ports?
What service is listening on those ports?
Is it listening locally only?
an attacker may need to use a tools such as chisel to tunnel in.
What network adapters are on the system?
What are the network settings?
What programs are installed on the system?
Once an attacker get administrator access:
What password hashes are stored on the system?
Just like OS recon, User recon techniques differ based on the OS of the target. However, just like OS recon, there are some specific things too look for and document.
Username
Groups
What permissions do you have?
Can you run any programs with admin permissions?
Can you manipulate processes/services running as a privileged user?\
What files and folders can you read?
Although this portion of recon could be considered node recon, I break it out because it could, and usually does, consist of many nodes on a network. The target may be using a three or more tier architecture for each website or each web application which a vulnerability or a misconfiguration in one or more may allow an attacker to compromise one or more node.
Performing recon on a person can help develop a plan of an attack on that individual much like recon on a company can. For example, an attacker can use information gathered this way to craft phishing emails.
Start off with getting a port scan of the system. There seems to be three main approaches when scanning a system. The first approach is to scan for the top 1000 (the default scan), or to have a set of specific ports to look for and scan, and lastly, to do a scan of all ports. If an attacker have followed my methodology thus far, in the phase, an attacker should have already scanned the system(s) with a set of interesting ports. 21,22,23,25,53,80,110,111,135,139,143,443,445,993,995,1723,3306,3389,5900,8080