Why match `-33800` instead of the full `%ASA-4-338001` prefix?

Two reasons. The digit after `%ASA-` is the message's severity, and administrators can change it per message with `logging message level `: Cisco documents the Botnet Traffic Filter messages at severity 4, while the sample shipped with LogTriage logs one at severity 2. And the filter writes several IDs in the 33800x range depending on whether the bad address was the source or the destination and whether the connection was only monitored or dropped. Matching the range without the severity digit catches all of them on real devices.

Why only threat levels high and very-high?

Every blacklist entry carries a threat level, and the lower levels produce far more hits for far less risk. High and very-high are where known botnet and malware infrastructure sits, so they are the ones worth an alert. Once you know your baseline, you can add `threat-level: moderate` to the list.

The same sample also has an AMP block and a port scan. Why does this rule ignore them?

Because neither would hold up on a real firewall. On Firepower Threat Defense (FTD) devices, message 430003 is the end-of-connection event that the access control policy logs for ordinary connections; file malware events have their own message, 430005. A rule keyed on 430003 would alert on normal traffic. And a single denied inbound SYN (106001) is constant background noise on an internet-facing firewall: scan detection needs a count per source address over a time window, with a much higher threshold than the sample's three denies. That belongs in a separate, aggregated rule.

What should I do when this fires?

Check which side was blacklisted. If the bad address is the destination, an internal host started the connection to known botnet infrastructure. Treat that host as likely infected, and pull its process and DNS activity for the same minutes. If the bad address is the source, it is inbound traffic from botnet infrastructure, usually scanning or exploitation attempts. Check whether the ASA dropped the connection or only monitored it, and whether the targeted service logged a matching request.

Detect Botnet Traffic Filter Blacklist Hits in Cisco ASA Logs

Published October 19, 2026

MITRE ATT&CK: T1071

Sigma Rule

title: Cisco ASA Botnet Traffic Filter Blacklist Hit (High Threat Level)
id: f7504077-63ed-401a-a120-f5aec2ed5d0b
status: experimental
description: >
  Detects the Cisco ASA Botnet Traffic Filter (Dynamic Filter) matching a
  connection against its blacklist at threat level high or very-high. The
  33800x message IDs are the filter's blacklist matches. The ID is matched
  without its severity digit, because administrators can change the logging
  level of any ASA message.
references:
  - https://attack.mitre.org/techniques/T1071/
author: LogTriage
date: 2026/10/19
logsource:
  product: cisco
  service: asa
detection:
  blacklist_hit:
    message|contains: '-33800'
  high_threat:
    message|contains:
      - 'threat-level: high'
      - 'threat-level: very-high'
  condition: blacklist_hit and high_threat
falsepositives:
  - Shared hosting or CDN addresses listed because of another tenant
  - Stale blacklist entries for cleaned-up infrastructure
  - Sandboxes or enrichment hosts that contact known-bad domains on purpose
level: high
tags:
  - attack.command_and_control
  - attack.t1071

What this rule detects

The Cisco ASA Botnet Traffic Filter, also called the Dynamic Filter, checks connections against a database of known-bad domains and addresses that Cisco updates, plus any local lists you configure. When a connection matches the blacklist, the ASA writes a syslog message in the 33800x range with the matched address, a threat-level and a category.

This rule fires on any such blacklist match at threat level high or very-high. One event is enough: the classification comes from the firewall’s own threat intelligence, not from an inference the rule makes.

Detection logic

Two selections, both required:

blacklist_hit: the message contains -33800, which covers every Botnet Traffic Filter blacklist message ID whatever severity the device logs it at.
high_threat: the message carries threat-level: high or threat-level: very-high.

The condition is blacklist_hit and high_threat. The rule keys on the message ID and the threat-level field, not on the message wording, which varies between ASA versions and between monitored and dropped connections.

Validated against a real sample

Validated against cisco_asa_attack.log (shipped with LogTriage). The rule fires on one of its eight lines: %ASA-2-338001, traffic from 45.142.212.100 to 10.0.0.100 on port 80, marked threat-level: very-high, category: Botnet.

The same file also contains three denied SYNs from 185.220.101.42 (106001), an access-list deny (106023), a denied ping (106014), an IP spoof deny (106016) and a line labelled as an AMP block (430003). The rule deliberately ignores them. The FAQ explains why the AMP line and the scan would mislead on a real device.

It stays silent on cisco_asa_normal.log, which holds only connection builds and teardowns (302013, 302014, 302015), a VPN session (713228) and a local-host build (609001), with no 33800x message and no threat-level field anywhere.

False positives

Blacklists are shared infrastructure. A shared hosting or CDN address can be listed because of another tenant, and an entry can outlive the compromise that put it there. Before you escalate, check the category, look up the address in a second source, and look for repeat hits from the same internal host. Exclude sandboxes and enrichment servers that contact known-bad domains on purpose.

Frequently Asked Questions

Why match `-33800` instead of the full `%ASA-4-338001` prefix?: Two reasons. The digit after `%ASA-` is the message's severity, and administrators can change it per message with `logging message <id> level <level>`: Cisco documents the Botnet Traffic Filter messages at severity 4, while the sample shipped with LogTriage logs one at severity 2. And the filter writes several IDs in the 33800x range depending on whether the bad address was the source or the destination and whether the connection was only monitored or dropped. Matching the range without the severity digit catches all of them on real devices.
Why only threat levels high and very-high?: Every blacklist entry carries a threat level, and the lower levels produce far more hits for far less risk. High and very-high are where known botnet and malware infrastructure sits, so they are the ones worth an alert. Once you know your baseline, you can add `threat-level: moderate` to the list.
The same sample also has an AMP block and a port scan. Why does this rule ignore them?: Because neither would hold up on a real firewall. On Firepower Threat Defense (FTD) devices, message 430003 is the end-of-connection event that the access control policy logs for ordinary connections; file malware events have their own message, 430005. A rule keyed on 430003 would alert on normal traffic. And a single denied inbound SYN (106001) is constant background noise on an internet-facing firewall: scan detection needs a count per source address over a time window, with a much higher threshold than the sample's three denies. That belongs in a separate, aggregated rule.
What should I do when this fires?: Check which side was blacklisted. If the bad address is the destination, an internal host started the connection to known botnet infrastructure. Treat that host as likely infected, and pull its process and DNS activity for the same minutes. If the bad address is the source, it is inbound traffic from botnet infrastructure, usually scanning or exploitation attempts. Check whether the ASA dropped the connection or only monitored it, and whether the targeted service logged a matching request.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs