Analyzing Network Data to Catch Hackers
Red Hand can analyze raw network data directly from network cards, network taps, and Packet Brokers. From a security standpoint, this is the optimal deployment method as it provides our detection engine with maximum visibility into network traffic, enabling it to identify suspicious activity more effectively.
Why Netflow?
Depending on your existing infrastructure and budget, accessing raw network (packet capture) data may not always be the easiest option. As an alternative, Red Hand can analyze network data from Netflow logs, which are often readily available from your switch vendor or cloud provider. If you already have access to Netflow logs, they can be easily integrated into Red Hand for a fully agentless deployment.There’s a lot to be learned from analyzing Netflow logs, and a wide range of malicious activities can be detected by doing so. However, it’s important to understand that the Netflow protocol was not designed with cybersecurity in mind, so using Netflow logs instead of raw packets does have some effect on the ability to effectively detect certain activities.
Limitations of Using Netflow for Detections
| No data below layer 3 |
Description: There is no visibility into protocols below the IP layer, such as Ethernet, ARP, STP, CDP, 802.1Q (VLANs), and others. Consequences: Low-layer discovery and mapping techniques, address spoofing, poisoning, and many types of man-in-the-middle attacks cannot be detected. |
| No data above layer 4 |
Description: There is no visibility into the application layer for critical protocols like DNS, DHCP, HTTP, TLS/SSL, SMB, LDAP, LLMNR, mDNS, NetBIOS, and others. Consequences: Application layer mapping and enumeration, masquerading, and many forms of injection and exploitation techniques cannot be detected. |
| No inspection of packet payload (Deep Packet Inspection - DPI) |
Description: Only metadata about connections is logged, while the actual data within the packets is largely discarded. Consequences: Signature and application layer fingerprinting capabilities, detection of application methods and actions, as well as stream reassembly and file extraction, are impossible. |
| No native name resolution available |
Description: Netflow does not resolve native DNS traffic to provide reliable and real-time entity names. Consequences: Investigating incidents without reliable and real-time name resolution is very difficult and prone to various identification errors. |
| Connection direction can be unreliable |
Description: Network connections will often appear reversed, causing clients to appear as servers and vice versa. Consequences: Higher rate of false positives when analyzing behaviors and activities for anomalies. |
| Connection duplicates exist in the data by design |
Description: Netflow aggregation strategies cause each connection to appear multiple times if the duration exceeds 1 minute (this duration can sometimes be extended). Consequences: Profiling entity behavior based on session duration, data upload, and data download is impossible, as this data is either unreliable or difficult to reconstruct. |
| Does not detect network tunnels |
Description: Netflow does not check for tunneling protocols that encapsulate other complete data packets using different communication protocols (e.g., VXLAN, IP-in-IP, GRE, SSTP, L2TP, PPTP, etc.). Consequences: Many forms of data transfer (such as exfiltration and collection), as well as command and control sessions that hide within legitimate protocols, cannot be detected. |