THREAT-VPN-CredentialStuffing Sumo Logic CSE · Sumo

Detect VPN and Remote Access Credential Stuffing / Brute Force in Sumo Logic CSE

Credential stuffing and brute force against VPN and remote access gateways is a persistent initial access vector for ransomware operators and nation-state actors. NCSC and CISA have repeatedly warned about Fortinet, Cisco ASA/FTD, Ivanti Connect Secure, Palo Alto GlobalProtect, and SonicWall VPN gateways being targeted. Attackers use credential databases from prior breaches and automated tools to test credentials at scale against VPN login portals. Unlike password spraying against M365, VPN credential stuffing often targets a single account at high frequency (bypassing account lockout through IP rotation) or uses a large pool of breached credential pairs. Volt Typhoon (China-nexus) specifically targets small business routers and VPN gateways for SOHO Living-off-the-Land access. Compromised VPN access gives attackers direct network access, bypassing perimeter defences entirely.

MITRE ATT&CK

Tactic
Credential Access Initial Access

Sumo Detection Query

Sumo Logic CSE (Sumo)
sql
// Alert 1: High-volume VPN authentication failures
(_sourceCategory="network/vpn" OR _sourceCategory="firewall/fortigate" OR _sourceCategory="firewall/cisco/asa" OR _sourceCategory="firewall/cisco/ftd" OR _sourceCategory="firewall/paloalto" OR _sourceCategory="firewall/sonicwall" OR _sourceCategory="vpn/ivanti" OR _sourceCategory="firewall/juniper")
| where (action in ("failure","failed","denied","rejected") or (type in ("vpn","ssl-vpn","ipsec","remote-access","auth")))
| where !(action in ("success","established","connected","authenticated"))
| timeslice 15m
| stats count as FailureCount, dcount(user) as UniqueUsers, dcount(src_ip) as UniqueSourceIPs, values(user) as TargetedUsers by dest_ip, _timeslice
| where FailureCount >= 20 or UniqueUsers >= 5
| if (FailureCount >= 100, "CRITICAL", if (FailureCount >= 50, "HIGH", "MEDIUM")) as Severity
| fields _timeslice, dest_ip, FailureCount, UniqueUsers, UniqueSourceIPs, TargetedUsers, Severity
| sort by FailureCount desc

// Alert 2: Successful VPN login from IP with prior failures
// Step 1 — collect failing IPs (run as subquery or scheduled lookup)
// (_sourceCategory="network/vpn" OR _sourceCategory="firewall/*")
// | where action in ("failure","failed","denied","rejected") and type in ("vpn","ssl-vpn","remote-access")
// | stats count as Failures by src_ip | where Failures >= 10
// Step 2 — join successes against that list
(_sourceCategory="network/vpn" OR _sourceCategory="firewall/fortigate" OR _sourceCategory="firewall/cisco/asa" OR _sourceCategory="firewall/paloalto" OR _sourceCategory="firewall/sonicwall" OR _sourceCategory="vpn/ivanti")
| where action in ("success","established","connected","authenticated") and type in ("vpn","ssl-vpn","remote-access")
| lookup Failures from path://"/shared/VPN_FailingIPs" on src_ip
| where Failures >= 10
| fields _messageTime, src_ip, user, dest_ip, action, type, Failures
| concat("CRITICAL") as Severity
high severity high confidence

Two-part detection for VPN credential stuffing in Sumo Logic. Part 1 aggregates authentication failures per destination device over 15-minute windows and alerts on high failure counts or many unique targeted users. Part 2 cross-references successful VPN logins against IPs that previously generated 10+ failures.

Data Sources

Fortinet FortiGateCisco ASACisco FTDPalo Alto NetworksSonicWallIvanti Connect SecureJuniper Networks

Required Tables

network/vpnfirewall/fortigatefirewall/cisco/asafirewall/cisco/ftdfirewall/paloaltofirewall/sonicwallvpn/ivantifirewall/juniper

False Positives & Tuning

  • Automated VPN reconnection loops from mobile devices with unstable connectivity
  • Large-scale password resets causing waves of authentication failures across the user base
  • Vulnerability scanners or network health monitors probing VPN endpoints
  • Branch office routers performing scheduled VPN tunnel renegotiations that briefly appear as failures
  • Outsourced IT or MSP teams authenticating from shared IP ranges that trigger volume thresholds

Other platforms for THREAT-VPN-CredentialStuffing


Testing Methodology

Validate this detection against 1 adversary technique from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1VPN Credential Stuffing Simulation via Python Requests

    Expected signal: VPN authentication logs record multiple failures (error: invalid credentials) for multiple usernames from the test IP within the 15-minute window.


Response Playbook

Triage

  1. Identify the source IP(s) of the credential stuffing. Check AbuseIPDB, Shodan, and VirusTotal for IP reputation. Stuffing typically originates from VPS hosts, botnets, or residential proxies.
  2. For successful VPN authentications following stuffing: immediately identify the account and their last legitimate authentication. When did they last successfully VPN in? From where? Has their device changed?
  3. Verify with the user: contact them via phone or secondary communication channel to confirm whether they initiated the VPN session.
  4. If VPN access is confirmed as unauthorised: immediately terminate the VPN session, disable the account, and assess what the attacker accessed during the session.
  5. Review VPN session logs for the compromised account: which resources did they access? Did they attempt lateral movement? Did they download or access sensitive files?

Containment

  1. Block the stuffing source IP(s) at the perimeter firewall and in the VPN gateway IP blacklist.
  2. For accounts with successful authentication from stuffing IP: terminate active sessions, disable account, reset password, require MFA re-enrollment.
  3. Implement VPN geo-blocking if your workforce is geographically concentrated — block VPN connections from countries where you have no employees.
  4. Deploy multi-factor authentication on the VPN if not already implemented — credential stuffing is ineffective against VPN MFA.
  5. Consider implementing client certificate authentication for VPN as an additional factor — certificates cannot be stuffed.
  6. Apply temporary IP rate limiting on the VPN login endpoint to slow credential stuffing operations.

Evidence Collection

  1. VPN authentication logs: all failure/success events for the incident window, including usernames and source IPs
  2. VPN session logs: resource access, traffic volume, duration for successful sessions from stuffing IPs
  3. Network flow logs from authenticated VPN session: lateral movement attempts, scanning activity
  4. Threat intelligence lookups for source IPs

Escalation Criteria

  • !Successful VPN authentication from a credential-stuffed IP — immediate incident declaration
  • !Post-VPN-access lateral movement indicators (net use, SMB connections to file servers, RDP to internal hosts)
  • !VPN access to domain controllers or sensitive server segments
  • !Data transfer volume significantly above baseline during the suspicious VPN session

Investigation Guide

Related Techniques

Forensic Artifacts

  • >VPN authentication logs with timestamps, usernames, source IPs, and success/failure
  • >VPN session records: connected IP, session duration, traffic volume
  • >RADIUS/LDAP authentication logs if VPN authentication is federated
  • >Network flow logs from VPN-to-internal-network segment during suspicious session

Tuning Guidance

VPN credential stuffing thresholds depend heavily on your environment. For small organisations with few remote users, even 5 failures from a single source in 15 minutes may be anomalous. For large organisations with many remote workers, failure rates may be higher due to legitimate connection issues. The most actionable signal is the success-after-failure detection — tune the failure prerequisite threshold down for high-security environments (as low as 5 failures) since a successful authentication following any unusual failure pattern warrants investigation. Also consider alerting on VPN logins outside business hours for accounts that have never historically accessed VPN at those times.


Hunting Queries

Hunt for IPs with both high failure rates and at least one success against VPN authentication — the credential stuffing to compromise pattern across any time window.

Hunting — KQL
kql
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor has_any ("Fortinet", "Cisco", "Palo Alto", "SonicWall", "Ivanti")
| where Activity has_any ("vpn", "ssl-vpn", "remote-access")
| summarize
    TotalAttempts=count(),
    Failures=countif(Message has_any ("fail", "invalid", "reject")),
    Successes=countif(Message has_any ("success", "connected", "established"))
  by SourceIP, bin(TimeGenerated, 1d)
| where Failures >= 10 and Successes >= 1
| extend SuccessAfterFailure = (Successes >= 1 and Failures >= 10)
| sort by Failures desc
Hunting — SPL
spl
index=network sourcetype IN ("fortigate:vpn","cisco:asa","panos:traffic")
  (action="failure" OR action="success") type="vpn"
| eval result=if(action="success", "success", "failure")
| bin _time span=1d
| stats sum(eval(if(result="failure",1,0))) AS Failures,
        sum(eval(if(result="success",1,0))) AS Successes
  BY src_ip, _time
| where Failures >= 10 AND Successes >= 1
| sort - Failures

Atomic Red Team Tests

Test 1 VPN Credential Stuffing Simulation via Python Requests
linux

Simulates a credential stuffing attack against a VPN web portal by iterating through a list of username/password pairs. This tests detection of high-volume authentication failures from a single source.

Command

bash
python3 -c "
import requests, time
creds = [('[email protected]','password123'),('[email protected]','Spring2025!'),
         ('[email protected]','Admin123!'),('[email protected]','Welcome1!')]
for user, pwd in creds * 5:
    r = requests.post('https://<VPN_PORTAL>/login', data={'username':user,'password':pwd}, verify=False)
    print(f'{user}: {r.status_code}')
    time.sleep(1)
"

Expected Telemetry

VPN authentication logs record multiple failures (error: invalid credentials) for multiple usernames from the test IP within the 15-minute window.

Expected Detection

Alert fires when FailureCount >= 20 or UniqueUsers >= 5 within the 15-minute aggregation window.

Related Detections