Threat Detection

Threat detection enriches every request with what is already known about its source — reputation from Gen0Sec's feeds, geographic and network origin, and the client's own fingerprint — and makes all of it available as conditions you can write rules against.

It does not decide anything on its own. It supplies the evidence; rules decide what to do with it.

What it gives you

Reputation without running your own feeds. Scores are aggregated from a large set of sources and kept current for you.
Identity that survives IP rotation. A client's fingerprint stays the same when its address changes, so a blocked tool does not come back simply by moving.
Network and geographic context — ASN, the organisation behind it, and country.
One vocabulary across features. The same fields are available to the WAF, to access policy, and to logging.

What you can act on

Field	Meaning
`threat.score`	Reputation score, 0–100
`threat.advice`	Recommended action: `allow`, `block` or `challenge`
`ip.src.country`	Country of the source address
`ip.src.asn`	Autonomous System Number
`ip.src.asn_org`	Organisation that owns the ASN
`ip.src.asn_country`	Country the ASN is registered in

The full field list is on WAF — kept there rather than duplicated here so the two cannot drift.

Two rule surfaces, two field sets

These are the fields available to WAF rules, which run in the proxy on HTTP requests. The agent's firewall rules use a different and larger scheme — it reaches IDS, ML and Kubernetes identity, and names HTTP fields differently (http.host rather than http.request.host). A field that works in one will not necessarily parse in the other. See Amygdala for the firewall side.

Combining them is the point:

# Reputation says block, and the source agrees it is worth acting on
threat.score > 80 and threat.advice == "block"

# Somewhere between suspicious and hostile — challenge instead of blocking
threat.score > 50 and threat.score <= 80

# Reputation, narrowed to one network
ip.src.asn == 64500 and threat.advice == "block"

Advice, and why it exists alongside the score

threat.score is a number; threat.advice is Gen0Sec's recommendation given everything known about that source. Acting on advice keeps your policy stable when scoring changes underneath it — you are asking "should this be blocked?" rather than pinning a threshold that may mean something slightly different next month.

Thresholds remain available when you want to set the bar yourself.

Fingerprints as identity

Threat detection also attaches the client's JA4+ fingerprint, which describes how the client speaks rather than where it speaks from — its TLS handshake, its HTTP header order, its TCP stack. Two connections from different addresses running the same tool share a fingerprint.

That makes a fingerprint the durable half of an identity, and an address the disposable half. See JA4+ for what each type covers, and Dendrite for how they are captured.

Limits worth knowing

Reputation is about the source, not the request. A clean address can still send a malicious payload — that is the WAF's and Content Scanning's job.
Shared addresses carry shared reputation. A CGNAT or corporate egress address represents many users; prefer fingerprint or a combination of signals before blocking one outright.
A fingerprint identifies a client, not a person. Many legitimate clients share one, so treat it as a strong grouping signal rather than proof.

Use cases

Block sources the feeds already know are hostile, before writing a single custom rule.
Challenge rather than block in the ambiguous middle, so a false positive costs a user friction instead of an outage.
Stop a credential-stuffing tool by fingerprint, so rotating its addresses does not help it.
Require two signals before acting — reputation and fingerprint — to keep false positives off the block list.

What it gives you​

What you can act on​

Advice, and why it exists alongside the score​

Fingerprints as identity​

Limits worth knowing​

Use cases​

See also​