Campaign detection

Coordinated attack detection catches many IPs hitting one endpoint within one time window. An attacker who spreads the same technique across several endpoints, rotates identities and user agents, or paces requests over hours instead of seconds never fills that one bucket. Campaign detection correlates on what does not change when an attacker automates: the same detection technique, the same request method, the same probe order, machine-regular spacing, and a small set of automation-classified source IPs, regardless of which endpoint or which IP delivers any single request. This is a SaaS-only capability with no in-process equivalent.

The campaign problem

A campaign is one scripted actor working across endpoints and time, not one burst against one endpoint:

• 40 rotating identities probe four different endpoints in the same fixed order, 250 milliseconds apart, one at a time.
• No single endpoint sees more than a quarter of the traffic in any five-minute window, so a per-endpoint burst detector never crosses its threshold.
• The technique is identical every time: guard-core's threat category when it sends one, otherwise a label derived from the event type, paired with the same HTTP method where that label still carries one.

How the SaaS detects it

Two detectors feed one campaign record, both gated to organizations on a tier that includes coordinated attack detection, Team and above.

Seeding and technique. Only an event with a matched pattern, or one of six event types, penetration_attempt, pattern_detected, decorator_violation, authentication_failed, behavioral_violation, suspicious_request, seeds a campaign. Bans, rate limits, country or cloud blocks and other bookkeeping events never seed one on their own. Guard-core's own threat category on the event becomes its technique when guard-core sends one, otherwise the first of its threat categories, otherwise a label derived from the event type: penetration for penetration_attempt, pattern_detected or decorator_violation, auth_failure for authentication_failed, behavioral for behavioral_violation, suspicious for suspicious_request. The fingerprint is that technique plus the request method, except method is dropped whenever the qualifying event's type is one of those same six, penetration_attempt, pattern_detected, decorator_violation, authentication_failed, behavioral_violation or suspicious_request: pattern_detected fires outside request scope and structurally carries no method at all, so normalizing method away for all six avoids fragmenting one scripted attacker's campaign on a field several of its events do not reliably carry.

A realtime burst detector watches the same fingerprint across every endpoint at once. When a fingerprint crosses 15 distinct source IPs and 60 events within a five-minute window, it computes a provisional score from distinct IPs, distinct endpoints and the automation share of those IPs, then opens a campaign only if that score reaches 0.6 and the fingerprint has touched at least 2 distinct endpoints. A burst confined to one endpoint stays with coordinated attack detection instead.

A scheduled job runs every five minutes over the last 24 hours of events per organization, grouped by the same fingerprint. For every group with at least 8 distinct IPs that seeded it, it scores six signals: distinct-IP volume, distinct-endpoint spread, whether members share the same ordered sequence of endpoints, how machine-regular the spacing between a member's requests is, how concentrated the user agents are across the group, and what share of members resolve to an automation IP type (the same classification coordinated attack detection uses, which includes datacenter IPs). A member's probe order and cadence draw on all of that member's security events in the 24-hour window, not only the ones that seeded the campaign, so a ban or a rate limit that follows still shapes its behavior signals; consecutive rows from the same member within 100 milliseconds collapse into one, since guard-core can emit several event rows in quick succession for what is functionally one request. The weighted combination of the six signals is the campaign's real score, replacing the realtime detector's provisional one on the job's next pass.

Lifecycle

A campaign opens once its score reaches 0.6 with at least 8 distinct IPs and at least 2 distinct endpoints. While open, new matching events refresh its score, evidence and member list without a new alert. A campaign with no matching event for 24 hours closes; if the same technique-and-method fingerprint returns later with a qualifying group, the same campaign record reopens rather than starting over.

Alerting

One alert fires when a campaign opens, and one more if it later reopens after closing, through the same channels coordinated attack detection uses: Slack, Discord and PagerDuty, wired from Settings -> Integrations. Slack and Discord post a message titled "Campaign detected", or "Campaign reopened" on a reopen, carrying the technique, method, score, member count, endpoint count, status, the project when the campaign resolves to one, and a link to the campaign page. PagerDuty gets a summary of Campaign detected: {technique} {method} score {score}, or Campaign reopened: {technique} {method} score {score} on a reopen, with the same fields in its custom details, severity critical at a score of 0.8 or higher and warning below that. Ordinary growth of an already-open campaign does not alert again.

Blocking

From a campaign's detail page, Block all members adds every member's IP to the project's dynamic rule blacklist in one push. A project can also opt into auto-block: once enabled in project settings with a minimum score, the scheduled job blocks a campaign automatically the moment its score crosses that threshold, no manual step required. Auto-block is off by default. Blocking, manual or automatic, requires the Dynamic Rules feature in addition to campaign detection itself.

The campaigns dashboard

The dashboard lives at /campaigns, next to Coordinated Attacks.

The list view shows score, technique, method, member count, endpoint count, first and last seen, and status.

The detail view shows the fingerprint and technique, the score with a bar per signal, the member table (IP hash, automation type, ASN, event count, endpoints hit), the top probe sequences shared across members, and a Block all members action with a confirmation step. A campaign whose members span more than one project asks which project to block against, since the dynamic rule push is per-project.

For the broader incident workflow, see the dashboard documentation, available with an account.

Tier gating

Campaign detection requires the same plan tier as coordinated attack detection: Team, Business, and Enterprise. Blocking and auto-block additionally require the Dynamic Rules feature. If you are on a gated tier and the dashboard is empty, confirm your agents are shipping enough volume for a burst or a 24-hour window to qualify.