A regional hospital's VPN portal logged fewer than three failed authentications per source address on a Tuesday overnight window. Per-IP lockouts stayed green. The SOC pager stayed quiet. By morning, a shared service account for imaging workflow had been guessed correctly from forty-one addresses spanning residential broadband, a compromised VPS range, and two cloud provider ASNs. Ransomware staging began ninety minutes later through that same VPN session. The attack never looked like classic brute force in the firewall view. It looked like ordinary login noise until someone pivoted the query from source IP to target username.
Campaigns like that sit in the same threat lane as the credential-driven Snowflake extortion cases and identity-focused operations such as 0ktapus: attackers prefer quiet access over noisy floods. Rising ransomware activity keeps amplifying the payoff. Detection that only watches per-host failure counts will keep missing the campaigns that matter.
What modern guessing campaigns actually look like in your logs
Classic brute force hammers one account from one address with many passwords. Most environments already catch that pattern. Production traffic today mixes three related behaviors that share tooling and objectives:
- Distributed password guessing against a small set of high-value accounts, with source IPs rotated after one or two failures
- Credential stuffing using breached username-password pairs, often paced to stay under rate limits
- Protocol hopping across RDP, SSH, VPN, OWA, and SSO portals against the same identity over hours or days
Large breach datasets, including incidents that put tens of millions of identity records into circulation, feed stuffing pipelines that never need to guess randomly. Your detection program has to treat "wrong password, many sources, same account" as a first-class signal, equal in priority to "many passwords, one source."
Build detections around the account, then add the network context
Start with identity telemetry as the primary index. Network and edge logs supply enrichment after you have a suspect account or time window.
Username-centric failure density
Aggregate failed authentications by normalized username (and by UPN or email alias where your IdP stores both) across all auth surfaces in a rolling window. Practical starting thresholds for interactive human accounts:
- 5 or more distinct source IPs producing failures against one account in 15 minutes
- 12 or more failures against one account in 60 minutes regardless of source count
- Failures against the same account on two or more protocols within 24 hours
Service accounts and shared mailboxes need tighter ceilings. A service account that suddenly receives interactive logon failures from public IPs is already an incident, even at a count of one.
Success after distributed failure
The highest-value alert is often the quietest: a successful authentication for an account that accumulated multi-source failures in the prior window. Wire that as a correlation rule, not a standalone threshold. Include MFA status, device compliance, geo or ASN change, and whether the success arrived from an IP that participated in the failure set.
Password reuse and stuffing fingerprints
Stuffing campaigns reuse the same password across many accounts in a short span from related infrastructure. Detect clusters where one password hash or one cleartext attempt string (where your IdP safely logs attempt metadata) appears against multiple users from overlapping ASN or /24 ranges. Pair that with impossible travel and new-device signals on any success in the cluster.
Edge and host signals that confirm the identity alert
Once an account or window lights up, pull:
- WAF and reverse-proxy auth path hits with elevated 401/403 rates on /login, /adfs, /oauth, and VPN portals
- SSH auth.log or Windows Security 4625/4771 sequences with FailureReason and WorkstationName
- IdP risk scores, impossible travel, and "MFA challenged then abandoned" events
- ASN and residential proxy labels on the source set, without treating reputation alone as the decision
Microsoft's ongoing volume of patched vulnerabilities remains relevant here: exposed RDP, VPN appliances, and identity-adjacent services still expand the guessing surface when patches lag. Close internet-facing auth listeners that do not need public reach before you tune another SIEM rule.
Instrumentation details that make the detections trustworthy
Gaps in collection create false calm. Confirm these fields land in your SIEM or data lake with consistent timestamps:
- Account name in a single normalized form across VPN, AD, Entra ID / Okta, and SaaS apps
- Source IP, ASN, user agent, and client app ID on every failure and success
- Auth protocol and resource (VPN profile, RDP host, API client, SSO app)
- Result code that distinguishes bad password, locked account, disabled account, and MFA failure
- Correlation ID tying multi-step SSO flows so partial successes are visible
Clock skew between VPN concentrators and IdP nodes breaks rolling-window rules. NTP discipline and ingest-time normalization are operational requirements, not niceties.
For high-traffic portals, sample thoughtfully. Dropping auth failures to save license cost removes the only signal that reveals distributed guessing. Prefer selective field reduction over dropping failed-auth events.
Prevention controls that shrink the guessing window
Detection buys time. Prevention reduces how often you need that time.
- Remove public password guessing surfaces. Put admin, RDP, SSH, and VPN behind SSO with phishing-resistant MFA, or restrict by trusted network and brokered access. Password-only portals on the open internet invite automated campaigns.
- Prefer phishing-resistant MFA for privileged and remote access roles. SMS and push-fatigue flows remain weak against operators who already hold a valid password from stuffing or guessing.
- Ban known-breached passwords at reset and periodic check time for privileged and externally reachable accounts.
- Separate service account authentication from human interactive paths. Certificate or managed identity auth removes password guessing as a viable path for those principals.
- Apply adaptive controls at the identity layer: step-up MFA, temporary block on multi-source failure density, and forced recovery for accounts that show success-after-spray patterns.
- Harden internet-facing appliances and keep them within current patch levels. Ransomware crews still chain stolen or guessed VPN credentials with unpatched edge flaws.
Geo and ASN filters help as a reduction layer when your workforce footprint is stable. Use them to raise friction for high-risk regions and bulletproof hosting ASNs against admin paths, then keep username-centric detection as the control that catches distributed residential sources.
Response when the username-centric alert fires
Treat multi-source failure density against one account as an active intrusion attempt until proven otherwise.
- Contain the identity. Disable or force reset the targeted account, revoke refresh tokens and VPN sessions, and invalidate active SSO sessions for that principal.
- Expand the hunt. Search the same window for other accounts hit by the same source set, password, user agent, or ASN cluster. Stuffing rarely stops at one user.
- Check for success. Any successful auth in the window triggers host and cloud triage: new MFA methods, mailbox rules, OAuth grants, remote access tools, and unusual file access.
- Block with precision. Temporary blocks on the participating IP set and ASN slices buy relief. Prefer identity containment first when sources are residential or rapidly rotating.
- Preserve evidence. Export raw auth events, VPN session metadata, and IdP risk details before retention windows rotate. Extortion and ransomware cases increasingly turn on proving when credentials were first abused.
- Close the exposure. If the path was a legacy password portal, schedule its retirement or SSO wrap as part of the incident corrective actions, not as a backlog item.
A practical weekly operations rhythm
Defenders who keep brute force under control run a short, repeatable loop:
- Review top accounts by distinct failing source IPs over 7 days and clear false positives with account owners
- Diff new auth applications and VPN profiles against expected inventory
- Spot-check that failed-auth events still arrive from every edge that terminates credentials
- Retune thresholds after workforce changes, mergers, or new SaaS rollouts that alter baseline failure rates
- Tabletop one "success after distributed failure" scenario with identity, network, and help desk so reset and session-revocation steps stay fast
Takeaways you can implement this sprint
Index brute force detection on the targeted username across all auth protocols, then enrich with IP, ASN, and device context. Alert on success that follows multi-source failures. Keep failed-auth telemetry complete enough to support those correlations. Shrink public password surfaces and move privileged access to phishing-resistant MFA. When an alert fires, revoke the identity first, hunt the sibling accounts next, and retire the exposed password path as part of closure.
Distributed guessing will keep blending into normal noise. Teams that follow the account across rotating addresses will see the campaign while the password is still being tried, not after ransomware operators are already inside.
