Note: This page is part of the archive.

This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact if you have any questions about the US-CERT website archive.

Note: This page is part of the archive.

This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact if you have any questions about the US-CERT website archive.

Introduction to Attack Patterns

Author(s): Amit Sethi Sean Barnum Maturity Levels and Audience Indicators: L3  / L  M  SDLC Life Cycles: Requirements  Testing  Copyright: Copyright © Cigital, Inc. 2005-2007. Cigital retains copyrights to this material.


This article is the first in a coherent series introducing the concept, generation, and usage of attack patterns as a valuable knowledge tool in the design, development, and deployment of secure software. It is recommended that the reader also review the following articles to fully understand the context and value of attack patterns.

Design patterns are a familiar tool used by the software development community to help solve recurring problems encountered during software development


One potential solution to these challenges is using attack patterns to help others understand the attacker's perspective. The black hat community is already well-versed in the techniques used to attack software, but the software development community is not generally educated in the ways in which software is exploited. Attack patterns provide a coherent way of teaching designers and developers how their systems may be attacked and how they can effectively defend them.

A common problem is that software developers try to harden small pieces of software while leaving gaping holes in the big picture. For instance, a developer may use 256-bit AES encryption to secure data but then store the key in the application itself. An attacker will of course choose the easiest way to break software. If an attacker needs the key, he/she will not attempt a brute force attack (computationally infeasible) or cryptanalysis (unlikely to be successful). The attacker will simply obtain the key from the code (very easy).

Likewise, builders of secure physical systems, based on centuries of experience, generally know that attackers always choose the easiest way to achieve their goal. As an analogy, a burglar breaking into a house will not pick the lock(s) on the front door and try to guess the code to the security system if he/she can instead cut the phone line to the house (thus disabling the security system) and break a window to gain access to the inside. Thus, the task of making a house more secure should not involve only better locks and longer security system unlocking codes; they should also involve things like stronger windows and cellular backups for the security system (note that cellular signals also can be jammed, although it is currently not quite as easy as cutting a wire), which can help mitigate known likely attacks. Unless software developers understand similar issues in software security, they cannot effectively build secure software.

Attack patterns help to categorize attacks in a meaningful way, such that problems and solutions can be discussed effectively. Instead of taking an ad hoc approach to software security, attack patterns can identify the types of known attacks to which an application could be exposed so that mitigations can be built into the application.

Another benefit of attack patterns is that they contain sufficient detail about how attacks are carried out to enable developers to help prevent them. Attack patterns, however, do not typically contain inappropriately specific details about the actual exploits to ensure that they do not help educate less skilled members of the black hat community (e.g, script kiddies). Information from attack patterns generally cannot be used directly to create automated exploits.

Of course, attack patterns are not the only useful tool for building secure software. Many other tools, such as misuse/abuse cases, security requirements, threat models, knowledge of common weaknesses and vulnerabilities, coding rules, and attack trees, can help. Attack patterns play a unique role amid this larger architecture of software security knowledge and techniques and will be the focus of these articles.


This section will describe the origin of the concept of attack patterns, provide more detail about the definition of an attack pattern, and discuss some related concepts.


The concept of attack patterns was derived from the notion of design patterns introduced by Christopher Alexander during the 1960s and 1970s and popularized by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides in the book Design Patterns: Elements of Reusable Object-Oriented Software [Gamma 95]. The book discusses vetted solutions to specific problems encountered in object-oriented software design and how to package these solutions for broad leverage in the form of design patterns. A design pattern captures the context and high-level detail of a general repeatable solution to a commonly occurring problem in software design. It is not a low-level design that can be transformed directly into code; it is a description of how to solve a problem that can be used in many situations. Examples of design patterns include the singleton pattern and the iterator pattern. Discussion of these and other specific design patterns is out of scope for these articles but constitutes recommended reading for anyone desiring a full foundational grounding in the context behind attack patterns.

Since the introduction of design patterns, the pattern construct has been applied to many other areas of software development. One of these areas is software security and representation of the attacker's perspective in the form of attack patterns. The term "attack patterns" was coined in discussions among software security thought-leaders starting around 2001, introduced in the paper Attack Modeling for Information Security and Survivability [Moore 01] and was brought to the broader industry in greater detail and with a solid set of specific examples by Greg Hoglund and Gary McGraw in 2004 in their book Exploiting Software: How to Break Code.

Since the publication of Exploiting Software, several individuals and groups throughout the industry have tried to push the concept forward with varying success. These efforts faced challenges like the lack of a common definition and schema for attack patterns, a lack of diversity in the targeted areas of analysis by the various groups involved, and a lack of any independent body to act as the collector and disseminator of common attack pattern catalogues. These articles, as part of the Build Security In effort sponsored by the U.S. Department of Homeland Security, attempts to provide some coherence of definition and structure. Efforts such as the ongoing DHS-sponsored Common Attack Pattern Enumeration and Classification (CAPEC) initiative will collect and make available to the public core sets of attack pattern instances.


An attack pattern is an abstraction mechanism for describing how a type of observed attack is executed. Following the pattern paradigm, it also provides a description of the context where it is applicable and then, unlike typical patterns, it gives recommended methods of mitigating the attack. In short, an attack pattern is a blueprint for an exploit. We propose that an attack pattern should typically include the following information:

  • Pattern Name and Classification: A unique, descriptive identifier for the pattern.
  • Attack Prerequisites: What conditions must exist or what functionality and what characteristics must the target software have, or what behavior must it exhibit, for this attack to succeed?
  • Description: A description of the attack including the chain of actions taken.
  • Related Vulnerabilities or Weaknesses: What specific vulnerabilities or weaknesses (see the glossary for definitions) does this attack leverage? Specific vulnerabilities should reference industry-standard identifiers such as Common Vulnerabilities and Exposures (CVE) number, US-CERT number, etc. Specific weaknesses (underlying issues that may cause vulnerabilities) should reference industry-standard identifiers such as the Common Weakness Enumeration (CWE).
  • Method of Attack: What is the vector of attack used (e.g., malicious data entry, maliciously crafted file, protocol corruption)?
  • Attack Motivation-Consequences: What is the attacker trying to achieve by using this attack? This is not the end business/mission goal of the attack within the target context but rather the specific technical result desired that could be leveraged to achieve the end business/mission objective. This information is useful for aligning attack patterns to threat models and for determining which attack patterns from the broader set available are relevant for a given context.
  • Attacker Skill or Knowledge Required: What level of skill or specific knowledge must the attacker have to execute such an attack? This should be communicated on a rough scale (e.g., low, moderate, high) as well as in contextual detail of what type of skills or knowledge are required.
  • Resources Required: What resources (e.g., CPU cycles, IP addresses, tools, time) are required to execute the attack?
  • Solutions and Mitigations: What actions or approaches are recommended to mitigate this attack, either through resistance or through resiliency?
  • Context Description: In what technical contexts (e.g., platform, OS, language, architectural paradigm) is this pattern relevant? This information is useful for selecting a set of attack patterns that are appropriate for a given context.
  • References: What further sources of information are available to describe this attack?

Two examples of attack patterns are provided below [Hoglund 04]:

  1. Pattern name and classification: Make the Client Invisible
    • Attack Prerequisites: The application must have a multi-tiered architecture with a division between client and server.
    • Description: This attack pattern exploits client-side trust issues that are apparent in the software architecture. The attacker removes the client from the communication loop by communicating directly with the server. This could be done by bypassing the client or by creating a malicious impersonation of the client.
    • Related Vulnerabilities or Weaknesses: CWE–Man-in-the-Middle (MITM), CWE- Origin Validation Error, CWE- Authentication Bypass by Spoofing, CWE- No Authentication for Critical Function, CWE- Reflection Attack in an Authentication Protocol
    • Method of Attack: Direct protocol communication with the server.
    • Attack Motivation-Consequences: Potentially information leak, data modification, arbitrary code execution, etc. These can all be achieved by bypassing authentication and filtering accomplished with this attack pattern.
    • Attacker Skill or Knowledge Required: Finding and initially executing this attack requires a moderate skill level and knowledge of the client-server communications protocol. Once the vulnerability is found, the attack can be easily automated for execution by far less skilled attackers. Skill level for leveraging follow-on attacks can vary widely depending on the nature of the attack.
    • Resources Required: None, although protocol analysis tools and client impersonation tools such as netcat can greatly increase the ease and effectiveness of the attack.
    • Solutions and Mitigations:

      Increase Resistance to Attack: Utilize strong two-way authentication for all communication between client and server. This option could have significant performance implications.

      Increase Resilience to Attack: Minimize the amount of logic and filtering present on the client; place it on the server instead. Use white lists on server to filter and validate client input.

    • Context Description: "Any raw data that exist outside the server software cannot and should not be trusted. Client-side security is an oxymoron. Simply put, all clients will be hacked. Of course the real problem is one of client-side trust. Accepting anything blindly from the client and trusting it through and through is a bad idea, and yet this is often the case in server-side design" [Hoglund 04].
    • References: Exploiting Software: How to Break Code, p.150 [Hoglund 04].
  2. Pattern name and classification: Shell Command Injection—Command Delimiters
    • Attack Prerequisites: The application must pass user input directly into a shell command.
    • Description: Using the semicolon or other off-nominal characters, multiple commands can be strung together. Unsuspecting target programs will execute all the commands. An example may be when authenticating a user using a web form, where the username is passed directly to the shell as in:
      	exec( "cat data_log_" + userInput + ".dat")

      The "+" sign denotes concatenation. The developer expects that the user will only provide a username. However, a malicious user could supply "username.dat; rm –rf / ;" as the input to execute the malicious commands on the machine running the target software. Similar techniques are also used for other attacks such as SQL injection. In the above case, the actual commands passed to the shell will be:

      	cat data_log_username.dat; rm –rf /; .dat

      The first command may or may not succeed; the second command will delete everything on the file system to which the application has access, and success/failure of the last command is irrelevant.

    • Related Vulnerabilities or Weaknesses: CWE-OS Command Injection, CVE-1999-0043, CVE-1999-0067, CVE-1999-0097, CVE-1999-0152, CVE-1999-0210, CVE-1999-0260, 1999-0262, CVE-1999-0279, CVE-1999-0365, etc.
    • Method of Attack: By injecting other shell commands into other data that are passed directly into a shell command.
    • Attack Motivation-Consequences: Execution of arbitrary code. The attacker wants to use the target software, which has more privilege than the attacker, to execute some commands that he/she does not have privileges to execute.
    • Attacker Skill or Knowledge Required: Finding and exploiting this vulnerability does not require much skill. A novice with some knowledge of shell commands and delimiters can perform a very destructive attack. A skilled attacker, however, may be required to subvert simple countermeasures such as rudimentary input filtering.
    • Resources Required: No special or extensive resources are required for this attack.
    • Solutions and Mitigations: Define valid inputs to all fields and ensure that the user input is always valid. Also perform white-list and/or black-list filtering as a backup to filter out known command delimiters.
    • Context Description: OS: UNIX.
    • References: Exploiting Software [Hoglund 04].

Note that an attack pattern is not overly generic or theoretical. The following is not an attack pattern: "writing outside array boundaries in an application can allow an attacker to execute arbitrary code on the computer running the target software." The statement does not identify what type of functionality and specific weakness is targeted or how malicious input is provided to the application. Without that information, the statement is not particularly useful and cannot be considered an attack pattern.

An attack pattern is also not an overly specific attack that only applies to a particular application. For instance, "When the PATH environment variable is set to a string of length greater than 128, the application foo executes the code at the memory location pointed to by characters 132, 133, 134, and 135 in the environment variable." This amount of specificity is dangerous to disclose and provides limited benefit to the software development community. It is dangerous because it enables black hats to more easily attack particular software without requiring much thought. It is of limited benefit to the software development community because it does not help them discover and fix vulnerabilities in other applications or even fix other similar vulnerabilities in the same application.

Though not broadly required or typical, it can be valuable to adorn attack patterns where possible and appropriate with other useful reference information such as:

  • Source Exploits: From which specific exploits (e.g., malware, cracks) was this pattern derived and which shows an example?
  • Related Attack Patterns: What other attack patterns affect or are affected by this pattern?
  • Relevant Design Patterns: What specific design patterns are recommended as providing resistance or resilience to this attack, or which design patterns are not recommended as they are particularly susceptible to this attack?
  • Relevant Security Patterns: What specific security patterns are recommended to provide resistance or resilience to this attack?
  • Related Guidelines or Rules: What existing security guidelines or secure coding rules are relevant to identifying or mitigating this attack?
  • Relevant Security Requirements: Have specific security requirements relevant to this attack been identified which offer opportunities for reuse?
  • Probing Techniques: What techniques are typically used to probe and reconnoiter a potential target to determine vulnerability and/or to prepare for an attack?
  • Indicators-Warnings of Attack: What activities, events, conditions, or behaviors could serve as indicators that an attack of this type is imminent, in progress, or has occurred?
  • Obfuscation Techniques: What techniques are typically used to disguise the fact that an attack of this type is imminent, in progress, or has occurred?
  • Injection Vector: What is the mechanism and format for this input-driven attack? Injection vectors must take into account the grammar of an attack, the syntax accepted by the system, the position of various fields, and the acceptable ranges of data [Hoglund 04].
  • Payload: What is the code, configuration, or other data to be executed or otherwise activated as part of this injection-based attack?
  • Activation Zone: What is the area within the target software that is capable of executing or otherwise activating the payload of this injection-based attack? The activation zone is where the intent of the attacker is put into action. The activation zone may be a command interpreter, some active machine code in a buffer, a client browser, a system API call, etc. [Hoglund 04].
  • Payload Activation Impact: What is the typical impact of the attack payload activation for this injection-based attack on the confidentiality, integrity, or availability of the target software?

Related Concepts

There exist many other concepts and tools related to attack patterns, including fault trees, attack trees, threat trees, and security patterns that are available to the community. It is useful to examine and describe these concepts briefly to reduce confusion between these concepts and attack patterns and so that related literature can be used as a reference when researching or using attack patterns.

Bell Labs developed the concept of fault trees for the Air Force in 1962. It was later applied in a software context in the works of Nancy Leveson [Leveson 83] in the early 1980s. Fault trees provide a formal and methodical way of describing the safety of systems, based on various factors affecting potential system failure. Fault trees are commonly used in safety engineering; the goal of which is to ensure that life-critical systems behave as required when parts of them fail [Vesely 81]. Fault trees have system failure as their root node and potential causes of system failure as other nodes in the tree. Any particular node's "children" represent ways in which the node can "fail." The concept of fault trees is especially helpful for analyzing software for which availability/survivability is a major security concern. Fault trees are a fairly mature concept, and an abundance of literature elaborates on the topic. Fault trees and attack patterns have only a very tenuous relationship. Attack patterns are much more closely aligned with attack trees, a derivative of fault trees, which are described below.

The concept of attack trees was first promulgated by Bruce Schneier, CTO of Counterpane Internet Security. Attack trees are similar to fault trees, except that attack trees are used to analyze the security of systems rather than safety. Attack trees provide a formal and methodical way of describing the security of systems based on varying attacks [Schneier 99]. Microsoft uses the term "threat tree" to describe the same concept [Swiderski 04]. An attack tree has the attacker's goal as the root, and the children of each parent node represent conditions of which one or more must be satisfied to achieve the goal of the parent node. In this manner, all paths to the root from the leaf nodes indicate potential attacks.

An attack pattern consists of a minimal set of nodes in an attack tree that achieves the goal at the root node. In a tree with only "or" branches, this consists of all paths from a leaf node to the root node. Such paths are also known as "attack paths." In a tree with some "and" branches, an attack pattern may be a sub-tree of the attack tree that includes the root node and at least one leaf node.

Attack trees and attack patterns are complementary concepts that balance and enhance each other. While attack trees provide a holistic view of the potential attacks facing a particular piece of software, attack patterns provide actionable detail on specific types of common attacks potentially affecting entire classes of software. Details and examples of attack trees can be found in [Schneier 99].

Lastly, another concept related to attack patterns is security patterns. Security patterns consist of general solutions to recurring security problems. A security pattern encapsulates security expertise in the form of vetted solutions to these recurring problems, presenting issues and tradeoffs in the usage of the pattern [Kienzle 01]. Examples include implementing account lockout to prevent brute force attacks, secure client data storage, and password authentication. Because general software developers may not be familiar with security best practices or with security issues, security patterns attempt to provide practical solutions that can be implemented in a straightforward manner. Security patterns also list various tradeoffs in the solutions. Security patterns can be an effective complement to attack patterns in providing viable solutions to specific attack patterns at the design level. As such, it should be noted that security patterns generally describe relatively high-level repeatable implementation tasks such as user authentication and data storage. They are not typically suitable for low-level implementation details such as NULL termination of strings or even very high-level design issues such as client-side trust issues. Hence, they are excellent for describing solutions to programming problems with a security context but they do not demonstrate how to avoid most common software development pitfalls. A security patterns repository is available at The repository is not meant to be a comprehensive or most up-to-date list of security patterns.

Further Reading

To learn more about the concept of attack patterns and how they can benefit you, it is recommended that you read the remaining articles in this series. They provide a clear picture of the attack pattern generation process (and thereby a much greater contextual understanding of attack pattern content), as well as how attack patterns can improve security enablement of the software development lifecycle. The series also includes a detailed glossary of terms, a comprehensive references listing, and recommendations for further exploration of the attack pattern concept.