AN1149: Analytic 1149
Detect adversaries filtering traffic or modifying server responses to evade scanning. Monitor iptables, nftables, or proxy configurations that deny or redirect requests from known scanning agents or defensive tools.
Analyst context for executives and security teams
This analytic is about spotting Linux servers or intermediaries that are configured to treat security scanners differently from normal users. For leaders, the significance is assurance: if a system can deny, redirect, or alter responses to known defensive tools, vulnerability management and monitoring results may look cleaner than reality. That can weaken patch prioritization, audit evidence, and incident scoping decisions.
Executive priority
Prioritize this as a control-validation issue for Linux-facing services and proxy paths where vulnerability scanning, compliance testing, or defensive tooling is relied on for risk decisions. Security leaders should ask whether scanner results are independently trusted, whether firewall/proxy exceptions are reviewed, and whether changes to iptables, nftables, or proxy rules are visible to the SOC and change-management process.
Technical view
The supplied ATT&CK analytic applies to Linux and describes monitoring for iptables, nftables, or proxy configuration changes that deny or redirect requests from known scanning agents or defensive tools. SOC and detection engineering teams should validate whether they collect configuration state and change events for host firewalls and proxies, and whether detections can distinguish approved scanner access-control rules from suspicious filtering or response modification. No ATT&CK tactic or relationship context was supplied, so local asset role, exposure, and change history are required to prioritize alerts.
Likely telemetry
- Linux host firewall configuration and change records for iptables
- Linux nftables ruleset state and change records
- Proxy configuration files, policy changes, and access-control rules
- System logs or audit records showing firewall or proxy configuration modification
- Change-management records for approved scanner allow/deny/redirect behavior
Detection direction
- Baseline authorized iptables, nftables, and proxy rules affecting defensive scanners or security tools.
- Alert on new or modified deny, redirect, or filtering rules that reference known scanning agents, scanner networks, or defensive tooling identifiers.
- Correlate firewall/proxy changes with scanner failures, sudden drops in findings, or inconsistent server responses.
- Tune for legitimate hardening controls, maintenance windows, and approved scan-routing policies to reduce false positives.
- Review blind spots where proxy devices or host firewall changes are not centrally logged or where scanner identity is not consistently known.
Mitigation priorities
- Establish ownership and approval requirements for Linux host firewall and proxy rules that affect security scanning.
- Maintain an inventory of authorized scanner sources and expected access paths.
- Centralize logging for iptables, nftables, and proxy configuration changes where feasible.
- Periodically compare live firewall/proxy state against approved baselines.
- Use vulnerability management and compliance reviews to challenge unexpected scanner denials, redirects, or unusually clean results.
Analyst notes and limits
This is a detection analytic, not a technique description. The official description focuses on adversaries filtering traffic or modifying server responses to evade scanning, specifically through Linux iptables, nftables, or proxy configurations. Because no relationships or tactics were supplied, the strongest use is as a validation prompt for SOC, vulnerability management, and compliance evidence pipelines.
Official detection content was not provided, tactics were not specified, and no relationship context was supplied. This take does not assert active exploitation, attribution, impact, or existing detection coverage. Environment-specific scanner architecture, Linux logging, proxy placement, and approved change processes are needed to operationalize it.
Analytic 1149
Detect adversaries filtering traffic or modifying server responses to evade scanning. Monitor iptables, nftables, or proxy configurations that deny or redirect requests from known scanning agents or defensive tools.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | a1ecc4d05354… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1149Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.