Analyzing security alerts from IDS or endpoint protection

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

Endpoint Protection Solutions or Intrusion Detection Systems can detect malicious events based on heuristics or signatures, and AI in newer solutions. They generate alerts via email, Syslog, Webhooks, or other means. However, effectively analyzing the root cause of these alarm messages to identify and respond to potential threats requires advanced tools and methodologies.

This article explores how the Profitap IOTA network traffic capture and analysis solution empowers security professionals to analyze IDS alarm messages, thereby enhancing network security comprehensively.

The first step is to capture the affected traffic. There are two options for capturing network traffic with IOTA: in-line or via a SPAN connection. If we have permanently deployed IOTA, we can retrospectively analyze traffic patterns immediately after an alert comes in. Where IOTA is placed in the network must be decided based on the desired application.

Our analysis process differs based on whether the messages come from an Endpoint Detection and Response (EDR) system or an Intrusion Detection System (IDS). Therefore, we have described various approaches to analyzing security alerts.

The first step in a retrospective analysis is to choose the desired time window. We select this in absolute terms (from … to) or relative to the current time in the top right-hand area of the IOTA interface. The time window should be restricted as far as possible to simplify the following analysis.

Figure 1: Apply a relative or absolute time filter on the IOTA dashboard.

We start our search for an attacker at an affected host. Let's start with the host where the attack or unusual behavior was first detected to find the so-called patient 0 and limit the time window accordingly.

If it is a known attack, searching specifically for communication patterns, such as specific target ports, may be possible. We also use this as an example. We assume a ransomware attack on a file server that provided its services via Server Message Block (SMB) in the network. The server's IPv4 address is 192.168.178.6.

We know that SMB is operating on TCP port 445, so we filter on this target port. This shows us that only client 192.168.178.22 had established an SMB connection with the file server during the encryption time window.

Figure 2: Filtered view by Destination Port 445 and IP Address 192.168.178.6. The flow graph is also filtered.

Here, we use the filter “IP_SRC = 192.168.178.22” to check which communication relationships were established shortly before by client 192.168.178.22 and to clarify whether command and control traffic or a download was taking place.

Only one communication relationship had previously left the internal network—specifically, a TCP connection with TLS on destination port 443, i.e., HTTPS. From here, we used the download feature of IOTA to download the entire flow and the corresponding flow. Now we can check the TLS extension Server Name Indication (SNI) in the client hello to clarify which hostname the client had used to establish a connection.

Figure 3: List of Flows on the Overview Dashboard. We can download them as PCAPNG, inspect the specific flow in detail, or filter them by selecting the + symbol to make an inclusion filter or the – symbol to make an exclusion filter.

A further analysis has to be carried out on the client in the log files themselves, as the download itself is not recognizable in plain text due to the TLS encryption. This showed that the user had downloaded and installed a malicious application, which then performed the encryption of files via the analyzed SMB network share.

These steps have provided us with 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 “front-end servers” of the attackers, which also change from time to time.

However, as lateral movements in the network are often recognizable in the case of attacks, other clients should also be checked, as the affected client could have already distributed the malware. If no external communication relationship is recognizable on the affected client, all internal communication patterns should be checked for anomalies that could have brought malware to client 192.168.178.22.

To first recognize which remote stations this host has communicated with, we can go to the Overview dashboard and simply click on the IP address in the flow diagram. IOTA then applies an IP filter to the IP address clicked on with source and destination address.

Figure 4: Filter by IP address and see captured flows. In this graphic, we can see two flows.

We subsequently recognize several IPv4-based communication patterns. In the example, the host communicated with six other addresses, one of which was the broadcast address (255.255.255.255), and 192.168.178.1 was the gateway. We also see multicast addresses 224.0.0.251 and 239.255.255.250. This leaves us only 192.168.178.6 and 192.168.178.25. As 192.168.178.6 is the file server itself, we can assume that 192.168.178.25 is the only other host.

Filtering on 192.168.178.25 allows us to investigate all communication patterns connected to this IP. If there is only one flow to 192.168.178.22, we can assume that 192.168.178.25 is patient zero.

In the following example, a customer datacenter network IDS reports an ARP spoofing attack. The IDS told us that IP address 192.168.178.21 is affected by this attack. We need to get the MAC address of the attacker to search the network for the switch and corresponding port at which the attacker resides.

The customer datacenter IP network was statically addressed, so we should only see a one-to-one mapping between the IP and MAC address. We go to the Local Assets dashboard to investigate this IDS alert with IOTA.

Figure 5: Navigate to the Local Assets dashboard.

Afterward, we can filter by source IP address by implementing the filter rule “IP_SRC = 192.168.178.21”. We can see two MAC addresses under “Client's inventory list”. MAC address 14:1A:97:9E:AC:D5 is the original mac address. Therefore, the attacker has a MAC address of 60:3E:5F:36:2B:5B, as shown below.

Figure 6: We can see two MAC addresses regarding IP address 192.168.178.21. Therefore, we have both MAC addresses.

Now, we have all we need to search our switches for attacker positioning on the network.

As another example, our IDS system connected to a TAP generated an alarm message for a TLS downgrade attack. The affected company policy only allows TLS versions 1.2 and 1.3, so we need to investigate which hosts are using TLS versions 1.0 or 1.1. To do that, we navigate to the SSL/TLS Overview dashboard.

Figure 7: Navigate to the SSL/TLS Overview dashboard.

On the SSL/TLS Overview dashboard, we can see unsafe configurations with TLS 1.1 or 1.0 and the Configuration column on SSL/TLS servers.

We can filter by “TLS_SERVER_VERSION < TLSv1.2” to only get unsafe connections, as shown below. There, we have one server with IP address 192.168.178.6, which has TLSv1 and TLSv1.1 active, and we have 160 flows affected by the unsafe transport encryption methods. We now know that this is the only server that can be affected by this attack.

Figure 8: SSL/TLS Overview dashboard with filter for unsafe TLS versions.

Afterward, we would like to investigate if this server also has safe versions enabled. On the SSL/TLS Overview dashboard, we created a filter of “IP_DST=192.168.178.6” to filter by our affected destination IP address. We can see that this server also has safe versions of TLSv1.2 and TLSv1.3 enabled. Therefore, we can assume that this server was affected by a TLS downgrade attack.

Figure 9: SSL/TLS Overview dashboard with all TLS versions offered by IP address 192.168.178.6.

Our next security event is generated by our endpoint protection. IOTA can identify port scans and clear up which host generates them. Therefore, we need to navigate to the TCP analysis dashboard.

Figure 10: Navigate to the TCP Analysis dashboard.

On the “TCP Analysis” dashboard, we can filter on “Incomplete 3-way or w/o Data”. This helps us inspect so-called TCP half-opens as Incomplete 3-way.

TCP half-opens help identify attackers who send SYN, wait for SYN/ACK, and leave the handshake open. Attackers gain information about open ports without finishing the TCP handshake with ACK. Some scenarios show handshake data without data transmission, indicating port scans.

Figure 11: TCP Analysis dashboard with a filter on source and destination IP address and our indicators “Incomplete 3-way” and “w/o Data”.

Sometimes, exporting captured data for thorough forensic analysis or further investigation is required. This process can be performed on-demand or proactively, ensuring we are not limited by the IOTA storage capacity.

We can navigate to the “IOTA Data Vault” option in the left-side menu to facilitate this. Subsequently, we can proceed to “Capture Export,” where we can choose the preferred protocol, namely WebDAV or FTP. Credentials and error handling can be configured by clicking “Apply” to initiate the export process. Following this protocol, captured data is uploaded to the designated server as PCAP files at thirty-second intervals.

Figure 12: Regular export to a WebDAV server.

All captured data on the IOTA SSD can be accessed in the IOTA Data Vault's “Captured Files” section as PCAPNG files. IOTA generates new PCAPNG files every thirty seconds. We can select the required data by start time and click download. With the capture files downloaded, we can analyze payloads in Wireshark if needed.

Figure 13: Selection and download of PCAPNG files for further investigation in Wireshark.

IOTA allows flexible network integration and capturing options to react to security alerts. Capturing can be done on-demand after an alert is reported, or as a permanent rolling capture.

Permanent capture is recommended so the required data is instantly available for analysis after an alert is raised.

Traffic can simply be exported as PCAPNG and imported later to analyze it as needed. IOTA enables us to quickly and effectively analyze malicious communication patterns using the provided dashboards. Flexible filter combinations and the option to drill down can speed up root cause analysis.

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