Why is there no decision to this appsec alert

[nocturne geode]

Shouldn't there be a decisions / remidiation for this alert?

cscli alert inspect 6844

################################################################################################

 - ID           : 6844
 - Date         : 2025-09-09T09:32:53Z
 - Machine      : Proxy
 - Simulation   : false
 - Remediation  : false
 - Reason       : anomaly score out-of-band: anomaly: 8,
 - Events Count : 5
 - Scope:Value  : Ip:20.118.227.29
 - Country      : US
 - AS           : MICROSOFT-CORP-MSN-AS-BLOCK
 - Begin        : 2025-09-09T09:32:52Z
 - End          : 2025-09-09T09:32:52Z
 - UUID         : 0d83c1db-f4db-4023-a3cc-0a2e1f65d6da

[willow rune]

Important Information

This post has been marked as resolved. If this is a mistake please press the red button below or type /unresolve

© Created By WhyAydan for CrowdSec ❤️ · Sep 9, 2025, 11:11 AM

[nocturne geode]

It triggered two rules within 60 seconds:

 - Context  :
╭───────────────┬──────────────────────────────────────────────────────────────╮
│      Key      │                             Value                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ ja4h          │ ge11nn030000_859c524ed96e_000000000000_000000000000          │
│ logdata       │ Matched Data: zgrab found within                             │
│               │ MATCHED_VARS:REQUEST_HEADERS:User-Agent: Mozilla/5.0         │
│               │ zgrab/0.x                                                    │
│ logdata       │ XXX.XXX.XXX.XXX                                              │
│ matched_zones │ REQUEST_HEADERS.User-Agent                                   │
│ matched_zones │ MATCHED_VARS.REQUEST_HEADERS:User-Agent                      │
│ matched_zones │ REQUEST_HEADERS.Host                                         │
│ method        │ GET                                                          │
│ msg           │ Found User-Agent associated with security scanner            │
│ msg           │ Host header is a numeric IP address                          │
│ name          │ native_rule:913100                                           │
│ name          │ native_rule:920350                                           │
│ target_host   │ XXX.XXX.XXX.XXX                                              │
│ target_uri    │ /                                                            │
│ user_agent    │ Mozilla/5.0 zgrab/0.x                                        │
╰───────────────┴──────────────────────────────────────────────────────────────╯

Version is 1.7.0 - hub is up to date.

[faint lark]

The alert was from AppSec, but you can see Remediation : false from the alert details this was simply just the appsec trigger itself.

Even though the alert has two rules, CoreRuleSet has one rule which is simply just the Alert scoring level so we dont count that when it comes to scenarios anymore.

[nocturne geode]

Yes - I know that - but the scoring level is

│ message       │ Inbound Anomaly Score Exceeded (Total Score: 8) │
│ rule_name     │ native_rule:949110                              │
│ uri           │ /                                               │

and

│ message       │ Anomaly Scores: (Inbound Scores: blocking=8, detection=8,    │
│               │ per_pl=8-0-0-0, threshold=5) - (Outbound Scores: blocking=0, │
│               │ detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=0,  │
│               │ RFI=0, LFI=0, RCE=0, PHPI=0, HTTP=0, SESS=0,                 │
│               │ COMBINED_SCORE=8)                                            │
│ rule_name     │ native_rule:980170                                           │
│ uri           │ /                                                            │

But the request tirggered

│ name          │ native_rule:913100                                           │
│ name          │ native_rule:920350                                           │

I have more examples where more rules than just the scroing levels were triggered but they are all Remediation : false

[faint lark]

Yes that cause our CRS by default is out of band means the request is not blocked but there is a scenario counter to block the IP if they keep trying.

so we released an in band version: https://app.crowdsec.net/hub/author/crowdsecurity/collections/appsec-crs-inband

this will block requests, but again it does not ban the IP unless they trigger multiple rules, over multiple requests you can see the scenario https://app.crowdsec.net/hub/author/crowdsecurity/scenarios/appsec-native

So if you want to simply ban every IP even thought it can be highly false positive prone just copy the scenario, remove capacity and change type to trigger

[nocturne geode]

Just realised appsec_native has capacity: 3

[faint lark]

Yes but those are for inband requests, the CRS out of band has it own scenarios

https://app.crowdsec.net/hub/author/crowdsecurity/scenarios/crowdsec-appsec-outofband

but we provide these defaults, cause we seen CRS can be false positive prone if not properly managed by the user.

[nocturne geode]

In order for OutBand rules to result in a ban they to trigger crowdsecurity/crowdsec-appsec-outofbandright?

 - ID           : 6829
 - Date         : 2025-09-09T08:13:38Z
 - Machine      : SRVProxy
 - Simulation   : false
 - Remediation  : false
 - Reason       : anomaly score out-of-band: xss: 30, anomaly: 30,
 - Events Count : 5

Did not trigger crowdsecurity/crowdsec-appsec-outofband
But I just saw that 2 "Events" were the scoring rules.
Maybe not count them as event when the're not counted towards offending rules 🙂

[faint lark]

it does, but you are counting events thinking it means capacity the capacity means it must be 5 different requests.

you can see buckets via cscli metrics if you dont see that scenario in the list then yes something off

[forest ether]

For waf matches with the CRS, the event count in the alert generated by the WAF is not actually the number of requests
It's the number of CRS rules that matched the request: CRS will always match more than one rule, it's there to allow you to understand what what exactly happening inside the CRS (think of it as a very light version of the modsecurity audit log)

[nocturne geode]

Got it. Thanks!

[forest ether]

It's a change in 1.7.0, before we were not even populating the events
We probably need to document that to make it clearer (I thought it was obvious, but thinking about it, it's probably not)

[nocturne geode]

While you're at it - please document that the message changed from "Appsec block" to "WAF block" this broke some profiles 🙂

[faint lark]

ooooh this I did not see probably broke mine too 😄 @forest ether

we really need to come up with a way to say "im an appsec alert"

[nocturne geode]

And final question - where do I need to ask if I never got a signup mail for https://app.crowdsec.net/
I wrote an E-Mail to support...

[faint lark]

DM me your email, was it to activation code?

[nocturne geode]

Yes - never got the activation code.

[willow rune]

Resolving Why is there no decision to this appsec alert