How to Identify Cybersecurity Attack Paths from the Attacker’s Perspective

When it comes to cybersecurity, there are two points of view to always consider – the external and the internal. The internal perspective is the perspective of the individuals defending the network or applications, looking from the inside – out. The external perspective is that of the attacker, looking from the outside – in. When defending a network or applications, it is important to evaluate how an attacker would see the same network. Putting yourself in the shoes of threat actors is an invaluable skill set that will help you see the potential attack paths and low-hanging fruit opportunities to exploit. 

When considering the attacker’s perspective, the first thing to think through is the attacker’s starting point. For any attack to be successful, finding a vulnerable starting point is always the first step. Ask yourself these questions to start this assessment:

• Is the attacker trying to breach the organization’s perimeter defenses?
• Is the attacker trying to exploit a remote or a local vulnerability? 
• Is the attacker already inside the organization’s network by compromising a server or workstation via a phishing attack, a weak password, or an unprotected network share?

As you start to answer these questions, begin running hypotheticals through your mind. If the attacker is trying to breach exterior defenses, where might they do that? Based on your knowledge of your network, where would you do that? If the attacker was going to exploit a vulnerability, what vulnerability might that be? What has your VA scanner or vulnerability prioritization tool been screaming at you to remediate? Continue accordingly.

Playing out these hypothetical scenarios begins to build a list of entry points for your team to go and check the security on. Shoring up the defenses in these critical areas goes a long way in preventing a potential breach. If the door is locked, deadbolted, and barricaded it’s going to be really hard to get in.

However, cybersecurity is all about contingency planning. With the complexity of today’s environments and the scarcity of cybersecurity resources, it’s very dangerous to assume that ALL of your entry points are 100% breach-proof. Understanding where a threat actor would go next after they’re in, is the next step in identifying their potential attack path.

The second thing a defender should consider is what a potential attacker is trying to ultimately compromise. From your perspective, assess what the most valuable crown jewels would be and work backwards to connect targets to potential starting points. Here are some questions to ask yourself to help try to determine what an attacker might go after:

• Would the threat actor try to get to the Domain Controller to compromise the totality of the Windows Active Directory? 
• Would the threat actor try to compromise some sort of database to get to the organization’s most valuable data? 
• Would the threat actor try to compromise the organization’s File Servers as he/she believes that valuable information is stored there? 
• Would the threat actor try to compromise the organization’s email server as a means to get confidential information? 

Through just these two steps, you can quite literally begin to map out how attackers might try to breach your defenses. The more detailed you go into this exercise, the deeper the understanding you’ll develop of our environment. The better that understanding is, the better you’ll be at determining the appropriate mitigating security controls to deploy. If you have the resources, these are the kinds of insights to hand off to a red team or a third party penetration tester to have validated.

To get deeper into the attacker’s perspective, we’ve put together a case study snapshot for you. We asked our Head Penetration Tester, Michelangelo Sidagni, to contribute some of his thought process when he tries to compromise an organization. We recommend you take this level of detail into consideration as you perform your attack path assessments. The hackers out there certainly do.

As part of my discovery exercise, regardless of where I start the attack – outside or inside the internal network – my first action is to try to map the environment surrounding me. I try to discover alive/reachable hosts by leveraging ICMP pings, ARP pings or HTTP/application pings techniques. The selected technique is dependent on which host I’m ultimately targeting. The hosts that do respond to the mapping begin to form my target “stash.” 

These “responding” hosts become part of my exploitation path. This is why it is important for the defenders to isolate sensitive information networks so that they can be only reachable from certain hosts and not from the rest of the network. Mitigating controls here are VLAN/Broadcast domains and network-segmenting firewalls.

With the discovered hosts as targets, I then port scan and OS fingerprint the hosts, so it can profile the hosts based on open ports, OS, and host infrastructure function.

For example, if I port scanned and OS fingerprinted hosts on my target list and discovered the following port/OS combinations, I could guess the infrastructure function of the discovered host:

• The following open ports might indicate the presence of a Domain Controller:
  • Open 88 UDP port: Kerberos service
  • Open 135 TCP/UDP ports: SMB service
  • Open 389 UDP port: LDAP Service
  • Open 445 TCP and UDP ports: File Replication services
• The following open ports might indicate the presence of a web application:
  • Open 80, 443, 8080, 8443: Web server which then might be fingerprinted as Apache, Nginx, IIS, Tomcat, etc.
• The following open ports might indicate the presence of different flavors of database servers:
  • Open 3306 TCP: MySQL database server
  • Open 1433 TCP: MS SQL database server
  • Open 27017-20 TCP: Default MongoDB ports
• The following open ports might indicate the presence of MS Exchange mails server:
  • Open TCP ports 35, 465, 110, 143 and 119 among others.

Through this method of open port and OS fingerprint mapping, I am able to determine the host’s infrastructure function and the relative host value.

The host function could also be guessed by resolving the host FQDN and determining the host’s NetBIOS name that might include an indication of its infrastructure function.

Once the hosts’ values are determined as well as their OSes and running services are guessed, I can move to determine whether the OSes and running services are vulnerable to certain vulnerabilities (open SMB ports associated with exploitable SMB vulnerabilities). Are these vulnerabilities exploitable? Do these vulnerabilities have public exploits associated with them?

My choice from there is to either exploit an existing service vulnerability or “live-off-the-land.” Living-off-the-land can take different forms

• Correctly guessing a login username and password
• Capturing SMB passwords – “man-in-the-middle”
• Searching for sensitive information/username and passwords in accessible file shares 
• Discovering and exploiting a web application vulnerability such SQL injection and/or command injection
  

All of these might then lead them to an operating system compromise.

Once I’ve landed into a workstation or server, I can start moving laterally. I pick one or two routes to do this:

• Escalate privileges to exploit a local vulnerability in order to attain a higher privileged access
• Enumerate domain users on the domain, trying to password “spray” these users across the domain hosts in the hope to correctly guess the required passwords to login. 
• If I land on a host with elevated privileges, I look at the host’s memory to see if they can find any privileged username/password combination (i.e. domain admin user) useful to log into other hosts in the domain

My end game for the attack is to find privileged domain access credentials that would allow me to either login directly to the Domain Controller and thus compromise the entire Domain, or continue to log into several stepping-stone hosts until I find the coveted privileged credentials.

Moral of the story for a defender: make it increasingly difficult for an attacker to achieve its initial foot-hold compromise, through focused vulnerability management and hardened identity management. Network segmentation and endpoint security prevention comes into play to limit the attacker’s lateral movements and ability to spread into the entire network environment. If the  Domain Controllers and database servers are successfully breached it is GAME OVER!!!