This will be the first blog post in a series designed to demonstrate how we commonly establish a foothold into a target network. Each blog post will dive into one of these common techniques at a deeper level, showing some practical application and defenses.

The goal of this series is to help educate those who are new to penetration testing and hacking techniques. We tend to see the same mindset applied when we speak to those new to pentesting “Scan something with Nessus to find the vulnerability, and then exploit it…Right?”. This is very far from reality when we talk about pentesting or even real world attacks. When performing penetration testing and red team engagements, we often find these five (5) techniques to be highly effective at establishing an initial foothold into the target network:

1. Phishing:

Big surprise here, phishing actually works. There is a lot to this particular method as you may be able to spoof email to the target by using a configuration flaw in their mail servers, using a compromised account, or even a vulnerability in their web applications. Taking advantage of a spoofing flaw or using a compromised account will likely increase your chance of success, as the phishing email will result in a higher level of trust.

We commonly leverage phishing to perform the following:

  • Click Analysis: See how likely a user will click a link
  • Credential Gathering: See how many users will supply credentials when prompted
  • Execute Code: Generally involves using PowerShell, Office Macros, HTML Applications (HTAs), Java Applet Attack Vector, etc.


2. Web Application Vulnerabilities:

Applications are literally everywhere! Whether an application is on the internal or external network of a company often we can still find vulnerabilities and flaws across these systems. Web applications can vary a lot depending on their purpose and complexity. As a result an application that is more dynamic in nature will often have more vulnerabilities and flaws. These web application vulnerabilities can vary but typically lead back to a lack of input validation occurring or a misconfiguration within the technology being at fault.

We commonly find web application vulnerabilities through the following avenues:

  • Unlinked Or Outdated Content: Often times companies have no idea what their web applications have exposed to users
  • Areas that Allow User Input: Applications that allow for user input often lack input validation in some manner
  • CMS Platforms & Plugins: Many companies use content management systems and 3rd party plugins for their applications which often go unpatched and remain vulnerable.

We talk a lot more about web application specific testing during our RVAsec 2016 Talk


3. Multicast Name Resolution Poisoning:

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS-NS are ways Windows resolves hostnames to an IP address. This multicast name resolution is used if DNS fails to resolve the hostname, and occurs very frequently on enterprise Windows networks. These protocols can be poisoned and can allow an attacker to gain access to usernames and password hashes (most commonly NetNTLMv2). An awesome tool called Responder, can be used to accomplish this attack, and in our experience will very quickly spill out usernames and password hashes (NetNTLMv2) from modern Windows environments.

To take advantage of these hashes you can either crack them, or relay them (see technique 4). NetNTLMv2 hashes can not be used like traditional Windows hashes to “Pass The Hash”, but combining password cracking techniques and SMB relay techniques you can have a lot of success.


4. Relaying SMB Credentials:

By establishing a malicious SMB server we can relay network authentication attempts from legitimate servers. Software updates, inventory, and patch management systems will very commonly spray credentials across the network. Once these systems attempt to authenticate to the malicious server we can relay the credentials to a victim system (assuming SMB signing is not enabled).

This technique can be combined with Responder to relay the NetNTLMv2 hashes, you can use the built-in Responder, or our preference is to use the Impacket script.


5. Account Compromise:

Humans are terrible with passwords, no surprise here. Often times we find that many companies lack a strong account and/or password policy, which as a result allows several systems on their network to be highly vulnerable to account compromise. Even worse once weak passwords are allowed on your network they are often shared across systems and accounts/passwords are re-used to simplify access for your users.

We commonly see the following factors as some of the leading causes to account compromise:

  • Single Factor Authentication: Only a username and password to gain access
  • No Account Lockout: An attacker can attempt to login to an account until successful
  • No Password Complexity: Users often default to a easy password that can be easily guessed rather than a complex one
  • Default Credentials: Technologies come with default credentials which are often left unchanged.
  • Shared Accounts: Same Root password across the board, or a shared local Admin account for Windows systems


It should be noted this is not a complete list of methods to establish a foothold and that every assessment is different, often requiring additional techniques to be leveraged. Once an initial foothold is established the assessment can go in many different directions based on the goals and established Rules of Engagement (RoE). Remember the value to your customer is to demonstrate risk, reach the goals of the assessment, and to stay within the Rules of Engagement (RoE); establishing a foothold is merely a means to an end.


Stay tuned, future blog posts will dive into each of these areas with sample code, examples, etc.