At 09:14 on a Tuesday, your ISP reports the UDP flood has collapsed. Scrubber graphs sit near baseline, the ransom email has gone quiet, and the NOC wants the BGP diversion torn down before lunch. Ten minutes after you withdraw the community, checkout latency spikes again and your NetScaler authentication path starts returning intermittent 503s. The volumetric layer cooled; the application path never recovered under load that still mattered to customers.
That pattern keeps showing up in the same weeks as edge exploitation news. Citrix's NetScaler SAML zero-day patches, ScreenConnect clients pulled into attacker tooling, and distraction-heavy extortion crews such as those tied to the ShinyHunters investigations all push the same lesson for DDoS responders: treat a quiet scrubber as a hypothesis, then prove service health before you restore the direct path.
Start from the paths customers still need
Build your confirmation checklist around the services that fail first under hybrid pressure, not around the protocol that filled the pipe.
- Auth and SSO front doors — SAML ACS URLs, OIDC token endpoints, MFA challenge pages, and VPN portals. Edge appliance flaws turn these into dual-use targets during floods.
- Transactional APIs — checkout, quote, booking, and payment webhooks. Soft L7 abuse often continues after UDP and SYN floods drop.
- Remote support ingress — ScreenConnect, RDP gateways, and similar jump paths. Attackers already treat these as reliable footholds; flood noise makes abuse harder to notice.
- DNS that your users actually query — authoritative answers for your brand zones and the recursive path your split-horizon clients depend on.
Write those four groups into the incident ticket before diversion starts. When the scrubber later looks calm, you already know which synthetic checks and log joins decide whether traffic can come home.
Detection steps while diversion is still up
Keep monitoring in two lanes: attack telemetry and victim-service telemetry. The first lane tells you the flood is changing shape. The second lane tells you whether users can complete work.
Lane one: attack shape and source churn
- Track packets-per-second and bits-per-second by vector every 60 seconds: UDP amplification remnants, SYN, ACK reflection, HTTP GET/POST floods, and slow-header or slow-body patterns.
- Watch source ASN diversity and prefix novelty. A collapse in volume with rising prefix churn often means the operator switched from rented botnets to application probing.
- Compare scrubber drop classes against your own edge ACL hits. If the scrubber reports mostly UDP while your WAF still sees rising 401/403/429 on login POSTs, the campaign has pivoted.
- Flag simultaneous management-plane probes on NetScaler, VPN, and remote-support listeners. Pair flood tickets with the same advisory watch you already run for SAML and appliance CVEs.
Lane two: signals that prove the business path
- Run synthetic transactions from at least three regions outside the scrubber: anonymous browse, authenticated session create, passwordless or MFA step, and one write API that touches inventory or payment authorization in a safe test tenant.
- Measure p95 and p99 latency plus error budget burn for those transactions, not average latency. Flood aftermath often hides in the tail.
- Join WAF and reverse-proxy logs to identity logs for the same window. Look for password spray, token replay, and new device enrollments while volumetric counters fall.
- Check origin connection tables and TLS handshake failures even when the scrubber dashboard is green. A clean transit report can still hide origin pool exhaustion.
- Verify DNS: authoritative SOA serial consistency, resolution success from public vantage points, and NXDOMAIN spikes for hostnames attackers fuzz during the same campaign.
Give each signal an owner and a pass/fail threshold in the runbook. Example thresholds that hold up in practice: synthetic checkout success at or above 99% for 30 continuous minutes, auth p95 under your normal peak-hour budget, origin concurrent connections under 70% of the pool limit, and no new privileged identity events unexplained by change tickets.
Response actions that keep mitigation honest
Hold diversion until the application lane passes
Require dual acknowledgment before withdrawing BGP communities or CDN emergency configs: one from network operations on attack telemetry, one from the application or identity owner on synthetic and log evidence. Document the hold time. Many teams use a minimum 30 to 60 minute green window across both lanes, with an automatic extension if auth error rates rise more than one standard deviation above the pre-incident baseline.
Stage the return path
Bring traffic back in slices when your provider supports it. Move static and cacheable content first, then read APIs, then auth and checkout. Keep a rollback community ready. If auth synthetics fail after the first slice, push that prefix class back to scrubbing without waiting for another full war-room debate.
Keep L7 controls independent of the scrubber
At the WAF and API gateway, retain tighter rate limits, bot challenges, and per-route concurrency caps for login, password reset, OTP verify, and payment intents until the next business day. Volumetric scrubbing removes packet storms. Application rate policy still has to absorb credential stuffing and request floods that ride otherwise legitimate TLS.
Treat remote support and edge admin as flood-adjacent risk
During the same incident window, freeze new ScreenConnect and similar remote-access enrollments, require step-up approval for console sessions on NetScaler and VPN appliances, and compare admin session inventories to change records. Hybrid campaigns use saturation to bury the session that matters.
Preserve evidence for the distraction hypothesis
Export scrubber summaries, edge ACL counters, WAF top offenders, identity anomalies, and EDR lateral-movement hunts for the diversion period. Extortion and access brokers benefit when responders celebrate a flat traffic graph and close the ticket. Keep the hunt queue open until auth timelines and endpoint timelines look ordinary for your environment.
A compact confirmation scorecard
Use a single table in the incident channel so the decision stays visible:
- Attack lane — primary vector under X% of peak for 30 minutes; no new vector above your alert floor; ASN churn trending down.
- DNS lane — public resolution success for critical names; no serial skew across anycast nodes.
- Auth lane — synthetic login and MFA success; no unexplained spike in failed passwords or new MFA devices.
- Commerce lane — checkout or equivalent write-path success and p99 latency inside budget.
- Origin lane — connection pool, TLS failures, and 5xx rate inside budget.
- Admin lane — no unapproved edge or remote-support sessions; advisory-linked probe IPs reviewed.
All six rows green means you may stage withdrawal. Any red row means diversion stays up or that slice returns to scrubbing.
Implementation details worth wiring now
Instrument synthetics that exercise the real IdP redirect, not a static health URL. Static /health checks stay green while SAML ACS handlers time out under load. Export scrubber metrics into the same observability backend as WAF, DNS, and identity so on-call staff can overlay them without screen-sharing five portals. Pre-negotiate emergency capacity and community strings with your ISP and scrubbing provider, including who may authorize spend when a ransom note lands before peak. Rehearse the scorecard in a game day that includes a mid-event pivot from UDP to HTTP on the login route; that pivot is the usual failure mode for teams who only practice pipe saturation.
Timely context helps keep the runbook sharp. Appliance patch cycles such as the NetScaler SAML fixes, remote-support abuse involving ScreenConnect clients, and law-enforcement attention on access-broker ecosystems all underline why DDoS closeout belongs next to identity and edge reviews. Pair that operational habit with your usual advisory listening, including sources such as ISC Stormcast, so flood response and exploit response share one clock.
Takeaways for the next incident
- Define customer-critical paths before the flood starts, and make those paths the gate for lifting diversion.
- Run attack telemetry and application telemetry as equal lanes with named owners.
- Return traffic in slices, keep L7 controls elevated after the pipe clears, and leave admin and remote-support reviews open until identity evidence agrees.
- Close the incident on confirmed transactions and clean auth timelines, with scrubber graphs as supporting context only.
