mcpField
C
cross-wave-delta-analysis

cross-wave-delta-analysis

github.com/uphiagoSecurity1.3k44 installsUpdated 8w ago
Repository

About cross-wave-delta-analysis

cross-wave-delta-analysis is a security analysis skill for comparing repeated recon results on the same target set. It classifies findings as new, regressed, persistent, changed, or reversed, and stresses retesting with consistent methods.

Key features

  1. 01Compare recon waves
  2. 02Identify new and regressed findings
  3. 03Track persistent issues and configuration changes
  4. 04Flag reversed security measures
  5. 05Retest deltas and avoid false classifications

Use cases

  1. 01Check whether a vulnerability has been patched
  2. 02Find newly exposed ports, subdomains, or endpoints
  3. 03Recheck finding status before reporting

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/uphiago/recon-skills --skill cross-wave-delta-analysis

After installing, type/cross-wave-delta-analysisin Claude Code to confirm it loaded.

Details

From the project README

Cross-Wave Delta Analysis Skill

Methodology for comparing findings across multiple recon waves on the same target set. Detects NEW findings, REGRESSIONS (previously open now blocked), PERSISTENT vulnerabilities, and CHANGES over time. Distilled from 9 waves across 7 deep targets that revealed missed CORS findings, new port exposures, and infrastructure drift.

When to Use

  • Running repeated recon on the same target set (Wave N+1 after Wave N).
  • You want to know if a vulnerability was PATCHED since last wave.
  • You want to know if a NEW surface appeared (new ports, new subdomains, new endpoints).
  • After completing a deep recon wave — produce the delta report before next wave.
  • Before reporting — confirm findings are still valid (not regressed).

Prerequisites

  • Prior assessment output beneath ${OUTPUT_DIR:-./output}/baseline/.
  • Current assessment output beneath ${OUTPUT_DIR:-./output}/current/.
  • Structured findings per target (at minimum: ports, CORS status, WP users, XMLRPC status, sensitive paths).

How to Run

# Produce a delta report comparing WaveN to WaveN+1
# Read wave outputs, compare per-target, classify findings

Quick Reference

Delta Categories
CategoryLabelMeaningExample
NEW++Finding that didn't exist in any prior wavePort 3306 (MySQL) now OPEN
REGRESSION--Service that was accessible but is now blockedXMLRPC 200 -> 405 (hardened)
PERSISTENT==Vulnerability unchanged across all wavesCORS still reflecting since wave6
CHANGE~Configuration changed but not a regressionWP users: 10 in wave7, 9 in wave9
REVERSED->A regression that was later undone (mitigation removed)XMLRPC 405 (W9) -> 200 active (W10)
REVERSED — Special Category

Reversed findings are regressions that later reverted to the original vulnerable state. This happens when:

  • A WAF rule was applied temporarily then removed (common on GoDaddy/Cloudflare shared hosting)
  • A plugin security update was rolled back
  • Infrastructure was redeployed without the hardening

Treat REVERSED as actionable: the security team either doesn't know or doesn't care. These targets are high-priority because their protection is unreliable.

Fields to Compare Per Target
FieldHow to CheckWhat Delta Means
XMLRPC statusHTTP status of POST /xmlrpc.php200 -> 405 = REGRESSION (hardened)
CORS headersACAO + ACAC on /wp/v2/usersReflecting -> No headers = REGRESSION
WP UsersCount from /wp/v2/usersCount change = CHANGE
Open portsnmap or naabu outputNew port = NEW (surface expanded)
Subdomainssubfinder outputNew subs = NEW
Sensitive pathsHTTP status for .env, info.php, etcPreviously 200 -> 403 = REGRESSION

Procedure

Step 1 — Gather Both Waves' Data
WAVE_OLD="${OUTPUT_DIR:-./output}/baseline"
WAVE_NEW="${OUTPUT_DIR:-./output}/current"
echo "=== Comparing $WAVE_OLD vs $WAVE_NEW ==="
Step 2 — Produce Per-Target Delta Table

For each target present in both waves, compare XMLRPC status, CORS headers, open ports, WP users, and subdomains. Flag findings as NEW (not in prior wave), REGRESSION (previously working, now blocked), PERSISTENT (unchanged), or CHANGE (different but not blocked).

Step 3 — Classify & Flag Critical Deltas

Signal critical deltas: new port 3306 (MySQL), new CORS credential reflections, new WP install pages, new subdomains with admin/staging patterns.

Pitfalls

  • False REGRESSION. A 403 may be rate limiting, not patching. Retry 3x with different IPs/delays.
  • False PERSISTENT. A 200 endpoint may still be live but the underlying vulnerability (e.g., multicall) may be disabled.
  • Timing matters. Waves must use the same methodology or deltas are meaningless.
  • Don't confuse "not documented" with "not present." A finding may have existed but was simply missed.

Verification

  • Every delta must be reproducible with the exact same command on both waves' output.
  • NEW findings should be re-tested immediately — they may be transient.
  • PERSISTENT findings across 3+ waves are the most reliable (no security team, no patching cadence).

Related Skills

  • attack-patterns-reference — match findings to pattern IDs (P-01 to P-25)
  • recon-playbook — the 4-phase pipeline that produces wave data
  • cross-attack-chains — chain NEW findings into critical impact
  • cors-credential-wordpress — verify CORS findings classification
  • xmlrpc-exploitation — verify XMLRPC regression status

Comments

Markdown supported