Nuclei Templates

repository·main·Indexed 11 days ago

https://github.com/projectdiscovery/nuclei-templates

A community-driven repository of scanning definitions for the Nuclei engine. It provides templates for automating the detection of vulnerabilities, misconfigurations, and exposed assets, including specialized sets for OSINT, credential stuffing, token-spraying, and phishing detection.

Tokens
10.9K
Snippets
37
Records
54
Agent score
93%

What's inside Nuclei Templates

  1. Use OSINT templates for user enumeration and phishing detection

    main

    The OSINT templates in this directory are designed for two primary security tasks:

    1. User Enumeration: These templates verify the existence of users across various websites. To use them effectively, you must provide input such as a username, email, or phone number using the -V or -var flag.
    2. Phishing Detection: These templates identify and analyze phishing sites, assisting OSINT analysts and threat researchers in uncovering phishing campaigns.
  2. Configure Nuclei attack types for credential stuffing

    main

    Nuclei supports different modes for processing credential lists:

    • Pitchfork mode (Default): Nuclei takes the first line from the username file and the first line from the password file, pairing them together. For this to work correctly, both files must have an equal number of entries with the correct email/password combinations aligned on the same line.
    • Clusterbomb mode: Enabled via the -at or -attack-type clusterbomb option. This mode tests every entry in the password list against every entry in the username list, which is useful for verifying weak credentials across a list of email addresses.
  3. Template Structure Overview

    main

    A standard Nuclei template consists of an id for identification, an info block for metadata (name, author, severity, description, references, classification, tags), and a protocol-specific block (like http or network) containing requests and matchers.

    Key metadata fields include:

    • severity: critical|high|medium|low|info
    • classification: Can include cve-id, cwe-id, or cvss-metrics.
    • tags: Comma-separated strings for categorization.
    id: template-identifier
    info:
      name: Human Readable Vulnerability Name
      author: your-github-username,vulnerability-discoverer-handle
      severity: critical|high|medium|low|info
      description: Clear explanation of what this template detects
      reference:
        - https://link-to-vulnerability-details
      classification:
        cve-id: CVE-2024-1234
        cwe-id: CWE-89
      tags: cve,sqli,rce
      metadata:
        verified: true
        shodan-query: 'http.title:\"VulnApp\"'
    
    http:
      - method: GET
        path:
          - "{{BaseURL}}/vulnerable-endpoint"
        
        matchers:
          - type: word
            words:
              - "vulnerability_indicator"
            part: body
  4. Implement strong vulnerability-specific matchers

    main

    Avoid weak matchers that rely on generic terms (like admin or login) or version-only detection, as these cause high false positive rates. Instead, use a Multi-Layer Verification Strategy by setting matchers-condition: and and combining multiple layers:

    1. Layer 1 (Identification): Identify the specific application (e.g., exact page title or unique body text).
    2. Layer 2 (Version): Confirm the vulnerable version range using regex.
    3. Layer 3 (Exploitation): Verify actual vulnerability presence using a unique payload response or command output indicator.

    Use condition: or within a layer if multiple proof methods are available.

    # Multi-layer verification example
    matchers-condition: and
    matchers:
      - type: word                    # Layer 1: Identify application
        words:
          - "Grafana Dashboard"
          - "grafana.com/login"
        part: body
        
      - type: regex                   # Layer 2: Confirm version
        regex:
          - 'version.*[6-8]\.[0-5]\.[0-9]'
        part: body
        
      - type: word                    # Layer 3: Verify exploit success
        words:
          - "unauthorized_data_access"
          - "/api/snapshots/{{randstr}}"
        part: body
        condition: or
  5. Implement a Multi-Layer Matcher Strategy

    main

    For high-fidelity templates, use a multi-layered approach by setting matchers-condition: and and defining multiple matcher layers. This strategy typically involves:

    1. Layer 1: Identify the specific application or service.
    2. Layer 2: Confirm the vulnerable version via regex.
    3. Layer 3: Verify the actual vulnerability exists (e.g., checking for exposed debug info or configuration leaks).
    # Use multiple verification layers
    matchers-condition: and
    matchers:
      - type: word           # Layer 1: Identify the application
        words:
          - "VulnApp Management Console"
        part: body
        
      - type: regex          # Layer 2: Confirm vulnerable version
        regex:
          - 'Version: [1-2]\.[0-5]\.[0-9]'
        part: body
        
      - type: word           # Layer 3: Verify vulnerability exists
        words:
          - "debug_info_exposed"
          - "configuration_leak"
        part: body
        condition: or
  6. How token-spray templates work

    main

    The token-spray templates are designed to test an API token against multiple static API service endpoints. Unlike standard Nuclei templates that require target URLs as input, these templates are self-contained because the API endpoints are predefined within the templates themselves.

    This is particularly useful for testing API keys that lack context (i.e., you have a key but do not know which service it belongs to). Nuclei will iterate through the known endpoints for the provided token and report any successful matches.

  7. Write an HTTP Template

    main

    HTTP templates define requests using methods (GET, POST, PUT, DELETE), paths, headers, and bodies.

    Key features:

    • Dynamic Variables: Use {{BaseURL}} or {{Hostname}} to reference the target.
    • Custom Headers/Body: Define headers and body (supports multi-line strings using |).
    • Cookie Handling: Use disable-cookie: false (default) to reuse cookies.
    • Matchers Condition: Use matchers-condition: and to require all matchers to pass, or or for any.
    http:
      - method: GET|POST|PUT|DELETE
        path:
          - "{{BaseURL}}/endpoint"
            # Alternative dynamic variable
          - "{{Hostname}}/another-path"
        
        headers:
          User-Agent: Custom-Agent-String
          Content-Type: application/json
          Origin: https://example.com
        
        body: |
          {"param": "{{payload}}"}
        
        disable-cookie: false
        
        matchers-condition: and
        matchers:
          - type: word
            words:
              - "success_indicator"
            part: body
  8. Implement Strong Matchers

    main

    To avoid false positives, use a multi-layer verification strategy:

    1. Identify the application (e.g., via a specific word in the body).
    2. Confirm the version (e.g., via regex matching a version string).
    3. Prove exploitation (e.g., via a specific technical indicator or proof-of-concept string).

    Use matchers-condition: and to combine these layers.

    matchers-condition: and
    matchers:
      - type: word                    # Layer 1: App identification
        words:
          - "Apache Struts Framework"
          - "struts-tags"
        part: body
        
      - type: regex                   # Layer 2: Version detection
        regex:
          - 'Struts 2\.[0-4]\.[0-9]+'
        part: body
        
      - type: word                    # Layer 3: Exploitation proof
        words:
          - "ognl.OgnlException"
          - "java.lang.SecurityException"
        part: body
        condition: or