Attack History

The Attack History tab is Pro’s forensic view into Card-Testing Defense activity. While the velocity rules and lockouts operate in real time, Attack History 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 on the tab, how to read it, and what questions it answers.

Location: TrustLens → Card-Testing Defense → Attack History.

---

What’s on the Tab #

24-Hour Decline Count #

A headline number — total declines from card-testing-protected requests in the last 24 hours. Spikes above your baseline indicate active or recent attacks. The number is paired with a small trend sparkline for the prior 24 hours so you can see the shape.

Decline-Code Breakdown #

A table of decline reason codes (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.
• Estimating attack progress. A few “approved” results among many declines means the attacker is finding live cards.

Top-10 Attacking Fingerprints #

A table of the 10 fingerprints that produced the most declines in the last 24 hours, with:

• Fingerprint hash (clickable to filter the event log)
• Decline count
• First and last seen timestamps
• Top countries (from GeoIP)
• Whether the fingerprint is currently locked out, allowlisted, or normal

Hourly Timeline Chart #

A 7-day chart showing decline counts per hour. Useful for spotting:

• Attack timing patterns (some attackers operate on schedules)
• Recurring attacks (same hour each day)
• Time-of-day baselines for your normal decline volume

Recent Lockouts #

List of recent per-fingerprint lockouts and their causes (which 60-second velocity threshold was crossed — declines or submissions). Confirms which fingerprints have been auto-locked and lets you investigate whether any look like false positives.

Recent Panic Freeze Activity #

All Panic Freeze activations and deactivations from the last 30 days, with trigger source (manual / auto-escalation / canceled).

---

CSV Export #

The full event log can be exported as CSV. The export includes every velocity event from the last 90 days:

• Event timestamp
• Event type (decline / lockout / panic_freeze / panic_cancel / etc.)
• Fingerprint hash
• IP (when available; hashed in the export for privacy)
• Decline code
• Customer email hash (if associated)
• Country code (from GeoIP)

Use the export for offline forensics — pivot tables in Excel, custom dashboards, fraud team reviews.

---

Common Investigations #

“Was that spike an attack?” #

1. Open Attack History
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 top-10 fingerprints — small number of fingerprints with high counts = bursty attack; many fingerprints with moderate counts = distributed

“Did we miss any attempts?” #

1. Filter event log to the attack window
2. Count declines from un-locked fingerprints — these slipped through velocity rules
3. If significant, tighten thresholds or enable per-fingerprint overrides on the worst offenders

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

1. Open the recent-lockouts list
2. For each lockout, check the associated customer email hash (if any)
3. Cross-reference against customer records — does the fingerprint match a known-good customer profile?
4. If false positives are common, consider allowlisting or tuning thresholds up

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

1. Check the Panic Freeze activity log for auto-escalation events
2. For each, look at the contributing fingerprints in the event log around that timestamp
3. Verify the geo-diversity safeguard verdict
4. If the safeguard blocked an escalation you would have wanted, lower the country threshold; if it let a false escalation through, raise the country threshold

---

Data Retention #

Velocity events are retained for 48 hours by default, then purged by a retention cron. 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).

Aggregate counts (24h, hourly) are computed from raw events, so they reflect only data within the retention window. Older attacks are no longer visible in Attack History after the retention period.

---

Privacy #

Attack History data is part of the standard TrustLens data set — covered by GDPR export and erasure tools. The CSV export hashes IPs to a one-way hash before writing, so an exported file can be shared with fraud teams or processors without exposing customer IP addresses in cleartext.

---

Limitations #

• Attack History only shows events captured by TrustLens. Attacks blocked at the WAF / CDN level before reaching WordPress aren’t visible here.
• Country attribution depends on GeoIP availability. Without a working GeoIP source, country columns will show “unknown.”
• The 90-day retention default may be too short for compliance or longer-term pattern analysis. Extend retention if needed.
• 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 #

• Review weekly even when no attacks have happened. Baseline knowledge of your normal decline patterns makes anomalies obvious.
• Export and archive monthly. A 12-month archive gives you year-over-year comparison.
• 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.