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,

Use country codes to block access from where you know you wont have connections. Example, if your people are located in the US, block everything but the US. Another thing would be to use some form of multi factor auth so that its that much difficult for the bad actors. 

One thing I do is enable telemetry and send it to PAN for research and analysis. This way they can write global indicators and that way everyone with a PAN will get the updates.

Regards,

[TilRando]

I think utilising regions within your policies for hosted services is a really good practise but it does start to become meaningless depending on your org, especially if they operate at a global level in every region. We really need more granularity during the auth stage and within threat ID:40017 and ID:32256 it is only good for fast and hard brute-force attempts. It really needs an additional condition like username and result:success/fail. The only way currently I can see resolving this issue is by utilsing a SIEM solution with a custom Query that when triggered updates an EDL within a block policy.

[stevemg7]

@TilRando i am with you 100%.  I just closed my support case the other day because they were of no help.  We already have it set to US only and the attempts are low and slow meaning about 1 attempt/minute and for each attempt it's a different user and source IP.  We do have 2FA and the web portal disabled but they are still generating logs which trigger an e-mail to me.  I wish PA had a more glandular way to handle this.  There are ways to control things using HIP and other things but that is only after a successful authentication so it's useless to me.  My scenario is that the hostname is always "mypc" which I'd love to be a criteria to be able to block by but that currently does not exist. 

[TilRando]

@stevemg7 wouldn't that be nice if you could stick some regex in there. Just an update for anyone else had a new vector from a different OS client but this was from a single IP but could be new tooling.

[LloydHopes]

We've spotted this problem and I've run through the article here but it still doesn't appear to be blocking the IPs. 

Any suggestions?

Thanks

[TomYoung]

Hi everyone,

I see these now also.  I have my portal turned off.  So, the only authentication attempts I get are with the AppID panos-global-protect to the gateway.  As @stevemg7 said, the hostname is always "mypc."  It could be the same actor, but I think it is a bundled PANW GP script kiddie package.

They rarely try twice from the same IP address.  So, the custom signature block in the article will not work.  In fact, IP blocking probably won't work.

I am only allowing traffic from the US, and I still get lots of attempts.

We've known password hacking for RA VPN has been going on for decades.  We have to allow our users to log in.  I think the #1 task is to use MFA for RA VPN.  Maybe we can find a better way to block regions.

Thanks,

Tom

[qdimclark]

Just chiming in that we are seeing the same things.

While it is nice to know that we're not the only ones, it's not nice that it's happening at all.

Up to 3 attempts per minute.

Switching IPs after one or two attempts.
Version showing Browser
Usernames appear to come from a compiled list.
Clientless VPN and Portal page disabled.
SSO and MFA enabled.

Management won't allow more region blocking than just the usual suspects.

We certainly need a better solution.

[michael.wilson]

I would email the @abuse contact for that block of IPs on the ARIN site.  I would also document internally that you emailed them.  Unfortunately it's the nature of the beast for edge devices....look on the brightside, it's job security either way!