Defensive strategies require understanding how an adversary will employ tactics to determine weaknesses. Offensive strategies are often most successful when the executor of the strategy is familiar with defensive tactics, such as the ones covered in the previous article. Often, the weakest link in any security chain is people. People keep passwords simple, ports open, and information being disclosed.
This information is for educational purposes only. I am not responsible for YOUR actions.
Recon
Reconnaissance is the preliminary survey to gain information, often used in the military as a survey of an enemy or target. In hacking it is the same concept, the goal of your recon is to gain information about the target such as versions of software running, architecture, what other company’s they may interact with, and of course analyzing where weaknesses may exist within the company structure. This type of analysis takes significant time and can mean the difference between a successful operation or a failure. The implication here is the more research and verified data you have the better plan of attack can be derived from the information.This same process can be applied to analyzing your application or service for defensive security analysis. The art of recon can be summed up in the movie Wargames in the following scene.
In the scene, David, played by Matthew Broderick is researching Dr. Falken to gain access to more of the WOPR system. This process of research and analyzing data to find the answers is what recon is at a basic level. While the movie is obvious just that a movie, the method used here to research the creator of the software can provide many vital data points that could be used for a variety of purposes. In this case, David is trying to find more information by gaining access to other parts of the system. In the modern era, we do not necessarily have to rely on libraries for old newspaper articles and information. We are also in the state of mass surveillance, that being said it is important to employ your OpSec practices even when doing recon on a particular target. Remember, all your search data and computer use should be treated as if someone is watching. They probably are watching.
Recon tools have come a long way from the 80’s and 90’s when a hacker would have to jump around phone systems trying to dial modems with wardialing just to identify a potential target existed. After identification of existence, they would need to connect and attempt to research all they could with the tools they had to find vulnerabilities to gain access. Social engineering is also another tool employed to gain vital information about targets. Some modern examples of social engineering can be seen as scam calls, spoofed emails, phishing, URL redirects, and befriending friends of the target on social media. I used scam calls because some people fall for the tactic every day. Not always is the “scam” call a call to obtain money, it could be to gain information to verify details an adversary could have obtained. An example would be to call a grandparent of a target and tell them that the target may be in trouble, or may need to verify a couple of pieces of information for a job onboarding process. This does not come off as a risk to most and they will confirm this information or inquire about their status, this confirms several key details for the social engineer in their recon.
Data points obtained from various methods recon are compiled together and a strategy is derived when this data is analyzed. There are a variety of modern-day tools for recon via remote methods, local methods, and of course the classic social engineering model. Social engineering attacks can happen in person, via email, or phone call. A common method of social engineering is looking at LinkedIn or Facebook events and the adversary sending an accomplice or attending themselves to gain valuable recon data. Networking events and conferences can be extremely useful in obtaining not just data but also physical access to a potential target. During these times, they could employ various hardware attack vectors ranging from an evil maid, USB insert, charging cable attacks, or network attacks. We often overlook what can be done in person because the movies paint a picture that isn’t realistic, but a clever attacker who is prepared will not need to be sitting in front of the computer to make it happen. Never underestimate to what lengths an adversary may be willing to go, that is a mistake that will end poorly.
Tools
Recon tool usage begins after a target(s) has been identified. Once this process occurs there is usually a time that is associated with the collection of data about the potential target. This information would be vital such as the operating system, version of various services they run, and of course what provider(s) that they may use. Other information along with this information would be utilized in the strategy and planning phase. Keep in mind, this could be done in hours, days, or weeks, and in some cases years dependent on how complicated the target(s) systems are. A variety of tools and methods will be employed to guarantee the validity of the data, as in hacking should always treat it as if you only have one chance, any repeated attempts would begin to provide identifiable links of an adversary to the target. This goes back to proper OpSec and understanding your threat modeling when performing recon.
Before 2010, recon work would often involve the use of compromised machines to do port scanning and identification of services used in a stack. This was a messy process and often the owners of the compromised systems could stop an operation completely with nothing more than reinstalling the operating system, an update, or pulling the system offline if the attack was being detected. This made for some very interesting problems in operations in this century as these were tried and true processes in the 90’s. As technology changes, so do the methods in which we obtain recon data on targets. In 2009 a new site, Shodan.io, would launch and it would greatly ease the complexity and risk of remote reconnaissance of a system. These tools provide critical details about systems that an attacker can utilize to their advantage.
Other services exist and you can easily find them on DuckDuckGo or whatever search engine you decide. I would advise against you using these systems with their API keys as their associated with an email address and account system. I would also encourage you to use Tor when accessing these services to prevent tracking to your usage. Use Tor and anonymity practices for more than just operations or risk correlation data attacks against you, remember to threat model your actions or have a bad time. Along with this information, you will want to cross-reference the CVE’s and known exploits. This will allow you to begin to build a basic understanding of the target(s). Do not make any assumptions of their infrastructure without doing your research, they could have a vulnerable web server, it could be in an isolated network and in a container, which would prevent your exploit from gaining access to their virtual machine in the cloud. Be sure to do your research on what if any hosting providers the target(s) may use. This will greatly cut down on your frustrations and problems identifying entry points.
Other recon tools do exist and I must warn you that if you use them improperly you will essentially be telling the target that you are doing your recon against them. Tools like nmap, reaver, and others can provide easy to use tools at the cost of improper usage leading investigators directly to you. These tools are very powerful and can help further in your recon of a target. Using Tor properly along with public networks while masking your mac address that I have covered in another article, can be employed here with these tools to get more data. Data is important, especially when analyzing your target(s). Just like when cutting a board, you want to measure twice and cut once. In most cases, you will only get one good chance to perform your attack, after the first attempt most network and systems administrators worth their salt is going to become aware of your intentions. The administrators can and will take actions to stop you, honeypot you, or contact law enforcement with a combination of any of these responses. Do not be stupid.
Another common mistake is not researching who the target(s) do business with. For example, they may use Cloudflare or reverse proxy, you are probably not even aware of the actual origin endpoints and could spend weeks of research on the wrong endpoint. This is not just a time sink and a waste of your resources, it is also a rather beginner move as you did not do your research. There are tools such as securitytrails.com and others that can help you in identifying the origins and endpoints that you should be spending your time analyzing instead of wasting it on the proxy endpoint. There are also plenty of tools for this on the command line as well. In this phase of recon, we want to avoid tying our system to research as much as possible to prevent leaving bread crumbs to the adversaries of the operation. This includes leaving a trail for law enforcement.
Once we have gathered vital information on the host(s), what providers they use, and the software employed in their stack. We will now need to find if there is any way for us to employ social engineering tactics to gain vital information on things such as password policies and other internal processes to the target(s). In- person networking events are not as common due to Covid right now, there are still some going on. People are going out to the parks and other public places and these can be great troves of information. Utilize social media to identify where some parks or places employees of a target may frequent. In knowing these tactics such as MITM proxy 2“FreeWifi” access points can be deployed, social engineering tactics such as striking up a casual conversation, and befriending can come into play. These methods seem ridiculous, but how many times have you heard someone complain and detail their password policy in public? A comment such as “OMG, I wish they would change this policy, I had to reset my password and they ask for this complex N character bullshit”, where N is some arbitrary value. I have heard this numerous times in Silicon Valley bars and parks. Use this information obtained through a variety of tactics to your advantage. Every data point makes your strategy more comprehensive.
Another tactic often employed with physical proximity is being on the same network as a potential target(s), such as a coffee shop or some hangout. Co-Working spaces are also a trove for social engineering attacks. As companies move away from larger satellite offices, a co-working space can and will often advertise what companies are possibly using their facility. You can often find this on their website, the physical office placard listing at the co- location, or through social sites like Meetup or Eventbrite, and cross-reference it with the target’s information to verify this information. Again, these are all data points and at face value, they do not seem like much, they can provide the entry point needed for your attack. No data point is worthless when performing reconnaissance.
Another valuable tactic is just simply researching the target(s) online. Often you will find customer pages of services like Network Intrusion Detection systems or cybersecurity firms. These can provide a wonderful insight into the level of security a particular target(s) may have about their infrastructure and data. Along with customer pages, also take a look at customer support forums of the providers as these too can provide critical details of issues and or services disabled due to issues with a version. An example is using AWS forums to scan for certain criteria, to post you must be a customer, many are using their real names and can often be linked directly to the company they work for which allows you critical data points on the infrastructure. It could also provide you API examples in some cases without needing to disclose your interest directly. Use all of these tactics to your advantage. Consume all the data you can and now let’s analyze.
Analysis
We have been collecting data points for a time now and let’s take a look at what we have amassed. Data collection can become very cumbersome as it is easy to lose track of the data if not properly stored in an easily understandable way. When compiling this information, you should use a dedicated device, a USB drive, or some storage system whose sole purpose is to contain this information. It should be encrypted and not via the operating system you are using, but with PGP. Do not take chances with your drops in OpSec to compromise a particular operation.
Let’s take a look at what data we have collected and organized. Start by sorting through the infrastructure of the particular target, this information would be like web server versions, the CVE’s associated with it, what provider they use, all forum posts related to the technologies they have employed, as well as our social engineering data. We now need to come up with what we have, I am going to use an example, your target(s) will vary greatly and I am only using this as an example. This information is for educational and reference purposes and is not indicative of any actual target(s).
- nginx 1.18.0, behind Cloudflare proxy
- postgres 13.1, separate subdomain host (CNAME)
- redis 6.0.9, separate subdomain host (CNAME)
- NodeJS 14.4.3, application runs on same host as nginx
- Self Hosted, no cloud provider
- No Docker
- Barracuda Network Intrusion Detection System
- F5 Load Balancer
- Linux: CentOS 8.0.1905
- User’s auth through Google, GitHub, LinkedIn, and Facebook, there is no direct account system creation through the application.
- Snort running on host(s), forum post disclosure.
- Possible SQL injections, need auth token. Stack Overflow Post. Lulz
- $GITHUB_REPOS
- Node Dependencies and Vulnerabilities
- CVE’s on each software component.
This is an example list of software and infrastructure notes of a particular target(s). Yours may contain information such as IP addresses, subdomains, as well as similar information as above. You should spend a large amount of time analyzing CVE’s and versions as this will become our method of testing which we will cover next week. Analyzing this data will take us some time to get all of the aforementioned details provided in this example. In an average run, it took me around 45 days of casual reconnaissance to obtain this information. It will take a few days to cross-check and verify these systems and utilizing social engineering can help in checking licenses are still up to date and the like for services employed by the target(s).
There are large amounts of companies sharing their services via Github or Gitlab as open-source projects and this too can be utilized in our analysis. Often companies will run bug bounties, in some cases, you may find pull requests from others patching bugs and they have not been merged. This too can provide us endless amounts of data points to analyze for our attack strategy. The strategy will consist of a few other steps for our operation to be successful. At the moment though, we now know a few critical pieces of information that we can take some actions on.
The proper strategy will require testing, and this does not mean against our target(s). In the New Year, Fresh Start article I mentioned buying an old desktop machine for testing, this is where the testing comes into play. We will now build out a copy of the system as close as we can that is based on the recon data we have collected. This is going to allow us to test and penetration test without sending a warning message to the target(s). I will be covering in-depth how this works and the methods used for setting up, testing, building out your tasks to perform for the operation in next week’s article. The strategy will take some time; we will still have to passively perform reconnaissance during this time in case of changes to the target(s). These changes could be bug fixes or the introduction of a feature that we can use as another attack surface. In the strategy article, we will be using scanner software and vulnerability assessment. We will also execute a couple of vulnerabilities against our test system.
Hacking is 98% research, 1% fortitude, and 1% execution.
Closing
We took a little stroll down recon work against a target(s) and were able to find several interesting data points. These points will allow us to strategize on what methods to employ for our testing. This testing will eventually lead us to the exact processes we will use to gain access. The same methods we have explored here should be applied to your operational security and your systems. These processes are the threat modeling that an attacker will use against you just as you are against a target(s). We too are also targeted by adversaries and should not turn a blind eye to the methods they deploy to analyze targets. Understanding defensive strategies allow us to craft strong offensive tactics without the need for erroneous disclosure to the target.
All of the aforementioned information in this article is again for educational purposes and I am not responsible for your actions. In the next article, we will set up a testing environment, execute vulnerability assessment, execute some exploits against the system, and verify the consistency of the execution. Once we have performed these tasks, we will draft a strategy. These tactics should be deployed against yourself to understand the weaknesses of your system(s) and operational security. These methods could be applied against hidden services as well but will require some finer tuning and a better understanding of Tor not just as a browser but as an overlay network. In the future, I may do a piece on dicing onions that are improperly configured and are easy targets.
I want to thank JACE for proofreading. If you find this information interesting please share with others. Knowledge is power. You can contact me on the following platforms:
Signal:(867–675–1041)
Tox: D7D264EA7541C4324625A8360267C3C54F9C1AF564D4266FE4 5F2BCB68924E21CB2A75746D51
