Dana Epp's Blog

Security (de)engineering for fun and profit

Mapping Attack Patterns to your Threat Model

I’m a big fan of the threat modeling process, especially when using STRIDE. I think that stems from the fact that back in the late 90’s I found Bruce Schneier’s approach with attack trees just too cumbersome. When I was introduced to an early version of STRIDE inside of Microsoft, I really got on the bandwagon, especially when used against data flow diagrams (DFD).

It’s one of the reasons I pushed Adam Shostak so hard to release an internal tool Microsoft had that used this approach into a tool for the whole appsec community. That became known as the SDL Threat Modeling Tool, and in my mind has always been the best threat modeling tool Microsoft built. TAM was pretty good too, but was more focused on SDL-IT than SDLC.

As an offensive security engineer though, it’s always been interesting to me to think about STRIDE categories in the context of attack patterns. Especially when using CAPEC to abuse an API.

If that concept is foreign to you, I recommend you read my article on Adversarial Thinking for Bug Hunters.

Anyways, a few years ago I stumbled upon some interesting research by Brett Crawley in which he constructed some detailed mind maps that clearly articulate how mapping STRIDE to CAPEC can be done.

This article is meant to highlight his work, and articulate how to map STRIDE categories to common attack patterns. I’ll break it down by threat category, and list out the matching CAPECs, just in case you aren’t a fan of mind maps. 

I will include not only the attack pattern ID, but also the descriptive title so you have an easy way to cross reference the attacks against the threat categories. If anything, just reading the attack pattern titles should provide a unique experience in associated threats to attacks.

Enjoy!

How to use the data in this article

Use this article as a point of exploration on how you can exploit potential threats you see in your threat model. Even if you don’t have an “attacker mindset”, you can map the threat categories directly to attack patterns. MITRE does a great job to make attack pattern titles descriptive, so the attacks should be self evident. When more generic attack patterns can be broken down into more specific attacks, you will find it a “child” of the parent.

If you are a visual learner, click the PNG images. It will expand to a more detailed mind map in an SVG format that is linkable to the MITRE attack database.  

If you are a more textual structured learner, the bulleted list breaks down each attack pattern and its children into extended nodes.

Experiment. Think about how data flows through your system, and where the weaknesses may be. Then go to that threat category, and explore the types of attacks that might be possible. Many won’t be relevant. But some may be. 

When you find an interesting attack pattern you think may apply, click the CAPEC id. That will take you to the attack database, where it will provide a good description of how you could attack the system. It will also describe how realistic it would be to execute, and the skill required. It may even include example code or patterns that you can use in your attack payload sequence.

Use that as a guide to inspire new ways to test the security of your system.

Good luck! 

Spoofing

Tampering

  • CAPEC-123: Buffer Manipulation
    • CAPEC-100: Overflow Buffers
      • CAPEC-10: Buffer Overflow via Environment Variables
      • CAPEC-14: Client-side Injection-induced Buffer Overflow
      • CAPEC-24: Filter Failure through Buffer Overflow
      • CAPEC-256: SOAP Array Overflow
      • CAPEC-42: MIME Conversion
      • CAPEC-44: Overflow Binary Resource File
      • CAPEC-45: Buffer Overflow via Symbolic Links
      • CAPEC-46: Overflow Variables and Tags
      • CAPEC-47: Buffer Overflow via Parameter Expansion
      • CAPEC-67: String Format Overflow in syslog()
      • CAPEC-8: Buffer Overflow in an API Call
      • CAPEC-9: Buffer Overflow in Local Command-Line Utilities
    • CAPEC-540: Overread Buffers
  • CAPEC-124: Shared Resource Manipulation
    • CAPEC-26: Leveraging Race Conditions
    • CAPEC-27: Leveraging Race Conditions via Symbolic Links
    • CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
  • CAPEC-129: Pointer Manipulation
  • CAPEC-153: Input Data Manipulation
    • CAPEC-126: Path Traversal
    • CAPEC-128: Integer Attacks
    • CAPEC-267: Leverage Alternate Encoding
      • CAPEC-120: Double Encoding
      • CAPEC-3: Using Leading ‘Ghost’ Character Sequences to Bypass Input Filters
      • CAPEC-4: Using Alternative IP Address Encodings
      • CAPEC-43: Exploiting Multiple Input Interpretation Layers
      • CAPEC-52: Embedding NULL Bytes
      • CAPEC-53: Postfix, Null Terminate, and Backslash
      • CAPEC-64: Using Slashes and URL Encoding Combined to Bypass Validation Logic
      • CAPEC-71: Using Unicode Encoding to Bypass Validation Logic
      • CAPEC-72: URL Encoding
      • CAPEC-78: Using Escaped Slashes in Alternate Encoding
      • CAPEC-79: Using Slashes in Alternate Encoding
      • CAPEC-80: Using UTF-8 Encoding to Bypass Validation Logic
    • CAPEC-28: Fuzzing
    • CAPEC-33: HTTP Request Smuggling
    • CAPEC-34: HTTP Response Splitting
    • CAPEC-105: HTTP Request Splitting
    • CAPEC-165: File Manipulation
      • CAPEC-73: User-Controlled Filename
      • CAPEC-572: Artificially Inflate File Sizes
        • CAPEC-655: Avoid Security Tool Identification by Adding Data
      • CAPEC-635: Alternative Execution Due to Deceptive Filenames
        • CAPEC-649: Adding a Space to a File Extension
      • CAPEC-636: Hiding Malicious Data or Code within Files
        • CAPEC-168: Windows ::DATA Alternate Data Stream
    • CAPEC-74: Manipulating State
      • CAPEC-140: Bypassing of Intermediate Forms in Multiple-Form Sets
      • CAPEC-663: Exploitation of Transient Instruction Execution
    • CAPEC-75: Manipulating Writeable Configuration Files
    • CAPEC-113: Interface Manipulation
    • CAPEC-176: Configuration/Environment Manipulation
  • CAPEC-161: Infrastructure Manipulation
  • CAPEC-184: Software Integrity Attack
    • CAPEC-185: Malicious Software Download
    • CAPEC-186: Malicious Software Update
      • CAPEC-187: Malicious Automated Software Update via Redirection
      • CAPEC-533: Mobile Device Patterns
      • CAPEC-614: Rooting SIM Cards
      • CAPEC-657: Malicious Automated Software Update via Spoofing
    • CAPEC-663: Exploitation of Transient Instruction Execution
    • CAPEC-669: Alteration of a Software Update
  • CAPEC-272: Protocol Manipulation
  • CAPEC-438: Modification During Manufacture
    • CAPEC-444: Development Alteration
      • CAPEC-206: Signing Malicious Code
      • CAPEC-443: Malicious Logic Inserted Into Product by Authorized Developer
      • CAPEC-445: Malicious Logic Insertion into Product Software via Configuration Management Manipulation
      • CAPEC-446: Malicious Logic Insertion into Product via Inclusion of Third-Party Component
      • CAPEC-511: Infiltration of Software Development Environment
      • CAPEC-516: Hardware Component Substitution During Baselining
      • CAPEC-520: Counterfeit Hardware Component Inserted During Product Assembly
      • CAPEC-532: Altered Installed BIOS
      • CAPEC-537: Infiltration of Hardware Development Environment
      • CAPEC-538: Open-Source Library Manipulation
      • CAPEC-539: ASIC With Malicious Functionality
      • CAPEC-670: Software Development Tools Maliciously Altered
      • CAPEC-672: Malicious Code Implanted During Chip Programming
      • CAPEC-673: Developer Signing Maliciously Altered Software
      • CAPEC-678: System Build Data Maliciously Altered
    • CAPEC-447: Design Alteration
      • CAPEC-517: Documentation Alteration to Circumvent Dial-down
      • CAPEC-518: Documentation Alteration to Produce Under-performing Systems
      • CAPEC-519: Documentation Alteration to Cause Errors in System Design
      • CAPEC-521: Hardware Design Specifications Are Altered
      • CAPEC-671: Requirements for ASIC Functionality Maliciously Altered
      • CAPEC-674: Design for FPGA Maliciously Altered
  • CAPEC-440: Hardware Integrity Attack
  • CAPEC-439: Manipulation During Distribution
  • CAPEC-441: Malicious Logic Insertion
  • CAPEC-548: Contaminate Resource
  • CAPEC-594: Traffic Injection
  • CAPEC-624: Hardware Fault Injection

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

Conclusion

By aligning STRIDE categories with CAPEC attack patterns, you can identify and mitigate potential threats more precisely. This method leverages the strengths of both frameworks, offering a structured approach to threat identification and response.

Brett Crawley’s mind maps provide a visual representation of these mappings, making it easier for you to comprehend and implement. However, for those who prefer a textual approach, the detailed breakdown of threat categories and their corresponding CAPEC attack patterns in this article serves as a valuable reference.

By utilizing this article, you can explore how different attack patterns may exploit the threats identified in your threat model. This dual approach—visual and textual—caters to different learning styles and ensures comprehensive coverage. It encourages experimentation and thorough analysis of data flows within your systems to identify and address weaknesses.

Remember, the key to effective threat modeling and security testing is continuous learning and adaptation. By staying informed about new attack patterns and regularly updating your threat model, you can better protect your systems from evolving threats.

Good luck and stay vigilant!

One last thing…

API Hacker Inner Circle

Have you joined The API Hacker Inner Circle yet? It’s my FREE weekly newsletter where I share articles like this, along with pro tips, industry insights, and community news that I don’t tend to share publicly. If you haven’t, subscribe today at https://apihacker.blog.

Dana Epp

Dana Epp
Hey, I’m Dana, aka SilverStr. I build and break software for a living, and am a Microsoft Regional Director and Developer Security MVP. I’ve spent decades as a security architect that focuses on helping secure software, data, and infrastructure on both blue and red teams. As of late, I have been focusing more on my offensive tradecraft to help developers and IT administrators see the impact of exploitation on vulnerabilities in their work. This blog is my chance to give back to the community by sharing my experiences and war wounds from the trenches.
←
→

Discover more from Dana Epp's Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading