[vc_row content_placement=”middle”][vc_column width=”2/3″][vc_wp_text]
[/vc_wp_text][/vc_column][vc_column width=”1/3″][vc_wp_text][xyz-ips snippet=”metadatatime”]
[/vc_wp_text][/vc_column][/vc_row][vc_row content_placement=”middle”][vc_column width=”2/3″][vc_column_text]
With IT security technology rapidly improving, an increasing number of organizations are turning towards analytics, AI, and automation to help with managing the complex task of detecting and remediating cyber-attacks as well as to assist in reducing dwell time. These tools are becoming increasingly advanced by the day, and have become the industry standard for IT security. On the other hand, many of the cybersecurity tools used nowadays utilize predefined rules and signatures to identify malicious activity. Subsequently these tools such as IDS, IPS and endpoint ATP are reliant on the developers to keep their rules and detection methods up to date. Until new threats are identified and corresponding rules are created, many of these tools will struggle to identify novel threats.
The upside of automation and analytics cannot be downplayed, however the need for SOC teams to be able to analyze system and network data directly, has become even more critical as automation is increasingly relied on. This is where threat hunting comes in. Threat hunting is the proactive practice of searching through IT systems to identify advanced threats that evade existing security solutions. Once an attacker successfully gets through the initial security mechanisms, they can stealthily remain in a network for months as they silently collect sensitive information or obtain login information that they can use in future for further attacks.
Many methodologies exist for how to conduct threat hunting, but the topic for this blog post is going to revolve around the Hypothesis-driven approach. This approach starts with an assumption or an idea on how our system might be compromised. This hypothesis could be triggered among others by observing threat patterns and vectors through various cyber threat intelligence sources or perhaps a suspicious phenomenon that we observed in our own network. Either way the analyst will take this hypothesis and will dig through vast amounts of data generated by the systems in the network, looking for any indicators that may support the hypothesis. To do this the analyst must have the right tools and sufficient data to search through.
One of the data sources that could provide the necessary data is packet captures. Packet capture is the process of intercepting and logging network traffic. As data moves across the network, the packet capture software or appliance captures each packet and, if needed, decodes the packet’s raw data, showing the values of various fields in the packet, and analyzes its content according to the appropriate specifications. This is just about the most in-depth data that can be provided to an analyst. As such it will contain extraordinary amounts of noise and thus will take a substantial amount of storage to hold the data, which may be a consideration for many organizations. A simple solution for this may be to simply only turn on packet capturing when hunting for a specific threat, or perhaps to apply filers in order to only log what is necessary. Another solution may be to use something a bit more light-weight such as Netflow as discussed in an earlier blog post, but in certain situations this may not be granular enough.
The contents of packets are incredibly useful for detecting well hidden, novel and persistent threats. Expertise in capture analysis, however, is an esoteric field, and the keen eyes necessary for such a job are hard to come by. Such an expert gives organizations a second line of defense against even the most advanced threats. The practice of threat hunting in packet captures is especially important as these efforts often focus on the post exploitation phases of the cyber kill chain. This means detecting active threat actors that have already infiltrated our network, before the damage is done. Dodging a bullet like this is something that is very difficult to achieve through means other than threat hunting with the help of packet capture analysis.
For instance, in the figure below we can see a packet that contains simple malicious code and is part of stage that is sent when a Meterpreter shell is established. These packets didn’t trigger any alerts with our open source IDS and could go easily undetected or could be erroneously labeled as false positive when looking only at network activity logs. However, it sticks out like a sore thumb in the packet capture and the nature of the packet can be decisively concluded leaving no room for error.
[/vc_column_text][/vc_column][vc_column width=”1/3″][/vc_column][/vc_row][vc_row][vc_column][vc_empty_space][/vc_column][/vc_row][vc_row][vc_column width=”2/3″][vc_single_image image=”30551″ img_size=”full” alignment=”center”][vc_column_text]Malicious packet in Wireshark[/vc_column_text][/vc_column][vc_column width=”1/3″][/vc_column][/vc_row][vc_row][vc_column][vc_empty_space][/vc_column][/vc_row][vc_row][vc_column width=”2/3″][vc_single_image image=”30552″ img_size=”full” alignment=”center”][vc_column_text]Malicious code reassembled from the packet stream.[/vc_column_text][/vc_column][vc_column width=”1/3″][/vc_column][/vc_row][vc_row][vc_column][vc_empty_space][/vc_column][/vc_row][vc_row][vc_column width=”2/3″][vc_column_text]
The usefulness of packet captures for eliminating false positives is something that often goes unnoted. When doubt arises when dealing with a potential incident, having the opportunity to dive down in to the specific packets that trigger the alert is incredibly useful. It helps reduce dwell time and allows for decisive decision making.
In conclusion having packet captures enables a new dimension for threat hunting allowing, allowing for conclusive identification of potential threats, in addition to the elimination of false positives. That is if the large amounts storage required and the endless packets of monotonous data don’t scare you away.