Twelve VPN Successes After a Low-and-Slow Spray
At 09:05 on Monday the SIEM fires on VPN authentication: 1,847 failures from 58 source IPs across nine ASNs, against 912 distinct usernames, over 40 minutes. Twelve authentications then succeed. Eleven of those accounts carry on with activity that looks ordinary. The twelfth, a finance analyst, immediately opens an SMB session to the file server and copies 380 files (about 1.4 GB) to a personal cloud-storage domain that is not on the proxy allowlist. The VPN requires a password plus push MFA. The file server has no EDR agent. VPN concentrator logs are retained for 30 days. HR confirms the analyst is on leave until Thursday. Legal has asked that nothing be deleted pending review, and the company has a four-hour regulatory notification clock for confirmed breaches of personal data. The SOC lead is in a meeting for the next 45 minutes.
1. Classify the authentication event and explain what in the numbers distinguishes it from credential stuffing and from brute force.
Read the worked answer
It is a password spray, and the arithmetic says so: 1,847 attempts across 912 distinct usernames is about two attempts per account, spread over 58 source IPs. Brute force concentrates many attempts on one account; credential stuffing reuses leaked pairs, producing few accounts with high attempt counts and a distinctive password-reuse signature, and typically many successes against unrelated services. Here the attacker is buying one or two tries per user to stay under lockout thresholds, which is the definition of spraying.
The harder question is the twelve successes. A password alone should not be sufficient - push MFA was required. So one of three things happened:
- MFA fatigue / push bombing - the attacker already held valid passwords and repeatedly pushed until a user approved. That produces a burst of push events for a single account, which the MFA provider log will show and the VPN log will not.
- Real-time phishing proxy capturing both factors.
- A legacy or service account exempt from MFA in the twelve.
Check the MFA provider for push volume per account and denied-then-approved sequences, and check impossible travel for the twelve sessions. The copy to an unlisted cloud domain 0 seconds after login is not consistent with the account owner - she is on leave - so treat that session as attacker-controlled, not as insider.
2. List your containment and preservation actions in priority order, accounting for the legal hold and the absent user.
Read the worked answer
Two constraints shape the order: VPN logs age out at 30 days, and nothing may be deleted.
- Revoke sessions and refresh tokens for all twelve accounts before resetting passwords. Password resets without token revocation leave live sessions running - the attacker keeps the SMB session while IT congratulates itself. Revoke first, then force re-authentication.
- Export the VPN concentrator logs now, and pull the MFA provider's push history and the file server's SMB access logs for the affected share. The 30-day window is not the only risk; correlation across three sources gets harder every hour.
- Cut the exfil path without deleting evidence: add the personal cloud domain to the proxy block list and confirm whether the 1.4 GB transfer completed or was throttled. Proxy flow records showing completed versus partial transfer are the difference between 'attempted' and 'confirmed'.
- Do not disable the on-leave analyst's mailbox or drive, and do not delete anything; legal hold means preserve. Disabling the account is fine after tokens are revoked, but preserve its contents.
- Contact the analyst by phone - she may have approved a push while travelling, which changes the classification from compromised credentials to MFA bypass.
- Escalate to the incident commander and start the notification decision in parallel, because the four-hour clock is measured from confirmation, not from discovery.
Ordering rationale: revoke, preserve, block, then communicate - each step is a precondition for the next being meaningful.
3. It is now 11:40 and you must decide whether to invoke the four-hour breach notification. Argue the decision on the evidence you can realistically obtain in the next 60 minutes.
Read the worked answer
The decision turns on one question: did the 380 files contain personal data? Everything else is secondary.
What can be established quickly: the file names and paths are visible in the SMB access log and the proxy record - you do not need to open the files, which respects the legal hold. If the share structure is by customer or policy number, the file names alone may confirm the data class. Ask the finance manager what lives in that directory; that is a five-minute conversation that often settles it.
What cannot be established quickly: whether the attacker read the data versus merely copied it, and where it now sits. Neither affects the notification obligation.
Reasoning to a decision: if the copied path set contains identifiable customer or employee records, treat the breach as confirmed and start the clock. If the path set is unambiguously non-personal (aggregate reports, internal forecasts), document that finding with the evidence used and record why notification is not triggered. The failure mode to avoid is drifting past the deadline while waiting for certainty you will never get - regulators assess whether you notified promptly after forming a reasonable belief, not whether your forensics were complete.
Log the decision, the decision-maker, the evidence relied on, and the time. If the evidence is genuinely ambiguous at the deadline, notify and correct later; late notification is a separate violation from the breach itself.