Threat Trends: Snort IPS

In this episode of ThreatWise TV, Brandon Stultz and Nick Mavis not only provide a great overview of Snort 3.0, but they also touch on the kind of vulnerabilities that tend to trigger the most Snort signatures.

Around 1½ years ago we looked at what Snort was seeing on Cisco Secure Firewall appliances. Given the rapid changes that can take place in the threat landscape, we decided to revisit the data set alongside this episode of ThreatWise TV to see how the landscape has shifted. Or has it? Let’s dig into the data and find out.

Our approach

Let’s briefly touch on how we’ve approached this data. Unless otherwise specified, we’re looking at January through December 2022. As we did last time, if a rule triggers at a particular organization, then we count that organization only once. Not only does this reduce noise from very active rules, but we can also say that X percent of organizations encountered a particular rule. (For more detail see the Methodology section below.)

Easy as rolling off a Log4Shell

As Nick and Brandon mentioned, attackers have been “spraying” Log4J exploits at anything and everything to find vulnerable systems. And it shows. Not only have Log4J-related rule alerts outpaced all other alerts in 2022, no other rule or exploit has come close to hitting as many organizations during either period we examined.

Just how prevalent was Log4J? In 2022, 72 percent of organizations had Log4J Snort rules alert on their firewall. Of course, the volume of attacks can vary. Several organizations saw millions of alerts, while others saw only a handful. Naturally several factors can influence the volume, but the typical organization saw around 110 Log4J alerts each month in 2022. This roughly translates to 3-4 exploit attempts per day.

Blasts from the past

Looking at the list of other exploits seen feels in some ways like reading a greatest hits playlist. Many of these five, six, even nine-year-old vulnerabilities made the list the last time we looked at the data. Vulnerabilities in PHPUnit, JBoss, and a variety of routers, along with the Shellshock vulnerability, all made repeat appearances.

A new entry worthy of mention is a vulnerability in the Java Spring framework, dubbed Spring4Shell. This vulnerability was disclosed in April 2022, but despite the similarity in naming and being a flaw in a widely used library, the conditions required for exploitation are far narrower, limiting its impact in comparison to Log4J. Nevertheless, based on our Snort telemetry, bad actors are indeed trying their hand at exploiting it—almost half of all organizations saw alerts for this vulnerability.

Trying something new

One question that arose after seeing the prominence of Log4J, and the presence of Spring4Shell, was whether newer vulnerabilities were alerting more frequently than the last time we looked at the data.

To answer this question, we looked at rules seen by at least 25 percent of organizations over similar time frames in 2021 and 2022—Q2-Q3 of each year. Then we counted the number of CVEs from that year and the year prior, which we classified as “new.”

So which time frame saw more new CVEs? For the period we looked at in 2021, 21 percent of the CVEs seen were new. However, in 2022 that number rose to 30 percent. This gives the appearance that bad actors are trying out newer exploits more frequently than they had previously.

Some of the new vulnerabilities seen are in applications such as Confluence, Apache HTTP Server, VMware, and Microsoft Exchange. An additional Spring framework vulnerability also makes the list.

MIRTE ATT&CK

Let’s take another look at the MITRE ATT&CK tactics and techniques.

As was the case before, Snort sees alerts on more Initial Access tactics than any other tactic. Log4J played a big part of this, falling under the Exploit Public-Facing Application technique. The Shellshock exploit, and many of the new CVEs mentioned previously, also appear here.

Execution tactics were the second-most encountered type of alert. Spring4Shell features in this tactic, as do exploits in applications such as Drupal, WordPress, and Apache Struts.

Organizations saw an increase in Command-and-Control tactic alerts since the last time we looked at the data. Well-known threats such as Mirai, AveMaria, Remcos, and Chopper were some of the most commonly seen.

Snort categories

Finally, let’s look at a few of the Snort categories that saw the most alerts.

It comes as no surprise that Log4J is top of the list, though the Heartbleed exploit falls into this category as well. A new exploit in Fortinet applications also appears in this category.

Many of the exploits against web applications highlighted last time continue to be used. However, two new exploits affecting Apache HTTP and Microsoft Exchange servers are part of this category.

This category saw an increase in activity compared to the last time we looked at this data. Almost 60 percent of organizations saw alerts for CNC traffic, up from 49 percent last time.

Conclusions

So, what does this analysis tell us about the attacks Snort is detecting?

It’s hard to ignore the impact that Log4J has had. This series of exploits dominated in 2022. And since attackers are still deploying years-old vulnerabilities—as the data has shown—Log4J will continue to stick around for years to come.

Perhaps emboldened by Log4J, it appears that attackers are attempting to use more recent vulnerabilities than they have in the past. True, many older exploit attempts have been seen, but the rise in alerts for newer ones is a potential shift in behavior that will make vulnerability assessment an even more important part of a strong security posture.

Addressing initial access attempts made against publicly facing applications is arguably the most important tactic and technique to address here. True, having a good firewall in place can alert on many of these attacks, but it’s equally important to keep those applications patched and carefully assess what is publicly accessible and what isn’t. If it isn’t necessary to have a service public-facing, don’t take the risk.

Using Snort and Cisco Secure Firewall

Snort is an open-source intrusion prevention system (IPS) that uses rules to detect malicious network activity. These rules are distributed through two sets, the Community Rule Set and the Snort Subscriber Rule Set. The former is developed by the Snort community, while the latter is developed and approved by Talos Intelligence. Both rule sets are QAed by Talos.

Cisco leverages the Snort detection engine and Snort Subscriber Rule Set in Cisco Secure Firewall. The Secure Firewall portfolio delivers greater protections for your network against an increasingly evolving and complex set of threats. With Cisco, you’re investing in a foundation for security that is both agile and integrated, leading to a strong security posture.

Our upcoming Cisco Secure Firewall 4200 appliance and 7.4 OS raises the bar for performance, security, and connectivity. Detect threats faster with a 4x throughput increase and the support of up to 200GE interfaces in a single rack unit. Cisco Secure Firewall 4200 Series delivers faster threat detection with superior visibility, providing the agility to safeguard large enterprises, campuses, and datacenters with a smaller footprint.

Methodology

For the most part we’ve used the same methodology as we did when we first looked at Snort data in October 2021. The product telemetry comes from organizations that have shared Cisco Secure Firewall data on an opt-in basis. This data has been anonymized and aggregated prior to analysis.

This analysis looks at the standard text rules and Shared Object rules in Snort, both provided by Talos. Of these rules, we’re filtering the rules on policies 1-3 described in the Snort FAQ. Since most deployments utilize one of these policies, this gives a clearer picture of what most organizations are facing, while also filtering out most false positives.

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: