IT Toolbox
Procedure

Respond to fraudulent connection attempts on a VPN

Respond to VPN brute-force or password-spraying attempts by preserving logs, searching for successful sign-ins, protecting accounts, limiting attempts, requiring MFA, reducing exposure, and monitoring for recurrence.

Cybersecurity

Objective

Contain fraudulent VPN authentication attempts and determine whether any login succeeded, rather than relying only on IP blocking, then harden remote access with MFA, appropriate lockout controls, reduced exposure, least privilege, and monitoring.

Prerequisites

  • VPN logs containing time, source IP, username, result, and authentication method.
  • Administrative access to the firewall/VPN, directory service, and MFA platform.
  • The list of targeted accounts, active accounts, and users authorized for VPN access.
  • A fast way to contact users whose successful login appears unusual.
  • A configuration backup before hardening the VPN.

Step-by-step procedure

1

Preserve logs and normalize timestamps

Export VPN logs before rotation and preserve the time zone. Group attempts by account and source IP, then distinguish brute force against one account from password spraying across many accounts. Keep the raw logs as evidence in addition to any summary.

Expected result
  • The campaign is quantified by time period, source, and targeted accounts.
2

Check successful authentications first

For each targeted account, search for successful logins during and after the campaign. Compare source IP, location, time, device, and MFA evidence with normal behavior. An unexplained success should trigger account-compromise handling, including session revocation and investigation of subsequent activity.

Expected result
  • Every successful login in the incident window is explained or handled as a compromise.
3

Review nonexistent, disabled, and privileged accounts

Identify attempted usernames that map to administrators, former employees, service accounts, or nonexistent identities. Disable unused accounts and remove VPN rights where they are not required. Enumeration of invalid usernames can reveal a separate reconnaissance phase.

Expected result
  • Unused identities are removed from the VPN attack surface and privileged targets are reviewed.
4

Temporarily block the most aggressive sources

Block the highest-volume malicious sources for a limited period when that reduces operational noise, but treat the block as containment rather than remediation. Document the reason and expiry so temporary deny rules do not accumulate indefinitely.

Expected result
  • The highest-volume abusive sources are contained without creating a permanent unmanaged rule set.
5

Configure login-attempt limiting

Use the VPN platform controls to limit repeated failures and apply a temporary lockout that fits legitimate user behavior. Start with documented values, monitor support impact, and avoid settings that allow a simple denial-of-service attack against known usernames.

config vpn ssl settings
    set login-attempt-limit 2
    set login-block-time 60
end
show vpn ssl settings
Expected result
  • Repeated bad-password bursts trigger a controlled temporary block.
6

Require MFA for every human VPN user

Verify that no unjustified exception allows password-only VPN access for a human account. Use a dedicated mechanism for technical accounts instead of bypassing MFA on the user portal. Test recovery and token-revocation procedures as part of the change.

Expected result
  • No human VPN access depends on a password alone.
7

Reduce portal exposure

Limit the VPN service to the interfaces and source ranges that are genuinely required. Use local-in policies, geographic restrictions, or other supported controls where appropriate, and disable unused web-portal features. A nonstandard port may reduce background noise but is not a security control by itself.

Expected result
  • The portal is exposed only to the required access perimeter.
8

Harden post-authentication groups and policies

A successful VPN login should not provide broad network access. Map VPN groups to the minimum required resources, segment profiles, log connections, and verify pushed routes and DNS settings. Least privilege limits the impact if an account is compromised.

Expected result
  • VPN users can reach only the resources required for their role.
9

Create alerts for meaningful attack patterns

Alert on high failure counts, a success after repeated failures, a login from a new region, attempts against disabled or privileged accounts, and VPN configuration changes. Tune thresholds against normal traffic so alerts remain actionable.

Expected result
  • New campaigns and suspicious successful logins are detected quickly.
10

Close and document the incident

Record the timeline, targeted accounts, source addresses, validated successful logins, containment measures, and configuration changes. Remove temporary blocks when their planned lifetime ends. State explicitly whether compromise was confirmed rather than claiming that IP blocking alone resolved the incident.

Expected result
  • The report clearly separates attempts, validated successes, any confirmed compromise, and preventive actions.

Validation

The procedure is validated when:

  • No suspicious successful VPN login remains unexplained.
  • Every human VPN user is protected by effective MFA.
  • Repeated failures trigger an appropriate rate limit or temporary block.
  • Portal exposure and post-authentication policies are limited to business need.
  • New attack campaigns and successes after failures generate actionable alerts.

Rollback

  • Remove a source or geographic block if it affects a legitimate user, using a targeted exception rather than reopening access globally.
  • Restore previous login-attempt limits if the new values cause excessive legitimate lockouts.
  • Do not disable MFA to restore one user quickly; repair the authentication method or use the approved recovery process.

Troubleshooting / common errors

  • If alerts are too noisy, tune thresholds without suppressing successful logins after repeated failures.
  • If MFA enrollment blocks a user, use the documented recovery process rather than creating a password-only exception.
  • If geographic filtering causes business impact, scope an exception to the smallest justified source or user group.
♡ 0