Determining Users Logged On to the System

Two similar commands are available to determine the users currently logged into a Linux system.

Determining User Activity

It is also important that the administrator know the activities of the users on the system.

Determining the State of the System

Sometimes the administrator wants to know the current state of the system, including determining which processes are running or which network connections have been made.

Detect: Java JAX-WS Remote Code Execution

Chapter 2 showed how to run the Java Applet JAX-WS Remote Code Execution attack against a Linux target running Java 7. Configure and run the attack, say against a CentOS 6.0 64-bit system running Firefox and Java 7 Update 0; for the payload use Java Meterpreter running through reverse HTTPS, connecting back to the attacker on port 443. Interact with the target and start a shell.

This shows a Firefox process (3230) spawned a Java process (3521), which seems normal enough. On the other hand, why is another Java process (3578) unrelated apparently to Firefox spawning a pair of Bash shells² (3615, 3640)?

The victim is located at 10.0.2.10, and the SSH connection to port 22 from 10.0.2.18 seen earlier is noted. Also noticed is what appears to be an HTTP connection to the site 184.29.105.107; a lookup of the IP address shows that it is named a184-29-105-107.deploy.static.akamaitechnologies.com. Nothing in this suggests anything malicious, at least not yet. On the other hand, the last line is perplexing - it appears to be using stateless translation between IPv4 and IPv6 to connect to 10.0.2.248, yet the system is on a network that was not configured to support IPv6.

This affirms that the connection out to 10.0.2.248 is suspicious, as 3578 is the Java PID that already seemed out of the ordinary.

Much of what is shown is standard; for example, Java libraries have been loaded into memory. There is the IPv6 connection that appears to be running between IPv4 addresses; there also appears to be a pair of deleted temporary files that were in /tmp that are named jar_cache(long-number).tmp.

An attacker that writes files to a target system runs the risk that these files will be detected by the defender, and subsequently analyzed.

Detect: Firefox XCS Code Execution

Chapter 2 showed how to attack Firefox directly with the Firefox 5.0 - 15.0.1 __exposedProps__ XCS Code Execution attack. Configure the attack using the default JavaScript XPCOM shell running on the default port (TCP/4444) for the payload. Visit the malicious web page with a vulnerable Ubuntu 12.04 desktop system using the vulnerable (and default) Firefox 14.0.1, and obtain a session on the target.

There are two connections of interest. The first (1567) runs on HTTP and appears to be a connection from a local Ubuntu named service to a host at Canonical, the makers of Ubuntu. The second connection (1757) is much more suspicious; it is a browser making an outbound connection to a host on TCP/4444, which is known to be the default port for many Metasploit payloads.

Because Firefox is a web browser, outbound network connections from it are expected. Had the attacker selected a more appropriate port (e.g., TCP/443) for the payload, then the analysis of the network connections would have shown nothing of interest. The JavaScript payload runs within Firefox, so this attack created no new processes to arouse the suspicion of the defender. This brief analysis of the Firefox process itself shows nothing out of the ordinary. Taken together, this attack is much less detectable than the first example. On the other hand, the stealth comes at a cost, as the attacker is trapped in the Firefox process. Once Firefox is terminated, the attacker loses access to the system.

Determining Users Logged On to the System

One way to determine the users logged on to a system is to use one of the tools from the Sysinternals suite. The Windows Sysinternals Suite is a collection of 70 tools that are invaluable to a Windows system administrator. The tools can be downloaded in a group from https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite ; they can also be downloaded individually.

Determining the State of the System

Just like on Linux, an administrator of a Windows system can examine the processes running on the system as well as the system’s network connections.

Task Manager

Windows Task Manager (Figure 3-1) displays the running processes in a graphical tool. It can be started with the keyboard shortcut CTRL+SHIFT+ESC; it is also one of the options available on a running system after pressing CTRL+ALT+DELETE on a logged-in system.

Process Explorer

The Sysinternals tool Process Explorer (procexp.exe) (Figure 3-2) when run as administrator provides a more feature-rich tool to manage running processes. Process Explorer color codes the process name by the process type.

• Green: New processes

• Red: Deleted processes

• Gray-Blue: Processes run by the same user running Process Explorer

• Pink: Services

• Gray: Suspended processes

• Purple: Packed processes, meaning that it is compressed or encrypted. Though some legitimate processes are packed (e.g., IrfanView, a common image viewer), some malware also uses this technique.

• Yellow: .NET processes, or DLLs that have been rebased in memory

• Brown: Jobs

• Teal: Immersive processes; these are only found on Windows 8, Windows Server 2012, and later operating systems.

Process Explorer can verify that processes on the system are running with verified signatures; from the Options menu select Verify Image Signatures. An additional column is shown; if the application is signed, then the publisher is listed. Though many legitimate applications are signed, not all are.

Process Explorer can submit the hashes of running processes to VirusTotal for analysis. VirusTotal, available at https://www.virustotal.com/en/ , checks the submission against different antivirus tools. When VirusTotal is used with Process Explorer (navigate Options ➤ VirusTotal.com ➤ Check VirusTotal.com), a new column appears in the display indicating the number of antivirus products that considered the file malicious and the total number of antivirus products checked. Clicking on the hyperlink in that column takes the user to the corresponding web page on VirusTotal.com.

Double-clicking on any process brings up a dialog box with the properties of that process (Figure 3-3).

One tab provides information about the image, including the file name, its version, its current working directory, and its parent process. The administrator can use the “Bring to Front” button to have the process appear as the top application on the Desktop. The TCP/IP tab lists all active network connections for the process. Other tabs provide information about process execution, performance, disk and network, running threads, and the environment variables for the process. The strings tab lists the text strings that occur either in the image or in memory.

Process Explorer can replace Task Manager; from the Process Explorer main menu, navigate Options ➤ Replace Task Manager.

An open source tool that provides many of the features of Process Explorer is Process Hacker, available at http://processhacker.sourceforge.net .

TCPView

The Sysinternals tool TCPView (tcpview.exe) (Figure 3-4) provides a graphical way to view network connections on the system. Each connection is color coded: new in green, recently closed in red, and connections that have recently changed state in yellow.

Right-clicking on an entry in TCPView brings up a context menu that allows the user to determine the properties of the process that started the connection; it also allows the user to run a whois query on the connection’s destination.

Detect: MS13-055 CAnchorElement

Chapter 2 showed how to run the MS13-055 CAnchorElement attack against Internet Explorer 8 on a Windows 7 system running with Java 6 installed. Run the attack, using the Meterpreter payload and reverse HTTPS.

Process Explorer (Figure 3-5) notes the notepad process; unusually, it is running as a child process for Internet Explorer. Double-click on the notepad.exe process; from the Image tab, use the button to “Bring to Front”; this should bring the window(s) used by that process to the top of the Desktop. This fails, with a message, stating that “No visible windows found for this process.” Together, this is quite suspicious.

On the other hand, the image has a valid signature from Microsoft, and VirusTotal raises no warnings. This combination of behaviors is expected; as noted in Chapter 2, Metasploit injects its code into running processes and spawned the notepad process to ensure its survival if Internet Explorer is closed. Since the original notepad.exe on the disk is unchanged, its signature remains valid, even though it was modified after it began running.

A check of the TCP/IP resources used by the notepad process or either of the two parent Internet Explorer processes does not show any connections; neither does TCPView. Downloading a large file (say 50 MB) from Meterpreter is enough that TCPView notes the connection but then only fleetingly.

The PID (1592) for the connection back to the attacker (10.0.2.251, TCP/443) is the PID for notepad.exe, not the command prompt.

This network connection remains, even if the attacker backgrounds the shell in Meterpreter, or even backgrounds the entire session.

In this example, the defender did not so much detect the MS 13-055 CAnchorElement attack, but rather detected the activities of the attacker once they were on the system. The notepad.exe process (PID 1592) as a child of an iexplore.exe process (PID 2724) was the first anomaly. If the attacker spawns a shell, then the notepad.exe process makes an outbound network connection, providing a second anomaly. This is one reason why attackers take care to manage what artifacts they leave on the system.

Detect: Adobe Flash Player Shader Buffer Overflow

Suppose an attacker uses the Adobe Flash Player Shader Buffer Overflow attack against the default version of Flash included as the plugin for Internet Explorer 10 in Windows 8. This attack is launched in the same way as other attacks shown in Chapter 2.

Process Explorer (Figure 3-6) shows a pair of Internet Explorer processes; the second (2124) is a child of the first (2076). It also shows a new instance of svchost.exe, running the Flash Player Plugin. These applications are running with verified signatures and without being flagged by VirusTotal.

The connection to the attacker’s system is difficult to detect. In general, it does not appear in the TCP/IP tab of the processes in Process Explorer; it does not appear in TCPView; and it does not appear in netstat, unless the attacker is making extensive use of the connection between the systems at that moment. Downloading a large file, for example, is sufficient for the connection to briefly appear. The connections are not associated with the Flash plugin, but instead associated with the child Internet Explorer process (PID 2124).

If the attacker leaves Meterpreter and starts a Windows command shell on the target using the Meterpreter shell command, then two new processes are spawned: a conhost.exe whose parent is cmd.exe whose parent is the child Internet Explorer process. Even then, unless the attacker is actively and extensively using the network, the connection does not appear in TCPView.

The original attack did not spawn a second process, making its detection on the target more difficult. On the other hand, if the Internet Explorer process is killed, the attacker loses their connection.

Tcpdump

This collects network traffic and stores the results in traffic0 until it collects 100 MB of data; then it stores the results in traffic1 until it fills, on through traffic4. When the last file fills, the original traffic0 is be overwritten with new data, and so on.

Wireshark

Wireshark is an excellent tool used to analyze captured packets. It is possible to use tcpdump to do so, but tcpdump lacks a graphical user interface. It is also possible to use Wireshark directly to capture packets, and this is often reasonable for small captures to help debug a network problem.

A Windows installer is available from the Wireshark page at https://www.wireshark.org/download.html . That page also has links to older versions of Wireshark.

To analyze multiple packet capture files, they must first be merged. The simplest way to do so is to drag and drop the files into Wireshark. Wireshark does have the ability to merge two packet capture files (navigate the main menu through File ➤ Merge), but this only functions on two files at a time, and one must already be saved.

The default Wireshark display (Figure 3-7) breaks into three panes. The top pane provides a column-based list of the received frames/packets; the middle pane summarizes the details of the frame/packet broken down by component; the bottom pane is the raw data from the frame/packet.

The highlighted frame of Figure 3-7, number 11, is an Ethernet frame containing a UDP packet from the Google nameserver at 8.8.8.8 returning with the results of a DNS query.

Packets and frames in the list are color coded by type. Additional columns can be included in the list; one particularly useful column is the absolute time that the packet was received. Right-click on the column headers and select Column Preferences. Select Add; for the Field Type select Absolute Time and give the column a name.

The Statistics entry in the main menu provides an entry point for tools that summarize the properties of the packet capture. For example, Protocol Hierarchy (Figure 3-8) breaks down the packets by type.

Wireshark collects packets into conversations that have the same endpoints. To view the TCP conversations, navigate the main menu through Statistics ➤ Conversation List ➤ TCP (IPv4 & IPv6) (Figure 3-9). The Follow Stream button shows the content of the conversation in a range of formats, including ASCII.

This just scratches the surface of what can be done with Wireshark; see the Notes and References section for some excellent resources to learn more.

Detect: Java JAX-WS Remote Code Execution

Chapter 2 demonstrated how to attack a Mint 13 system running Firefox 12.0 and Java 7 Update 5 with the Java Applet JAX-WS Remote Code Execution attack. Set up a Kali offensive system and a Mint 13 target; also set up a Linux system running tcpdump to capture the packets sent between the attacker and the target. Run the attack using the Java Meterpreter payload running through a reverse HTTPS connecting back to the attacker on TCP/443. Use Meterpreter to interact with the victim system to ensure that some interesting network traffic is generated.

Open the resulting packet capture (Figure 3-10) in Wireshark and examine the list of conversations. One set of conversations goes from the victim to the attacker on TCP/8080 (http-alt); this is the request that spawned the attack. Second and far more numerous are conversations starting from the victim going to the attacker on TCP/443 (https); this is how the attacker interacts with the victim.

The conversations on TCP/443 are more difficult to understand. As expected, the content is encrypted, and following the stream provides no useful data.

Though the traffic is encrypted, the TLS handshake shows unusual behavior. Open the TLSv1 Server Hello packet and examine the data for the certificate’s issuer (Figure 3-11).

In this example, the common name of the certificate issuer is “ytkrqnwt,” which appears random.

Considering the different HTTPS conversations together as a group, two facts stand out. The victim communicates with the attacker in bursts, each using a different source port. This explains why the connections were so difficult to notice during the host-based analysis. The timing of the connection attempts from the victim to the attacker is also suspicious. Examining the relative start time for the connections, they appear to go out from the victim roughly every 10 seconds (Figure 3-10).