Attack History

Attack history is Pro’s forensic view into Card-Testing Defense activity: the 24-hour intelligence card on the Card-Testing Defense page and its CSV export. While the velocity rules and lockouts operate in real time, this is the place to go after an attack to understand what happened, audit your defense, and tune for next time. This page covers what’s in the card, how to read it, and what questions it answers.

Location: TrustLens → Card-Testing Defense → 24-hour intelligence (below the Detection Settings and Allowlists cards).

---

What’s on the Page #

Headline Metrics (Free) #

The top of the Card-Testing Defense page shows, for every tier, the last 24 hours’ declines, checkout submissions, decline rate (declines ÷ submissions), and the number of fingerprints held right now. Spikes above your baseline indicate active or recent attacks.

Targeted Now (Free) #

Every fingerprint currently held, with its strike count (when it has tripped detection more than once), when it’s held until, and a Release button. Releasing lifts the hold, wipes the device’s strike history, and clears its card-testing taint — use it for false positives.

Hourly Timeline Chart (Pro) #

Declines per hour over the last 24 hours. Useful for spotting:

• When an attack started and stopped
• Whether it came in one burst or several waves
• Your normal hour-to-hour decline volume, for comparison

Decline-Code Breakdown (Pro) #

A table of the gateway decline codes recorded in the last 24 hours (insufficient funds, invalid expiry, fraud-suspect, processor decline, etc.) with the count for each. Useful for:

• Identifying attack types. Card-testing attacks heavily skew toward “insufficient funds” and “invalid expiry” — bots try lots of cards quickly and most fail validation.
• Distinguishing attacks from gateway issues. A spike in “processor decline” or “communication error” usually means your gateway is having trouble, not that you’re under attack.

Top Attacking Fingerprints (Pro) #

The 10 fingerprints that produced the most declines in the last 24 hours, with each fingerprint hash and its decline count. Declines recorded against the server fingerprint count here too, so a bot rotating its browser fingerprint still shows up. The dashboard’s Top Attacker Fingerprints panel shows the top 5.

---

CSV Export #

The Export CSV link in the card downloads the raw velocity events for the last 24 hours, one row per event, with these columns:

• created_at_utc — event timestamp (UTC)
• event_type — submission, decline, gate_block (a request the gate stopped), target (a fingerprint newly locked out), and the server-fingerprint mirrors submission_server / decline_server
• fingerprint_hash
• decline_code — the gateway decline code, or the block reason for gate_block rows
• order_id — when the event belongs to an order

The export doesn’t include IP addresses, email hashes, or countries. Use it for offline forensics — pivot tables in Excel, custom dashboards, fraud team reviews.

---

Common Investigations #

“Was that spike an attack?” #

1. Open the Card-Testing Defense page
2. Look at the hourly timeline — does the spike show on the chart?
3. Check decline-code breakdown — heavy “insufficient funds” / “invalid expiry” suggests card testing
4. Check the top attacking fingerprints — a small number of fingerprints with high counts = bursty attack; many fingerprints with moderate counts = distributed

“Did we miss any attempts?” #

1. Export the CSV and filter it to the attack window
2. Compare decline rows against target rows for each fingerprint — declines from fingerprints that were never targeted slipped under the velocity rules
3. If significant, tighten thresholds (especially Declines in 1 hour), or set up the Browser Challenge for attackers who change identity on every attempt

“Are any of our lockouts hitting real customers?” #

1. Check the Targeted now list during and after the attack
2. For each held fingerprint, look for completed orders in the CSV (rows with an order ID) and check those customers in TrustLens
3. Release any fingerprint that belongs to a legitimate customer
4. If false positives are common, consider allowlisting or tuning thresholds up

“Why did auto-escalation fire (or not fire)?” #

1. Count the target rows in the CSV around the time of the freeze — auto-escalation needs 3 distinct fingerprints targeted within 10 minutes
2. If enough fingerprints were targeted but no freeze happened, the geo-diversity safeguard judged the burst natural (3+ countries, none above 50%)
3. Check that WooCommerce geolocation is working — without it the safeguard never blocks an escalation

---

Data Retention #

Velocity events are retained for 48 hours by default, then purged by a daily retention job. The retention window is set in hours on the TrustLens → Card-Testing Defense page and can range from 24 to 168 hours (1 to 7 days).

The card and the default export cover the last 24 hours. Events older than the retention window are gone, so export the CSV soon after an attack if you want to keep a record.

---

Privacy #

Velocity events store the IP address of each checkout attempt and, when the checkout carried one, the customer’s email hash — for the retention window only. They aren’t part of WordPress’s personal-data export and erasure tools; the retention job removes them. The CSV export leaves out IP addresses and email hashes, so a file can be shared with fraud teams or processors without exposing customer IP addresses.

---

Limitations #

• Attack history only shows events captured by TrustLens. Attacks blocked at the WAF / CDN level before reaching WordPress aren’t visible here.
• There is no country breakdown, no list of past Panic Freeze activations, and no record of bypass or allowlist decisions.
• The longest history available is the retention window — at most 7 days. Export and archive the CSV if you need longer-term pattern analysis.
• Customer-association requires the request to include a billing email — pure pre-checkout probes without an email don’t link to a customer record.

---

Best Practices #

• Check the page weekly even when no attacks have happened. Baseline knowledge of your normal decline patterns makes anomalies obvious.
• Export after every attack. The data is purged after the retention window, so the CSV is your archive.
• Tune after every attack. Each real attack is a tuning opportunity — what threshold would have caught it faster?
• Document attack patterns. Recurring attack signatures often re-emerge. A notes file keyed by signature helps future-you respond faster.