Most brute force programs still measure progress by how well Active Directory or the IdP lockout policy behaves. Attackers already moved. They hammer ScreenConnect listeners, NetScaler gateways, RDP web clients, and jump-host SSH long before a domain account ever sees a failed logon event that your SOC trusts.
That gap shows up every patch week. When NetScaler zero days such as CVE-2026-88771 and CVE-2026-88772 hit public advisories, probe traffic against gateway auth jumps within hours. When ScreenConnect clients show up in abuse reporting on the same day as an ISC Stormcast brief, operators who only watch Windows Security Event 4625 miss the campaign that is already guessing passwords on the remote support plane. Directory lockout stays quiet. The edge does not.
Why directory-first detection keeps failing defenders
Identity platforms give you one cohesive failure counter. Remote access stacks give you five incomplete ones. Each appliance ships its own attempt window, its own source IP key, and its own idea of what counts as a lock. Password spray that rotates across VPN, RDP Gateway, and a remote support portal never trips any single threshold hard enough to page anyone.
Helpdesk pressure makes the problem worse. Teams raise AD lockout values to cut ticket volume after legitimate users hit the same Wi-Fi NAT. Those higher thresholds then apply only to the directory path. Edge appliances keep the vendor defaults, or worse, keep unlimited attempts behind a TLS listener that never forwards failures into your SIEM with a stable username field.
Breach timing compounds the miss. A student loan incident that exposes millions of records puts fresh username and password pairs into circulation within a day. Stuffing against a portal looks like a handful of successes, not a wall of failures. If your only brute force rule is "N failures in M minutes," valid pairs from the dump sail through while your dashboard reports a calm auth graph.
AI-assisted guessing changes the shape again. Microsoft has warned that threat actors are moving faster with early AI tooling. That shows up as higher password diversity per account at a pace that still sits under classic volume caps. Keyboard walks, breach-variant mutations, and seasonal password templates arrive as slow, varied attempts from residential or cloud exits. Volume detectors stay green. Account takeover still happens.
What a useful signal looks like in production
Treat brute force as a cross-surface identity problem. One username tried against two or more remote access products in a single shift is a stronger campaign indicator than fifty failures against one RDP host. Build the ledger around the account and the auth surface, then attach source infrastructure as secondary context.
Minimum fields every auth path must emit
- Normalized username (UPN or DOMAIN\user, lowercased, stripped of alternate suffixes)
- Auth surface label (netscaler_gateway, screenconnect, rdp_gateway, ssh_bastion, entra_interactive)
- Outcome (fail, success, mfa_challenge, lockout, password_expired)
- Source IP plus ASN and whether the path used a known corporate egress
- Client fingerprint when available (User-Agent, TLS JA3/JA4, RDP cookie, ScreenConnect client ID)
- Timestamp in UTC with the appliance clock offset documented
If ScreenConnect or NetScaler logs land as free text without a parsed user field, fix parsing before you tune thresholds. A detector that cannot join on identity will keep firing on scanner noise and missing targeted guessing.
Detection logic that survives IP rotation
- Count distinct password-failure events per username per surface over 15 minutes, 2 hours, and 24 hours.
- Flag any username that accumulates failures on two or more surfaces inside four hours.
- Flag any username with failure diversity above a set edit-distance or variant threshold even when volume stays low.
- Elevate priority when a failure trail on an edge gateway is followed by a success on a different surface within the same day.
- Separate corporate ASN and ZTNA egress from residential, hosting, and Tor exits so legitimate travel and VPN hairpins do not drown the queue.
That last success-after-multi-surface-fail pattern is where real takeovers hide. Spray tools map which products accept the same directory password. Once they find a soft surface, they stop failing loudly on the hard one.
A one-week playbook you can run without a new platform
Day 1: Inventory the guessing surfaces
List every path that accepts a directory password or a local appliance account. Include forgotten ones: secondary ScreenConnect instances left after an MSP onboarding, NetScaler Gateway themes still published after a migration, RDP Gateway on a DR subnet, and SSH on cloud jump boxes that still trust password auth. For each surface, write down the log source, the field that holds the username, and whether lockout exists at all.
Day 2: Normalize and forward
Push those events into one index or table with the minimum fields above. Use a short lookup so jsmith, [email protected], and CONTOSO\jsmith collapse to one identity key. Confirm a test failure on each surface appears in the joined view within five minutes.
Day 3: Stand up three high-signal rules
- Cross-surface spray: same identity, failures on ≥2 remote access products in 4 hours.
- Edge-only hammering: ≥20 failures on NetScaler or ScreenConnect for one identity while AD 4625 count for that identity stays near zero.
- Fail-then-shift success: failures on surface A, success on surface B within 12 hours, especially from a new ASN.
Page on the third rule. Ticket the first two into the identity hunt queue with a four-hour SLA.
Day 4: Bind response to the surface that yielded
When a rule fires, disable or step-up the account at the IdP, then revoke sessions on every remote access product that shares that directory. Resetting only the AD password while an RDP Gateway or ScreenConnect session cookie remains valid leaves the attacker inside. Pair this with a quick check for GPO and privileged group changes. PAYLOAD-style ransomware that hijacks Group Policy often arrives after the first durable remote foothold, so treat a confirmed auth compromise as the start of a staging hunt, not the end of an identity ticket.
Day 5: Align lockout and MFA to the real yield order
Rank surfaces by how often guessing produces a usable session in your environment. Put stricter attempt caps and phishing-resistant MFA on the highest-yield paths first. Remote support and edge VPN almost always outrank the main webmail form. Keep helpdesk unlock workflows tied to verified out-of-band identity so attackers cannot use lockout itself as an account enumeration oracle.
Concrete scenario
Overnight, NetScaler Gateway logs show 8 to 12 failures each for 40 service accounts from three hosting ASNs. AD lockout reports nothing because those attempts never reach a domain controller in a form your SIEM rule understands. At 07:10 a ScreenConnect login succeeds for one of those service accounts from a fourth ASN. Your volume-based AD rule stays silent. A cross-surface ledger marks the account at 07:11, revokes the remote support session, forces a password and MFA reset, and opens a hunt for lateral use of that service account against admin shares and GPO edit rights.
The same pattern appears after large consumer and education breaches. Fresh pairs get tried first against whatever remote access product still permits password auth without device compliance. Your portal rate limit can look healthy while the support gateway absorbs the real guessing yield.
Controls that pair with detection
- Disable password auth on SSH bastions and remote support where certificate or SSO is available.
- Require compliant device plus phishing-resistant MFA on VPN and RDP Gateway for privileged roles.
- Keep separate, lower attempt thresholds on appliance-local accounts that are not covered by IdP smart lockout.
- Feed threat intel on exploited edge CVEs into a temporary tighter auth window on the affected product, not into a generic IP deny list alone.
- After ransomware staging alerts tied to GPO modification, replay the prior 48 hours of edge auth for the same operators and service accounts.
Takeaways for the next standup
Move primary brute force telemetry to every product that accepts a password at the edge, normalize usernames across those products, and alert on cross-surface failure and fail-then-shift success. Retune directory lockout only after those sensors exist. When the next NetScaler advisory or ScreenConnect abuse wave lands, you will already be watching the paths attackers actually guess against, with a response that cuts sessions everywhere the password still works.
