Discovering indicators of compromise

Reconnaissance

The Security Analyst's Perspective

What does this attack look like from the perspective of the defender? A security analyst generally doesn't use Metasploit or custom code to conduct an attack. A defender uses different tools to "listen," as it were, for evidence of the attack.

First, I'll start with what the reconnaissance/discovery process looks like from the perspective of both the attacker and security analyst with the use of a simple two-system example:

Attacker: 172.16.190.158 (system1)
Victim: 172.16.190.159 (system2)

Figure 2 shows an attacker using Nmap to conduct a quick discovery with the command:

system1$ sudo nmap -sV -O -A 172.16.190.159 -p 445

Figure 2: Attack with a downloaded EternalBlue exploit.

This command tells Nmap to do a verbose discovery of a host (-sV), and this scan will (one hopes) reveal the type of operating system (-O) and the specific service it is running (-A) at port 445 (-p). The result is shown in Figure 2.

This scan has revealed quite a bit of information, including:

The operating system version (Windows 7, Service Pack 1)
The computer name/NetBIOS name (WIN-NJKFH7RKUAQ)
The computer's workgroup
That it is running Microsoft Networking/Server Message Blocks (SMB)

From a security analyst's perspective, Figure 3 shows what the scan looks like through Wireshark. I've marked the scanning packets black and red and filtered all network traffic so that I am only viewing TCP-based traffic between the attacker and victim systems mentioned earlier.

Figure 3: Viewing a discovery/reconnaissance scan through Wireshark.

Although this traffic is encrypted in this particular example, you can trace it. To get to the TCP trace function in Wireshark, first highlight a TCP packet, and then right-click on the packet. A pop-up window will appear. When it does, select Follow | TCP Stream . An example of an encrypted TCP trace is shown in Figure 4. You can also trace UDP packets in a similar fashion. Even though the traffic shown here is mostly encrypted, notice that certain Microsoft Networking header information is still easily readable.

Figure 4: Encrypted TCP-based Microsoft SMB traffic.

Security analysts often use information like this to preprogram IDS and SIEM systems, which, believe it or not, don't often discover these details automatically. Figure 5 shows the Windows NetBIOS Name Service (NBNS) traffic that was generated by the Nmap scan.

Figure 5: Nmap-generated NBNS traffic in Wireshark.

Now that you've seen what a quick scan looks like, it's possible to (1) program IDS and SIEM systems with this information and (2) inform security operations workers about this traffic and its appearance.

From the discovery/reconnaissance phase, I'll consider what an actual attack looks like from both perspectives. Figure 6 shows an attack from a publicly available EternalBlue exploit, which is one of the many tools that the US National Security Agency developed to break into systems. Tools such as these were released by The Shadow Brokers hacking group back in 2017; many of these tools are still in use and find successful victims to this day.

Figure 6: Compiling and executing EternalBlue exploit code.

Notice that system1 (172.16.190.158) first configures some shellcode that contains a hard-coded IP address, which is the address of the system being attacked (system2, with IP address 172.16.190.159). In the last line, I execute the command to attack system2:

./eternalblue exploit7.py 172.16.190.159 ./shellcode/sc x

From the security analyst (blue team) worker's perspective, Figure 7 shows what the result of the attack looks like.

Figure 7: Result of the first shellcode-based EternalBlue attack.

Yep, that's a Windows 7 "blue screen of death." The result of the attack with the shellcode I downloaded from the Internet resulted in nothing more than a particularly obvious denial of service attack.

I'm being a bit of a smart aleck, here, but I do have a very serious point: In many cases, an attacker uses various tools that result in a system crash, rather than a system compromise. The security analysts I have talked with over the years are always on the lookout for system reboots and blue screens, because they could be indicators of an attack. In fact, I've seen evidence before of hackers who use tools like this simply to conduct denial of service attacks.

In this case, however, the mission is to do more than just crash a system, so I've simply switched tactics and used Metasploit's Meterpreter to conduct an attack (Figure 8). In this attack, I've set the remote host to the victim system (system1) and used a really obvious port (4444).

Figure 8: Successful EternalBlue attack using Meterpreter.

A good hacker would usually specify a much more "stealthy" port, which would be one commonly used on the network (e.g., TCP port 445, port 80, or port 8080). A good IDS would likely get pretty curious about why port 4444 is being used when it has never been seen before in this way. Then again, a good IDS would also possibly alert about SMB-based traffic being used on a web port (e.g., 80, 8080). As you can see, a good hacker needs to use good judgment, too.

Figure 9 shows what the very beginning of this attack looks like in Wireshark. Notice the SMB-based communication and how the traffic starts at port 445 from system1 (IP address 172.16.190.158, marked with the red circle). Then, you can see how system2 (172.16.190.159) begins the SMB protocol version negotiation and how NT LAN Manager 1.0 and 1.2 are being negotiated.

Figure 9: Viewing an EternalBlue attack in Wireshark.

This observation is important, because the EternalBlue attack takes advantage of Microsoft Windows systems that mishandle specially crafted packets. When the affected Microsoft systems mishandle requests, a shell is left behind. Attackers can then use this shell to execute remote code and administer the system remotely without proper authentication credentials. In other words, you are seeing what the beginning of an EternalBlue attack looks like from the perspective of a security analyst.

Figure 10 shows the point where the EternalBlue code from Meterpreter has been able to open the reverse shell on port 4444 and begin creating a login shell for me to execute arbitrary code. If I try to trace the traffic stemming from system1 to system2, it is fully encrypted, much like the Microsoft SMB traffic I profiled earlier in Figure 4.

Figure 10: Metasploit's EternalBlue attack spawning a reverse shell at port 4444.

This is where my trusty copy of Wireshark really can't do much more good for me as a security analyst. Still, it is often the case that other exploits don't have a fully encrypted data stream. If that's the case, you can use information gathered in a Wireshark TCP or UDP trace to better program an IDS application or SIEM implementation.

On the Windows System

So far, I've focused on network-based traffic. Figure 11 shows the types of processes that the Metasploit EternalBlue attack spawns on the Windows system. Although it's awfully difficult to differentiate this process from any other legitimate instance of PowerShell, if you right-click on this instance, you can further trace what it is doing, as shown in Figure 12. Notice that this particular instance has opened a suspicious socket – in this case, one that goes back to the attack on system1 using port 4444.

Figure 11: Viewing the PowerShell process opened by the Metasploit EternalBlue attack.

Figure 12: Inspecting a PowerShell instance with Process Explorer.

Successful attackers are really never happy with simply gaining access to a remote system. A compromised, admin-level shell on a remote system is a precious but fleeting thing. In other words, all it would take is for a user to reboot the Windows system or for an antivirus update to eliminate the hacker's hard work and shut down port 4444, or whatever port the attacker is using.

Therefore, a hacker will always try to establish persistence, which is a hacker trying to create a more legitimate way back into the system that is more difficult to discover. That way, the hacker can take their time and return to the system using a more legitimate method. That makes the hacker's activity all the more difficult to discover.

Credential Harvesting

One of the more typical attack methods is to glean usernames and passwords stored in the registry. This activity is an example of "credential harvesting." Two common ways to harvest usernames and passwords in Windows systems are with the use of:

Windows Credential Editor (WCE), which allows you to "dump" a credential, as well as change a user password. Installed by default in Metasploit, you can upload it and activate it during a Meterpreter session.
The Meterpreter lsa_dump_secrets module, also installed by default, which allows you to dump password hashes and, if you are lucky, cracks the passwords during the process.

You can use either or both of these tools. In the exploit shown in Figure 13, the attacker has been able to use Metasploit's WCE to download passwords from system2, the victim system. The highlighted code is a Windows LAN Manager hash that an exploiter can then decode using an application such as John the Ripper, or any of the dozens of online hash-cracking tools (e.g., CrackStation [8] or GPUHash.me [9]).

Figure 13: Using Metasploit's Windows Credential Editor (WCE) to harvest passwords.

An attacker could even download the hashes of previously used passwords that are stored in the password history portion of the registry. Windows systems often store the hashes of the system's password history to enforce password reuse policies so that end users don't simply reuse old passwords when it comes time for them to change. You can do this with Meterpreter's lsa_dump_secrets module, as shown in Figure 14.

Figure 14: An attack with Metasploit's lsa_dump_secrets command.

In this case, the lsa_dump_secrets command dumps various password hashes. I also got lucky – Metasploit's Local Security Authority (LSA) feature was able to decrypt the default admin password and even give the old password for that account.

All of these activities are traceable from a security administrator's perspective. Figure 15 shows how each of the above activities spawned a new command-line shell on the Windows system. Now you know how to do more than just create a credential-harvesting exploit; you know what one looks like, as well.

Figure 15: Viewing newly spawned shells in Process Explorer.

Hackers often activate legitimate services and ports in their quest for persistence. For example, many Windows systems administrators still use Microsoft Remote Desktop Protocol (RDP), so if an attacker still has access from the EternalBlue exploit, why not enable RDP by making a simple little change in the registry (Figure 16)? In the lengthy command, the attacker knew exactly which registry entry to enter: It is easily found online.

Figure 16: Editing the Windows registry in Metasploit.

Figure 17 shows what a security analyst will see if they are auditing this process manually with Process Explorer. You can see how the reg.exe process attempted to edit the registry. At first, access is denied, but then, the highlighted entry shows that the change is granted. With this change, I, as the attacker, now have the ability to use RDP. I can simply use any RDP client (e.g., rdesktop) to access the victim system with the use of the legitimate username and password that I had already harvested:

Figure 17: Viewing registry changes in Process Explorer.

rdesktop -u user 172.16.190.159

Now, even if someone discovers my EternalBlue exploit and shuts down port 4444, I can still log back in at any time via RDP (Figure 18), or I can walk up to the system and log on locally. I have therefore just established persistence on my system.