Cisco Secure Firewall - High Volume of Intrusion Events Per Host

SPLUNK detection rule by Nasreddine Bencherchali, Splunk · Apache-2.0

The following analytic detects internal systems that generate an unusually high volume of intrusion detections within a 30-minute window. It leverages Cisco Secure Firewall Threat Defense logs, specifically focusing on the IntrusionEvent event type, to identify hosts that trigger more than 15 Snort-based signatures during that time. A sudden spike in intrusion alerts originating from a single host may indicate suspicious or malicious activity such as malware execution, command-and-control communication, vulnerability scanning, or lateral movement. In some cases, this behavior may also be caused by misconfigured or outdated software repeatedly tripping detection rules. Systems exhibiting this pattern should be triaged promptly, as repeated Snort rule matches from a single source are often early indicators of compromise, persistence, or active exploitation attempts.

name: Cisco Secure Firewall - High Volume of Intrusion Events Per Host
id: 9f2295a0-0dcb-4a5f-b013-8a6f2a3c11f6
version: 8
creation_date: '2025-04-16'
modification_date: '2026-05-13'
author: Nasreddine Bencherchali, Splunk
status: production
type: Anomaly
description: |
    The following analytic detects internal systems that generate an unusually high volume of intrusion detections within a 30-minute window. It leverages Cisco Secure Firewall Threat Defense logs, specifically focusing on the IntrusionEvent event type, to identify hosts that trigger more than 15 Snort-based signatures during that time. A sudden spike in intrusion alerts originating from a single host may indicate suspicious or malicious activity such as malware execution, command-and-control communication, vulnerability scanning, or lateral movement. In some cases, this behavior may also be caused by misconfigured or outdated software repeatedly tripping detection rules. Systems exhibiting this pattern should be triaged promptly, as repeated Snort rule matches from a single source are often early indicators of compromise, persistence, or active exploitation attempts.
data_source:
    - Cisco Secure Firewall Threat Defense Intrusion Event
search: |
    `cisco_secure_firewall` EventType=IntrusionEvent
    | bin _time span=30m
    | stats count as TotalEvents values(signature_id) as signature_id
            values(signature) as signature
            values(dest) as dest
            values(dest_port) as dest_port
            min(_time) as firstTime max(_time) as lastTime
            by src class_desc MitreAttackGroups InlineResult InlineResultReason rule transport app
    | where TotalEvents >= 15
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `cisco_secure_firewall___high_volume_of_intrusion_events_per_host_filter`
how_to_implement: |
    This search requires Cisco Secure Firewall Threat Defense Logs, which
    includes the IntrusionEvent EventType. This search uses an input macro named `cisco_secure_firewall`.
    We strongly recommend that you specify your environment-specific configurations
    (index, source, sourcetype, etc.) for Cisco Secure Firewall Threat Defense logs. Replace the macro definition
    with configurations for your Splunk environment. The search also uses a post-filter
    macro designed to filter out known false positives.
    The logs are to be ingested using the Splunk Add-on for Cisco Security Cloud (https://splunkbase.splunk.com/app/7404).
    The intrusion access policy must also be configured.
known_false_positives: |
    False positives can occur in environments where vulnerability scanners or malware sandboxes are actively generating simulated attacks. Additionally, noisy or overly aggressive Snort rules may produce bursts of alerts from legitimate applications. Review host context before escalating.
references:
    - https://www.cisco.com/c/en/us/td/docs/security/firepower/741/api/FQE/secure_firewall_estreamer_fqe_guide_740.pdf
drilldown_searches:
    - name: View the detection results for - "$src$"
      search: '%original_detection_search% | search  src = "$src$"'
      earliest_offset: $info_min_time$
      latest_offset: $info_max_time$
    - name: View risk events for the last 7 days for - "$src$"
      search: '| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$src$") | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
      earliest_offset: 7d
      latest_offset: "0"
intermediate_findings:
    entities:
        - field: src
          type: system
          score: 20
          message: A high number [$TotalEvents$] of Snort intrusion detections for [$signature$] were triggered by [$src$] in a 30-minute time window.
threat_objects:
    - field: signature
      type: signature
analytic_story:
    - Cisco Secure Firewall Threat Defense Analytics
asset_type: Network
mitre_attack_id:
    - T1059 # Command and Scripting Interpreter
    - T1071 # Application Layer Protocol
    - T1595.002 # Active Scanning: Vulnerability Scanning
product:
    - Splunk Enterprise
    - Splunk Cloud
    - Splunk Enterprise Security
category: network
security_domain: network
tests:
    - name: True Positive Test
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/cisco_secure_firewall_threat_defense/intrusion_event/intrusion_events.log
          source: not_applicable
          sourcetype: cisco:sfw:estreamer
      test_type: unit

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

01345d77-dd33-4e08-8fcf-a0522bb69ab3

Propose edits, view related rules, and engage with the community through comments.

Executable code, not a declarative rule

This submission is arbitrary [[ currentRule.format ? currentRule.format.toUpperCase() : '' ]] code, not a declarative detection rule — review it as you would any script before running it, and note that it cannot be safely aggregated or auto-executed alongside YARA/Sigma/Suricata/CRS rules.

Rejected pattern present

[[ reason ]]

What does this mean?

Format & documentation suggestions

Not a security issue — this rule is valid and was accepted as-is. These are optional fields/conventions its own format recommends, mainly affecting its quality score and how well it documents itself for other reviewers.

[[ reason ]]

What do these messages mean?

[[ currentRule.title && currentRule.title.length > 60 ? currentRule.title.slice(0, 60) + '…' : currentRule.title ]]

[[ currentRule.title ]]

Community Discussion