Brute-forcing passwords for VPN access has become a standard technique for various actors to access corporate networks to exfiltrate data later or deploy ransomware. After identifying the VPN, an attacker may use simple brute forcing, credential stuffing, or social engineering in some very public cases to obtain access.

Today, I noticed in one of my honeypots new "most commonly hit" URLs:

GET /remote/login HTTP/1.1
GET /dana-na/auth/url_default/welcome.cgi HTTP/1.1
GET /global-protect/login.esp HTTP/1.1
GET /vpn/index.html HTTP/1.1

These URLs have one thing in common: They are used by VPN and remote access solutions. The first one is a bit generic, making it difficult to identify the exact product they are looking for.

The second URL, '/dana-na/' appears to be associated with Pulse Connect Security, a VPN solution with a rich history of vulnerabilities in the past. I do not see any exploit attempts as part of these scans, just simple requests for the URL. Some of our handlers suggested Juniper may also use it.

'/global-protect/login.esp' is associated with Palo Alto's Global Protect solution. It also had a few vulnerabilities in the past. 

Finally, '/vpn/index.html' appears to be related to a Netscaler remote access product.

Another interesting property of these scans is that they all originate from 77.105.147.0/24. A different IP address in this subnet scans for each URL; the IPs have not been used before the last couple of days.

Whois data for this network:

role:           Aeza Network
address:        350001, Krasnodar, st. im. Mayakovskogo, b. 160, office 2.4
nic-hdl:        AN32749-RIPE
mnt-by:         aeza-group-mnt
created:        2021-11-24T09:55:02Z
last-modified:  2021-11-24T09:55:02Z
source:         RIPE # Filtered

The scanning IP addresses have no services exposed, but other IPs in this /24 do have simple default web pages. This appears to be typical for a hosting provider like Aeza Networks. It is possible that the originator of these scans compromised or just rented a few servers in this subnet. Low-cost virtual servers offered by providers like Aeza, are always popular as "throw-away" systems to conduct scans like this.

What should you do?

First, ensure your remote access software is up to date. This should not just include these web-based VPN solutions. Include console servers or other remote access methods.

Secondly, use multi-factor authentication. If supported, opt for a phishing-resistant solution. Note that simple one-time passwords like Google Authenticator are not phishing-resistant. A phishing-resistant solution does not allow the user to select the credentials for a particular website. Possible solutions are FIDO2 or Passkeys, which are sadly not much seen yet for these types of remote access systems.

You should probably implement country-based blocking for critical gateways or a limited allow list. But quite often, you will need these VPN gateways to be accessible from dynamic home IPs, and country-based block lists are not only hard to get right, but they are simple to bypass. Blocking 77.105.147.0/24 may be a good start :)

And a bit of "security through obscurity" can help: Try to run these gateways on an unusual port.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|