Evilginx Capture Pipeline, Loot API, and Webhook Notifications

Automatically ingest evilginx adversary-in-the-middle credential and session captures into Guard phishing campaigns, retrieve captured session loot via API, and receive real-time webhook notifications when sessions are captured.

Evilginx Capture Pipeline, Loot API, and Webhook Notifications

Guard's evilginx capture pipeline closes the loop on phishing simulations by receiving credential and session material from evilginx adversary-in-the-middle (AiTM) infrastructure and attributing it directly to campaign recipients. Results appear in Guard in real time without manual export or correlation. Operators can retrieve captured session loot programmatically via API and receive automated webhook notifications when new sessions are captured.

Overview

When a phishing simulation uses evilginx to proxy target sessions, captured credentials and cookies are automatically forwarded to Guard over an authenticated webhook. Guard normalises each inbound event, correlates it to the correct campaign recipient, and stores the captured material as a per-session artifact. A backfill job handles any events that arrive late or out of order.

A WAFv2 IP allowlist fronts the webhook route so that only known evilginx node addresses can reach the ingest endpoint.

How the pipeline works

Stage

Description

Webhook receiver

Accepts authenticated POST events from evilginx nodes over HTTPS. Each request must include a valid bearer token.

WAF IP allowlist

A WAFv2 IP set in Count mode restricts inbound traffic to known evilginx infrastructure addresses before requests reach the receiver.

Event normalisation

A consumer reads each inbound event, extracts credential fields and cookie/session material, and maps them to the Guard campaign event schema.

Session attribution

Normalised captures are correlated to individual campaign recipients, producing per-user records of compromised credentials and session tokens.

Backfill cron

A scheduled job reconciles events that arrived out of order or were delayed, ensuring complete coverage across the campaign lifecycle.

Security model

Bearer token authentication. Every evilginx node must present a bearer token when posting to the webhook. Guard stores tokens as SHA-256 hashes and performs constant-time comparison on every request to prevent timing-based token enumeration.

WAF IP allowlist. Guard places a WAFv2 IP set in front of the webhook route. Only IP addresses registered as known evilginx nodes are permitted. Requests from addresses outside the allowlist are counted and can be blocked, limiting the attack surface of the ingest endpoint.

Encrypted loot storage. Full session loot — including credentials, cookies, and auth tokens — is stored encrypted at rest. Raw session cookies are not exposed through the campaign-level list endpoint; they are available only through the per-capture detail endpoint.

Retrieving captured session loot via API

Guard exposes two endpoints for programmatic access to phishing capture data, eliminating the need to manually SSH into phishkit nodes to retrieve results.

List captures for a campaign

GET /red-team/campaigns/{id}/captures

Returns credential metadata, origin, and timestamps for all captures associated with the specified campaign. Raw session cookies are not included in this response.

Use this endpoint to enumerate all captures within a campaign and obtain individual capture UUIDs for detailed retrieval.

Get full detail for a single capture

GET /red-team/captures/{uuid}

Returns the full replay context for a single captured session, including:

  • Captured credentials (username and password)
  • Session cookies and auth tokens
  • User agent string
  • Origin IP address
  • Capture and event timestamps

Use the UUID returned from the campaign captures list to request individual session detail.

Automated webhook notifier provisioning

Guard automatically configures webhook notifiers for evilginx campaigns during the Configure and Reconfigure steps. All four evilginx trigger types are enabled and verified on setup. This replaces the previous requirement to manually SSH into phishkit nodes and run evilginx notify commands.

Operators receive real-time notifications when sessions are captured without any additional configuration steps.

Campaign results

Once captures are ingested and attributed, the following information is available per campaign recipient:

  • Captured credentials (usernames and passwords submitted through the evilginx proxy)
  • Session cookies and tokens harvested during the AiTM session
  • Attribution metadata linking each capture to the targeted user and campaign

This data surfaces in the same campaign reporting views used for other phishing simulation outcomes, enabling unified per-user analysis without leaving Guard. The same data is accessible programmatically via the Loot API endpoints described above.

Requirements

  • An evilginx node reachable from the Guard webhook endpoint
  • A bearer token issued and registered in Guard for each evilginx node
  • The evilginx node IP address added to the Guard WAF allowlist before simulation traffic begins

Contact your Praetorian engagement team to provision webhook credentials and register evilginx node addresses prior to running a phishing simulation.