Clientless VPN Portal Brute Forcing

[David_Burton]

Hi all, 

I have an issue with a single/multiple threat actors attempting to brute force or clientless vpn portal. They are switching IP's with each attempt and they occur 3-7 time per hour. They use the most ridiculous dictionaries for user names but regardless, they change periodically and I would like to put a stop to it but am finding it quite difficult. 

Anyone have any advice for blocking these attempts? I've read so very much on this but cannot seem to find a solution for my particular situation. Any help or suggestions would be greatly appreciated. 

Many thanks in advance!

Best, 

DB

[OtakarKlier]

Hello,

How doe the Palo Alto see the traffic? Anything in the Threat logs? If you see something there, you can put policies in place to prevent this. A Zone Protection applied both internal and external (separate policies) might help. However if there is something in the traffic that can be recognized a custom AntiVirus or Vulnerability protection profile could help. Another way would be to send the logs to a SIEM and somehow block the IP's that are attempting to perform this. 

Hope this helps.

[OtakarKlier]

Another thing might be to limit what IP's can access your portal, eg only traffic from the US, however if they are coming from the US this doesnt work. But also drop traffic that match the builtin EDL's and not from friendly nations:

Regards,

[David_Burton]

OtakarKlier,

Thank you for responding... I was actually updating our firewalls over the weekend and had little time to respond.

I am going through the threat logs now to see if there may be anything of interest. Also, creating a custom AntiVirus and Vulnerability protection profile may be the way to go. Let me dig into this over the day and I'll be back with some info which may be helpful. 

Sadly, the rate at which the IP's are changing may prove to be difficult to deal with and this is one of the reasons I decided to create this thread. Again, however, let me dig into this and see what I can discover. 

Thank you so much for your advice my friend!

Best, 

David B.

[OtakarKlier]

Hello,

This one might be a tough one to track down. However setting up the EDL blocks as well as Zone Protection profiles might help. Also might help to send telemetry back to Palo Alto, if they see something they can write something to help block it for everyone.

Regards,

[OtakarKlier]

Hello,

I just found this while looking for something else:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJ2CAK

Maybe worth a try as well.

[David_Burton]

Your advice is much appreciated my friend, I am about to read the KB you linked earlier...

Also, nothing coming up in the threat logs regarding the attempts but I have adopted the tedious task of filtering out the IP's the threat actor is using more than once or twice and adding them to our Explicit IP Drop Policy. I have done this in the past but it seemed hopeless. 

This time, however, the attempts at brute forcing our clientless vpn portal have ceased as of 9/16. I'm hoping I covered most of the actors IP pool but I'm continuing to monitor the situation. I just updated our firewalls and may need to make some changes to send out telemetry data but that's a great suggestion which I will follow through with.

Again, thank you for your time and advice sir.

Best, 

David B. 

[TomYoung]

Hi @David_Burton ,

EDIT:  You clearly said clientless!  You can't disable the portal then.

If you do not need to roll out new GP clients, disabling the portal login page under Network > GlobalProtect > Portals > [edit portal] > General will stop 99% of those attempts.

Like @OtakarKlier , I also limit the countries that can connect to my portal via security policy rule.

Thanks,

Tom

[David_Burton]

@OtakarKlier we have an explicit drop policy and so far we can only block RU. If I had my way about it we would also block the region of China among others. Most of our malicious traffic seemingly originates in Russian for reasons without explanation. Of course, Russia, Iran, and China are our top threats from state sponsored APTs but no traffic from Iran as of yet. 

@TomYoung Thanks for the input!!! That could actually be an option... Disabling the outward facing vpn portal... If the number of individuals who use clentless vpn access is minimal then that may be enough for me to work with to gain approval for blocking it. Ideally, having both would be optimal but it it could prevent initial access from a Threat Actor or APT then I am a supporter!!

So far, no futher brute force attempts on the clientless VPN portal but I am monitoring the situation. And will provide updates, there's always someone knocking on our firewall's door. Lol!

Best, 

David B. 

[OtakarKlier]

Hello,

Interesting that the powers at be not allowing more blocking, etc. Maybe a SIEM alert for some of the following:

• Impossible travel, a user logs in from say the US and Africa within like a few hours
• An authentication failure followed by success from the same country/region
• Different patterns, say a user usually logs in from Dallas, but all of a sudden logs in from another city
  • Yes there could be false positives, but still worth an investigation

Things of this nature. I'm sure there are more that I didnt list that others are doing as well.

Regards,

[David_Burton]

@OtakarKlier

Agreed!!! Each of those points make perfect sense and I only wish we had that ability...

And fun fact: The threat actor(s) have started up again... Same ip hopping per login attempt and still only using 5-7 user names. Recon is one thing, but at this point, the threat actor likely knows what hardware we are using and seems to be making no further attempts to improve his odds at actually running a successful brute forcing campaign. It doesn't make one bit of sense at this point...

The biggest issue I've discovered when it comes to this/these types of threat actors which are using simplistic "brute forcing" methods. Almost on a "script kiddie" level taking me back to the days. of "NetBrute" if you will, but I digress

The thing is, PAN-OS allows for you to block authentication attempts via user name but ONLY when using LDAP. You cannot simply add a user name to an explicit ip drop (or other policy) that does not exist within your AD environment. Of course, you COULD create that user within your OU but noone wishes to create users accounts in AD such as sslvpn, admin, root, or testuser simply for the purposes of having the ability to block access attempts from individuals using these usernames. 

Not to mention the additional security issues that are accompanied by doing such. But let us just say that if I could drop ip's explicitly and block them based on the user name that was used in the portal then problem solved!!! Why has Palo Alto refrained from incorporating such a feature?? 🤔

DB

[David_Burton]

This is what I'm talking about... Occasionally, there will be a "new" username that is used but for the most part they are repetitive. 

Again, for purposes of recon...maybe, or testing our respone to such an "attack", but really seems pointless from the threat actor's point of view.\

[stevemg7]

I have the same problem as David but I already have the portal/gateway only allowing US and the portal/clientless vpn functionality is disabled.  Each attempt has a different IP and different username and they come in at the rate of 1 attempt/minute.  Sometimes it lasts for an hour or sometimes many hours and I get hundreds of "authentication failed" emails.  We're using SSO with 2FA but the attempts continue to happen.  What I discovered recently is that in the monitor logs of global protect is the "version" column and all of these attempts say "browser" which makes me believe that it's trying to use the clientless vpn even though the portal logon page is disabled and clientless vpn is not enabled-how can that be the case???  I have a whole slew of EDL block lists and they fly right by that and the only unique thing about all of them is the host name of "mypc".  From what I can tell the HIP info isn't collected until after a successful login I cannot do anything with it....

[David_Burton]

@stevemg7
Sorry to hear that you are having the same issue... I know just how frustrating it can be, even more interesting is that the clientless vpn portal has been disabled but the traffic continues. One thing I have done in order to minimize there attempts is to modify your authentication profile. If the actor(s) are making an attempt every second then you could setup your criteria to block a user name after "x" failed attempts for "yy" minutes. I believe we chose 7 login attempts before the user is blocked for YY minutes. May drop it to 6... If a user ends up blocked you can easily unblock them with a single click. 

Now, since your clientless vpn portal has been deactivated I'm unsure how this would work. If the brute force attempts are still occurring and you're seeing failed authentication via your RADIUS server in your GP/System logs you may still be able to leverage this method to aid in this uphill battle. 

Let me know if you are able to completely stop these attempts, I would LOVE to know how you did it. Lol!

Best, 

DB

[TilRando]

I am seeing the exactly the same thing. Though the attacks in my case are directed explicity at my gateways. I could look at region blocking with policies but the attacks are distributed globally. They are low and slow even with the KB mentioned here, in order to be effective would more likely impact users than deter this.