Retrospective analysis

Learn more about the IOTA solution at profitap.com/iota

In many situations, such as sporadic errors in the network or attacks on networks, a retrospective network communications analysis must be done. In the case of performance issues, the cause must be identified, and in the case of malware or intrusion, the source of the attack must be located.

The first step in a retrospective analysis is to select the desired time window. We select either an absolute time range (from … to…) or a time range relative to the current time in the upper right area. The time window should be restricted as much as possible to simplify the following analysis.

Figure 1: Overview Dashboard with a selection of absolute and relative time windows for analysis.

When searching for error causes, we start with the host where the error occurred and then work our way to the root.

However, not all error patterns can be analyzed with the same workflow. In this case, we are dealing with an incorrectly functioning connection.

The only information we have is that the affected host has the IP address 192.168.3.102 and that the error occurred on 03/18/2023 between 16:00 and 17:30. We do not know the IP address or port of the target server.

By restricting the absolute time window, we can already see a significant reduction in connections in the flow diagram of the Overview Dashboard.

Figure 2: Restricting the absolute time range of the analysis to 03/18/2023 from 16:00 to 17:30.

Next, we filter for the previously mentioned IP address of the affected host. To do this, we can either click on the corresponding IP address in the flow diagram or enter the IP address directly as a value in the search field to the right of the “IP” attribute field.

As a result, we see that our problematic host communicated only with IP addresses 192.168.3.1 and 168.61.99.98.

Figure 3: Graphical display of communication relationships for host 192.168.3.102 in the defined time window.

If we scroll down further in the Overview Dashboard, we get to the list of communication relationships. Here, we can see that besides DHCP (UDP ports 67 and 68) and ICMP messages from gateway 192.168.3.1, only the host 168.61.99.98 was requested on TCP port 9043.

The increasing client port numbers indicate multiple connection attempts or multiple parallel attempts to establish the socket. The payload 0 Bytes in the far right column shows failed connection attempts.

Figure 4: Tabular representation of the communication relationships with protocol and port numbers.

To examine how far the connection establishment on TCP port 9043 got, we click the Inspect button on the left of the list view. This brings us to the Flow Details dashboard for this specific connection.

In the Flow Details dashboard, we see that in the TCP Connection area, only one SYN packet was sent from the client to the server, but no SYN/ACK arrived as a response. This was the case in all flows to this destination server and port.

Either the initial SYN on the outbound transport path or the SYN/ACK on the return path seem to be blocked.

Figure 5: Flow Details of failed communication with the target server 168.61.99.98.

Next, we check the log files on the next hop, i.e., the IP address 192.168.3.1, which is the gateway and firewall simultaneously.

We notice that an outgoing firewall rule blocked TCP port 9043. Unblocking this destination port and the destination server 168.61.99.98 solved the problem.

We can see that failed TCP sockets are recognizable by SYN retransmissions and missing SYN/ACKs, which can be easily seen in the flow details of the IOTA.

Like the root cause example, we can start by searching for an attacker at an affected host.

Start with the host where the attack or unusual behavior was first detected, the so-called patient 0, and narrow the time window accordingly.

A targeted search could be made for communication patterns, such as specific destination ports if it is a known attack. This is what we’ll do in this example. We assume a ransomware attack on a file server that provided its services via Server Message Block (SMB) in the network. The IPv4 address of the server is 192.168.178.6.

Since SMB is operated on TCP port 445, we filter on this destination port. After applying the filter, we see that only client 192.168.178.22 had established an SMB connection with the file server during the time window of the ransomware file encryption.

So, using a filter “IP_SRC = 192.168.178.22”, we check which connections were established just before by client 192.168.178.22 to clarify whether there was any command and control traffic or a download taking place.

There was only one communication relationship that left the internal network before the attack. Specifically, a TCP connection with TLS on destination port 443, which is HTTPS. So, using the download feature of IOTA, we downloaded the entire flow alongside the corresponding flow and checked the TLS extension Server Name Indication (SNI) in the client hello to clarify which hostname the client was connecting to.

Further analysis has to happen on the client in the log files since the TLS encryption means that the download itself is not recognizable in plain text. Here, it’s determined that the user downloaded and installed an application. This executed the encryption process of files over the analyzed SMB network share.

This means we now have the IP address, hostname, and file that led to the attack. In some cases, however, the servers from which the malware is downloaded are only the attackers' “front-end servers,” which also change from time to time.

However, since lateral movements in the network are often detectable in the case of attacks, other clients should also be checked since the affected client could also have already distributed the malware.

If no external communication relationship is detected on the affected client, all internal communication patterns should be checked for anomalies that can bring malware to the client 192.168.178.22.

Learn more about the IOTA solution at profitap.com/iota