These days, protecting the network perimeter is a foregone conclusion. However, there is no longer a monolithic perimeter—there are often multiple perimeters to protect. Unauthorized attempts to cross perimeters are frequent, and the need to defend against threats is critical to protect your assets.
In any perimeter defense a key component is firewalls—the proverbial guard towers in your fortifications. They are chiefly responsible for controlling and inspecting the traffic coming into, and going out of, the network. And if they encounter unauthorized traffic or threats, they protect the network.
In this Threat Trends release, we’ll be looking at Cisco Secure Firewall. In particular, we’ll be talking about its Secure IPS component and the Snort rules it utilizes, examining what is regularly encountered and blocked.
To do this, we’ll look at Snort telemetry coming from Secure Firewalls, examine the most frequently encountered rules, rule categories, and consider these rules through the lens of the MITRE ATT&CK framework. The goal is to highlight the common threats that organizations encounter and block with Secure Firewall.
Table of Contents
Snort and detection policies
Before diving into the telemetry, let’s briefly cover how Snort rules are used within Secure Firewall. (A detailed explanation of Snort rules can be found in the Snort FAQ.)
Secure Firewall version 7.0 supports Snort 3 as the default inspection engine. Snort 3 provides better performance and scalability than its predecessor, Snort 2, using less memory and supporting more intrusion rules and a larger network map.
Snort is highly configurable, offering tens of thousands of rules to detect different types of activity. However, simply enabling them all is not recommended—doing so would not only result in an unmanageable tsunami of alerts but could drastically impact network performance.
To make managing rulesets easier, Snort rules are organized into policies. There are four base policies available to help with initial configuration and operation, though you can also create your own. The four base policies are:
- Connectivity over Security
- Balanced
- Security over Connectivity
- Maximum Detection
These policies add additional rulesets as they decrease in permissiveness. The “Connectivity over Security” policy is included in “Balanced” along with additional rulesets. “Connectivity over Security” and “Balanced” rules are in turn included in “Security over Connectivity,” in addition to further rulesets, and so on.
Which policy you choose depends on the environment you’re protecting. Cisco recommends using the Balanced policy in most environments to get the best mixture of security with the lowest number of false positive alerts. However, you may want to consider the other policies, depending on where the firewall is deployed. (Secure Firewall even provides automated recommendations to tune your ruleset to your environment, reducing false-positives and increasing network performance.)
The final policy, Maximum Detection, is mainly designed for testing environments, since it can lead to a high number of false positive alerts. We do not recommend that customers enable this policy because of this.
Finally, there are rules that do not belong to any policies. These rules can be added to custom policies, being tailored for specific situations, and can be located by searching for product names, CVEs, or other keywords.
Methodology
The goal of this analysis is to showcase the common threats that organizations encountered and blocked with Secure Firewall between April-September 2021 (Q2-Q3 2021). To do this, we’ve examined product telemetry that organizations have shared with us on an opt-in basis, which has been anonymized and aggregated before carrying out the analysis.
The Snort rules we’re looking at are the standard text rules and Shared Object rules, both provided by Talos Intelligence. It’s worth noting that the use of Snort and Secure IPS is only one component used by Secure Firewall to detect threats. There are other protection mechanisms, such as Malware Defense, that can block further threats.
Since we want to see which threats organizations frequently encounter, we’re analyzing rules in policies 1-3 described above, filtering out rules from the Maximum Detection policy and those that do not belong to any policies. As the lion’s share of deployments utilize one of these policies, this will give a clearer picture of what most organizations are facing, while also filtering out most false positives.
When blocking malicious activity, different rules and attacks produce different numbers of alerts, which can make comparing them difficult. For example, alerts produced by one firewall under a DDoS attack can easily dwarf the number of alerts generated from a single exploit that hits hundreds of organizations. Simply looking at the raw numbers in this case would give the false impression that DDoS attacks have a far greater impact across the base of organizations.
To address this, we’ll use distinct counts of organizations encountering rules. If a rule triggers at a particular organization, then we count that organization only once. This not only reduces the impact of noisy alerts in the data, but it allows us to show what percentage of organizations have encountered a particular rule. In essence, we can say that X percent of organizations encountered a particular rule between April and September.
Finally, the trends discussed here show what Secure Firewall is detecting. This may sound self-evident, but it’s important to note that what is seen is not necessarily indicative of the larger threat landscape. A firewall is likely to see more of a particular type of attack, while an endpoint protection application will see more of something different, as would an email gateway.
MITRE ATT&CK
To start, let’s look at Tactics and Techniques from the MITRE ATT&CK framework. Many of the rules released in the last few years, as well as older, frequently encountered rules, have been mapped to MITRE ATT&CK. (However, as mapping is only partial, the following should be taken as conservative estimates.)
| Tactic | Percent of organizations |
Techniques seen (in order of frequency) |
| Initial Access [TA0001] |
90.9% | Exploit Public-Facing Application [T1190] |
| Drive-by Compromise [T1189] | ||
| Valid Accounts [T1178] | ||
| Phishing [T1566] | ||
| Execution [TA0002] |
64.2% | Native API [T1106] |
| Command and Scripting Interpreter [T1059] |
||
| User Execution [T1204] | ||
| Shared Modules [T1129] | ||
| Windows Management Instrumentation [T1047] |
||
| Command & Control [TA0011] |
48.7% | Web Service [T1102] |
| Dynamic Resolution [T1568] | ||
| Discovery [TA0007] |
46.9% | File and Directory Discovery [T1083] |
| Application Window Discovery [T1010] | ||
| Network Service Scanning [T1046] | ||
| Remote System Discovery [T1018] | ||
| Network Sniffing [T1040] | ||
| Account Discovery [T1087] | ||
| Credential Access [TA0006] |
64.2% | OS Credential Dumping [T1003] |
| Unsecured Credentials [T1552] | ||
| Network Sniffing [T1040] | ||
| Forced Authentication [T1187] | ||
| Input Capture [T1056] | ||
| Privilege Escalation [TA0004] |
41.1% | Exploitation for Privilege Escalation [T1086] |
| Access Token Manipulation [T1134] | ||
| Hijack Execution Flow [T1574] | ||
| Valid Accounts [T1078] | ||
| Defense Evasion [TA0005] |
26.7% | Access Token Manipulation [T1134] |
| Obfuscated Files or Information [T1027] | ||
| Deobfuscate/Decode Files or Information [T1140] |
||
| Rootkit [T1014] | ||
| Signed Binary Proxy Execution [T1218] | ||
| Hijack Execution Flow [T1574] | ||
| Valid Accounts [T1078] | ||
| XSL Script Processing [T1220] | ||
| Use Alternate Authentication Material [T1550] |
||
| Impact [TA0040] |
13.4% | Resource Hijacking [T1496] |
| Persistence [TA0003] |
7.3% | Hijack Execution Flow [T1574] |
| Valid Accounts [T1078] | ||
| Browser Extensions [T1176] | ||
| Server Software Component [T1505] | ||
| Lateral Movement [TA0008] |
5.8% | Remote Services [T1021] |
| Use Alternate Authentication Material [T1550] |
||
| Exfiltration [TA0010] |
2.8% | Automated Exfiltration [T1020] |
| Exfiltration Over C2 Channel [T1041] | ||
| Collection [TA0009] |
0.8% | Input Capture [T1056] |
Naturally, a firewall is more likely to see more Initial Access attempts given its position on the network perimeter, where 90.9 percent of organizations saw alerts for this tactic. Organizations saw exploit attempts against public-facing applications, such as Apache Struts, Bash, and Exchange Servers. Drive-by Compromise techniques, such as detecting connection attempts to spoofed websites and SMB share access attempts, were also frequently encountered.
Execution attempts were seen by 64.2 percent of organizations. Common rules that alerted on such activity covered vulnerabilities in content management systems (CMSes), the Zeroshell Linux vulnerability, and an Apache Struts code execution vulnerability. (Apache Struts also features prominently under Privilege Escalation and Defensive Evasion.)
Command and Control activity came in third, where 48.7 percent of organizations saw traffic of this type. Much of this traffic is comprised of suspicious DNS queries, which point to known or likely Command and Control sites.
Discovery tactics such as attempting to traverse administration files in a CMS was frequently seen. DNS BIND information disclosure attempts were also commonly encountered.
In the Credential Access tactic, credential dumping attacks appear to be targeting routers and IoT devices such as CCTV cameras. In particular, organizations saw alerts for attempts to exploit vulnerabilities that can provide admin credentials or attempts to access PHP configuration files.
Snort categories
Now we’ll drill down deeper into the ruleset and talk about some of the frequently encountered rules. To do this, we’ll examine the various rule categories in Snort. Beyond the policies described above, Snort rules are also organized into categories that group similar rules together. These category groups can then be enabled and disabled in Secure Firewall as needed.
So let’s talk about some of the most commonly encountered categories and the rules in them.
SERVER-WEBAPP
Our most common category largely lines up with the most encountered MITRE ATT&CK technique, Exploit Public-Facing Application. This category is one of the more varied of the bunch as well, including rules to detect unwelcome connections to a wide variety of applications.
CMSes were a popular target. Alerts for a vulnerability in PHPUnit, a widely used PHP testing framework used by many CMSes, and alerts for a vulnerability in the Drupal CMS framework were regularly seen.
Alerts for vulnerabilities in the web interfaces or authentication processes of several routers and IoT devices were a regular occurrence. Unsurprisingly, the most recent vulnerability is associated with the Hafnium attacks discovered last March, which exploited Microsoft Exchange zero-day vulnerabilities.
OS_OTHER
Most alerts seen in this category during this timeframe came from rules designed to detect a group of vulnerabilities commonly referred to as ShellShock. These vulnerabilities can give an attacker unauthorized access to vulnerable operating systems that use Bash.
Why are a series of exploits from 2014 showing up so prominently in 2021? It’s likely because these old vulnerabilities have made their way into automated scanners or botnets that hit every open HTTP server they can find and launch a laundry list of exploits.
SERVER-OTHER
A few SSL-related exploits comprise much of the activity in this category. In particular, the Heartbleed vulnerability from 2014. Like ShellShock, the exploit for this vulnerability is present in many automated hacking tools.
| Rules | Rule description | CVEs (if applicable) |
| 30524 | OpenSSL TLSv1.1 heartbeat read overrun attempt | CVE-2014-0160 |
SERVER-APACHE
The alerts seen in this category are predominantly made up of vulnerabilities in Apache Struts.
SQL
Alerts in the SQL category tend to center around injection attempts. However, few of these have CVEs assigned to them, likely due to being the result of poor database security practices, rather than an inherit flaw in the software itself.
| Rules | Rule description | CVEs (if applicable) |
| 19438 | url ending in comment characters – possible sql injection attempt | CVE-2012-2998 |
| 19439 | 1 = 1 – possible sql injection attempt | |
| 16431 | generic sql with comments injection attempt – GET parameter | |
| 49666 | HTTP URI blind injection attempt | |
| 19440 | 1 = 0 – possible sql injection attempt |
Other categories
While this summarizes some of the most seen categories, there are many other categories beyond this. For example, CNC traffic from botnets such as Ursnif, Remcos, and Lokibot appeared in the MALWARE-CNC category. And SMB exploits and overflow attempts featured regularly in OS-WINDOWS.
Defending the perimeter
At this point it may appear as though network perimeters are under constant attack. While largely true, this does vary between organizations and which specific perimeter the firewall is defending. Some see thousands of alerts a day and others only a few.
It’s important to note that many organizations may not use the applications or devices that Secure Firewall can alert on. That is why IPS tuning is important to reduce analyst alert fatigue. The fact is that many exploit attempts are carried out in an automated fashion, where the attacker launches a tool containing many exploits. In these cases, they’re most likely attempting to see what works for future attacks.
But beyond this, it’s important to carefully consider which systems and applications are public-facing. Be sure to keep these systems up-to-date with the latest patches as soon as possible to avoid compromise when a new vulnerability is discovered.
Finally, a firewall with IPS capabilities, such as Cisco Secure Firewall, can go a long way towards blocking these attacks.
Get started today!
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Instagram
Facebook
Twitter
LinkedIn
Share:
Leave a Reply