March 27, 2017 By Scott Craig 6 min read

When reading summaries of prevalent cyberattacks, I often find myself puzzled. Sometimes it’s because the name of an attack is too ambiguous to know what it is referring to, forcing the reader to make assumptions about the meaning.

Many security analysts report attack types using the consequence of the incident, the attack pattern, the name of the device being targeted or a name that was derived at the time and may be used again in the future. Given this inconsistency, a standardization for describing attack type patterns might help analysts report cybersecurity threats more accurately and consistently.

Cataloging Threats With CAPEC

Thankfully, an existing standard that has recently been revised sets forth a common set of names for cyberattack patterns. The Common Attack Pattern Enumeration and Classification (CAPEC) is maintained by the MITRE Corporation, a not-for-profit organization that operates research and development centers sponsored by the federal government.

CAPEC is a comprehensive dictionary and classification taxonomy of known attacks that can be used by analysts, developers, testers and educators to advance community understanding and enhance defenses. The objective of the CAPEC effort is to create a publicly available catalog of common attack patterns classified in an intuitive manner, along with a comprehensive schema for describing related attacks and sharing information about them.

For the 2017 IBM X-Force Threat Intelligence Index, the X-Force team grouped methods of attack observed in 2016 according to the CAPEC standard.

Familiar Standards

IBM X-Force Threat Research adopted the CAPEC standard for attack categorization because it was developed using methodologies similar to those used in other well-established naming conventions for security terms, such as Common Vulnerabilities and Exposure (CVE). Many IT security professionals are already aware of the CVE dictionary of common names for publicly known cybersecurity vulnerabilities.

Prior to CVE, the security tools that existed used their own names for vulnerabilities and it was relatively difficult to determine whether varying tools were referring to the same problem. The CVE database, also maintained by MITRE, was launched in 1999 to bring a consistent approach to naming security vulnerabilities and exposures. This effort was successful — CVE is now the industry standard for vulnerability and exposure names.

As of March 20, 2017, the IBM X-Force Vulnerability Database reported 110,503 vulnerabilities, 83,087 of which were associated with a CVE. When using a vulnerability scanning service or tool where a vulnerability is identified, it helps the user to know the associated CVE identifier. The CVE ID documentation provides a short description about the vulnerability and a list of references that offer more details on how to mitigate the specified vulnerability.

Another popular naming standard in the developer and security practitioner communities is the Common Weakness Enumeration (CWE) project, a community-developed list of common software security weaknesses. It serves as a common language, a measuring stick for software security tools, and a baseline standard for weakness identification, mitigation and prevention efforts. As of CWE version 2.10, there are a total of 1,005 CWEs.

CAPEC Hierarchy

CAPEC uses graph views, which are basically hierarchical representations of attack patterns. The top of the hierarchy is a set of categories (see Figure 1), under which there are meta-level patterns. These meta-level patterns are parents to standard patterns, which may then be parents to detailed patterns.

CAPEC version 2.9 currently provides two views on the CAPEC site: Mechanisms of Attack and Domains of Attack. In the Mechanisms of Attack view, nine categories are shown at the top level, with a total of 503 attack patterns within the entire hierarchy.

Figure 1: Mechanisms of Attack Categories (Source: CAPEC)

Shown in Figure 2 is a partial listing of a few expanded branches of the Mechanism of Attack view hierarchy. Note how the hierarchy follows this format: View -> Category -> Meta -> Standard -> Detailed.

Figure 2: CAPEC hierarchy example (Source: CAPEC)

The following shows how one would indicate the hierarchy of the detailed attack pattern “Blind SQL Injection,” for instance:

(V) Mechanisms of Attack -> (C) Inject Unexpected Items -> (M) Command Injection -> (S) SQL Injection -> (D) Blind SQL Injection

Using CAPEC instead of other naming conventions should help analysts better recognize which attack patterns they most often see and then prioritize improvements to their security. Just knowing there have been a lot of distributed denial-of-service (DDoS) attacks, for example, doesn’t indicate how to best defend against them because this type of incident can occur as a consequence of different attack patterns.

Here’s an example of two vulnerabilities that, when exploited, can each result in a denial-of-service (DoS), although they have different attack patterns:

  • CVE-2003-0760, a vulnerability in Blubster 2.5 that enables attackers to remotely launch a DDoS-induced crash by flooding connections to User Datagram Protocol (UDP) port 701; and
  • CVE-2016-9429, an issue affecting the Tatsuya Kinoshita w3m fork that enables remote attackers to trigger a crash and possibly execute arbitrary code through a crafted HTML page.

The CAPEC attack pattern for CVE-2003-0760 is a UDP Flood:

(C) Abuse Existing Functionality – (210) -> (M) Flooding – (125) -> (S) UDP Flood – (486)

Meanwhile, the CAPEC attack pattern for CVE-2016-9429 is Overflow Buffers:

(C) Manipulate Data Structures – (255) -> (M) Buffer Manipulation – (123) -> (S) Overflow Buffers – (100)

Consequences, Device Types and Attack Vectors

Below are some examples of names analysts commonly use when reporting attack types that are not attack patterns:

  • Denial-of-service —consequence;
  • Point-of-sale (POS) — targeted device type;
  • Internet of Things (IoT) — targeted device type;
  • Backdoor — Consequence or indicator, depending on how it’s detected;
  • Malicious documents (attachments) and links — attack vector;
  • Shellshock — specific malware or campaign;
  • Web — assuming anything using HTTP for an attack;
  • Remote code execution — consequence; and
  • Wi-Fi — attack vector.

Many in the security community, including the IBM X-Force team, have lumped some of these examples together in the past under the category of “attack type or pattern.” However, as shown above, these examples are not representative of an attack pattern. Some are consequences, such as DoS, while others describe the type of device that’s being targeted, such as an IoT device.

We analyze CAPEC mechanisms of attack and attack patterns using data from monitored security client environments. The following is a breakout of the meta attack pattern (M) and standard attack pattern (S) levels below the “Inject Unexpected Items” category, according to the X-Force analysis of 2016 data. More information regarding this attack pattern will be available in the 2017 IBM X-Force Threat Intelligence Index.

Figure 3: CAPEC Attack Patterns seen under Inject Unexpected Items category (Source: X-Force-monitored security client environments)

Looking It Up

When looking up IDs on the CAPEC website, you will notice there’s a presentation filter option on the left side. It defaults to “Basic” and has an option labeled “Complete.” What is shown from either view is based on the data available and applies to the given entry. The headings noted below are from CAPEC-17.

Basic will show you: Summary, Attack Prerequisites, Solutions and Mitigations, and Related Attack Patterns.

Complete will show you everything that Basic has, plus: Typical Severity, Typical Likelihood of Exploit, Methods of Attack, Examples-Instances, Attack Skills or Knowledge Required, Resources Required, Solutions and Mitigations, Attack Motivation-Consequences, Injection Vector, Payload, Activation Zone, Payload Activation Impact, Related Weaknesses, Related Attack Patterns, Purposes, CIA Impact, Technical Context, References and Content History.

A Call for Continued Adoption

CAPEC was initially released in 2007 and continues to evolve over the years. The Telecommunication Standardization sector (ITU-T), a division of the International Telecommunication Union (ITU) responsible for coordinating standards for the telecommunications industry, approved recommendation X.1544 for the use of CAPEC as a standard in April 2013. CAPEC is also used in ISO/IEC TR 20004:2015.

CAPEC version 2.9 was released in January 2017. The focus of version 2.9 was to restructure the Mechanisms of Attack view based on the feedback received by MITRE Corporation. I expect to see more and more cybersecurity professionals adopting CAPEC for classifying and communicating about attacks in the near future.

Read the complete 2017 IBM X-Force Threat Intelligence Index

More from Advanced Threats

Hive0051 goes all in with a triple threat

13 min read - As of April 2024, IBM X-Force is tracking new waves of Russian state-sponsored Hive0051 (aka UAC-0010, Gamaredon) activity featuring new iterations of Gamma malware first observed in November 2023. These discoveries follow late October 2023 findings, detailing Hive0051's use of a novel multi-channel method of rapidly rotating C2 infrastructure (DNS Fluxing) to deliver new Gamma malware variants, facilitating more than a thousand infections in a single day. An examination of a sample of the lures associated with the ongoing activity reveals…

GootBot – Gootloader’s new approach to post-exploitation

8 min read - IBM X-Force discovered a new variant of Gootloader — the "GootBot" implant — which facilitates stealthy lateral movement and makes detection and blocking of Gootloader campaigns more difficult within enterprise environments. X-Force observed these campaigns leveraging SEO poisoning, wagering on unsuspecting victims' search activity, which we analyze further in the blog. The Gootloader group’s introduction of their own custom bot into the late stages of their attack chain is an attempt to avoid detections when using off-the-shelf tools for C2…

Black Hat 2022 Sneak Peek: How to Build a Threat Hunting Program

4 min read - You may recall my previous blog post about how our X-Force veteran threat hunter Neil Wyler (a.k.a “Grifter”) discovered nation-state attackers exfiltrating unencrypted, personally identifiable information (PII) from a company’s network, unbeknownst to the security team. The post highlighted why threat hunting should be a baseline activity in any environment. Before you can embark on a threat hunting exercise, however, it’s important to understand how to build, implement and mature a repeatable, internal threat hunting program. What are the components…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today