Firewalls are a staple in every enterprise environment and are typically the first line of defense protecting a network. They control the flow of traffic in and out of network boundaries based on a set of rules. The management of these rules will ultimately determine the level of security and protection a firewall provides. One of the fundamental rules in configuring a firewall is to deny all traffic by default, then create exceptions to allow services based on specific business needs. However, as business needs change over time, old policy exceptions may still be in effect. This increases the attack surface by leaving holes and weaknesses in the network perimeter. Hunting through firewall data isn’t only helpful for finding potentially malicious traffic; it also provides a look into general network traffic flow. Taking a broad look at what traffic is allowed out and from where will lead to a better understanding of how traffic is controlled outbound and where the gaps are.
As part of our Threat Hunting Use Case series, we’re sharing the use case below around outbound firewall traffic, developed and refined by our Research and Development teams, to help you get started threat hunting.
Use Case: Outbound Firewall Traffic
Objective: Baseline outbound network traffic using firewall logs to find perimeter weaknesses and identify anomalies that could indicate malicious network activity.
Log source & requirements: Firewall logs from Application-/Protocol-aware Firewalls
Duration: 7–14 Days
|What to look for||Why?|
|Baseline outbound firewall traffic by network segments and device types (workstation/servers).||It is important to understand what normal traffic looks like in the environment. Outbound traffic from workstations will look different than traffic by file servers and domain controllers. Better knowledge of traffic in the environment at a more granular level will make it easier to quickly identify anomalies and potential security gaps.|
|Correlate firewall policy rule names with the actions taken (traffic allowed vs. traffic blocked) to identify any gaps in network security controls.||Default factory settings, and custom policy exceptions that no longer fit a specific business need, may be inadvertently left in effect. These lead to unnecessary holes in the network perimeter, increasing the attack surface and making it easier for attackers to establish c2 communication and exfiltrate data.|
|What to look for||Why?|
|Identify anomalous and potentially malicious ports and application protocols by performing frequency analysis on those coming from few source IPs.||Malicious outbound traffic should be less frequent across devices in an environment than legitimate traffic. Identifying the least-frequent ports and application protocols across devices is a quick and easy way to highlight unusual traffic.|
|Review outbound traffic for ports and protocols that should only come from specific devices (e.g., DNS servers over port 53) and look for any irregular or unexpected devices.||Certain protocols like DNS, SSH, and FTP are typically seen from select devices that use the protocol for a specific business function. Traffic from devices that do not align with the business function should be reviewed for any additional indicators related to C2 traffic or data exfiltration.|
|Look for traffic where the port does not match the listed protocol (e.g., SSH over port 443).||An attacker may change the default port for a specific protocol to a more common port such as 443 to bypass network filtering and blend in with normal high-volume traffic.|
|Look for firewall traffic to countries in which the organization does not conduct business, especially those that are common sources of cybercrime.||Traffic to geolocations outside of the organization’s area of operation should be relatively infrequent. Filtering on attempted traffic to outside geolocations may help highlight anomalous traffic.|
|Look for outbound traffic with a high upload ratio (more data sent than received), sessions spanning a long period of time, or repeated sessions with a fixed amount of data.||An attacker may attempt to evade detection by data transfer threshold limits by using communication channels that transfer data in fixed increments.|
|Look for clients generating abnormal levels of blocked or denied traffic.||Devices with excessive blocked traffic should be reviewed to determine why the device is attempting to communicate outbound in a way that is prohibited.|
|Correlate firewall data with threat intelligence lists to identify any hits on known bad IPs.||Integrating IoCs from threat intelligence lists with a firewall hunt dataset is can help to easily identify potentially compromised devices communicating with known bad destinations.|
Make threat hunting a reality at your organization with ReliaQuest GreyMatter.
By aggregating and normalizing your data from disparate tools, such as SIEM, EDR, multi-cloud, and third-party applications, ReliaQuest GreyMatter allows your team to run focused hunt campaigns, both packaged and freeform, that are strategic and iterative. Use ReliaQuest GreyMatter to analyze indicators of compromise retrospectively or perform behavior assessments to visualize abnormal from normal activity.
Ready to kick-start your threat-hunting program? Get the white paper: Threat Hunting 101.
Check out the other blogs in our Threat Hunting Use Case Series: