the last week someone has been trying to bruteforce a bunch of logins from various ips. we’ve been doing the cat and mouse thing by adding drops for those ips. but they keep hopping around.
im curious if theres any other ways to mitigate this that we havent throught off…
we were thinking of changing our vpn users ids…like adding a prefix or something…OR changing the port that anyconnect runs on.
i’ve got a list of pros and cons for both options. but looking for more solutions
im curious whats to be gained here? its MFA and unless they have a comprimised cell phone they will never get the code. aside from locking out our users and preventing acess its really not causing us any trouble. are they trying to exhaust our sms pool? are they trying to get us to disable SMS?
There could be an element of MFA PUSH bombing… they don’t know you use SMS, so they may be hoping someone eventually pushes accept on an MFA request.
you can use control plane ACLs …but that becomes tedious.
Another thing you can try is creating another Connection Profile that has a URL alias so users connect to (ex. vpn.company.com/aliasname) , then set the DefaultWEBVPNGroup connection profile to use a dummy auth server, and set it to deny access. If you change the profile on the DefaultWEBVPNGroup, and get everyone to reconnect, they’ll get it, and then move other on the next time they reconnect, and as long as the bad guys don’t get connected, they won’t get it…
If you’re using Cloud Managed Anyconnect you can just change the profile there, and users will move over.
Your users are receiving MFA requests via SMS from these login attempts?? If so, that means they have the credentials and the accounts are compromised.
As to your comment about exhausting sms pool, are you actually sending sms messages for these login attempts? That shouldn’t happen unless the attacker knows the correct password. SMS should only follow a correct user/pass combo. In that case, the users password is in the wild and needs to be changed immediately.
Don’t dismiss the SMS threat (SE, SIM Swapping, etc), there is a reason Duo lists it as the least secure auth type. I would highly recommend moving to WebAutnN or verified push at a minimum, if possible.
They may be probing around trying to find a user who doesn’t have 2FA enabled or enrolled. Make sure your Duo new user policy is set to Deny Access and all AnyConnect users are in a group protected by Duo. (You can now also limit how long an account can be left in the new user state before being locked out. E.g after 7 days if the user hasn’t completed enrollment, disable the account)
You can also set the Duo lockout to a number of failed attempts lower than AD, which would lock their Duo account before their AD account. If they’re an on-prem user, this would provide some relief.
This is an attack vector that Cisco warned about last week. We started getting the same attempts right after the announcement. So far I have shunned a couple addresses but it just isn’t worth the time.
Making sure your vpn usernames are not the same as their email address is also a good practice. But using an alternate port is probably a good tactic as well. So far we are just suffering log in delays since this is similar to a DOS attack.
Short term mitigation is going to be tough, long term a zero-trust-like VPN solution that requires registered Device might assist.
Short term options I haven’t seen mentioned here is looking at some sort of Cloudflare/other CDN that will check or restrict prior to hitting VPN edge.
Cisco describes a manual Geo-Fence method using IANA in this bug (need an account to access). Other than that you can Shun the IPs, but it will be a never-ending endeavor.
Change the port for AnyConnect from port 443 to some random port, it’ll eliminate 99.9% of the random brute force attacks.
Aside from MFA fatigue, they may have compromised some of your user devices and they’re trying to find an account that matches the device(s) they compromised so they can intercept MFA.
You could disable push MFA and just use in-line MFA code. The user inputs their password in anyconnect, followed by a comma “,” then the Duo 6 digit MFA code from the app. If you really wanted to get fancy you could issue yubikeys, and they input the comma “,” then touch the yubikey.
It’s a short term fix that doesn’t change user workflow that much.
Check your duo auth proxy logs to see what usernames are being guessed and if they have successfully entered a user password. Your vpn logs should correlate and tell you their ip addresses. Make sure you send these logs to a central log repository and/or siem for easier search and analysis.
A couple of other options are 1) play whack-a-mole and try shunning or blocking their ip addresses as they bounce around to new and exotic locations, or 2) just block everyone by default and only allow the known good users to connect. It helps to have a firewall in front of your current vpn firewall to do this, but cisco has some special rules you can put in place at the control-plane to make this work.
A geo fence won’t really help 100% here since the attackers could just as easy target you from within your country to get around the fence.
Look into a zero trust network access solution and get off of the traditional vpn remote access. Also look at making duo more secure by not using easily phishable authentication methods like sms and phone calls.
Security researcher Aaron Martin told BleepingComputer that the activity observed by Cisco is likely from an undocumented malware botnet he named ‘Brutus.’ The connection is based on the particular targeting scope and attack patterns.
Martin has published a report on the Brutus botnet describing the unusual attack methods that he and analyst Chris Grube observed since March 15. The report notes that the botnet currently relies on 20,000 IP addresses worldwide, spanning various infrastructures from cloud services to residential IPs.
The attacks that Martin observed initially targeted SSLVPN appliances from Fortinet, Palo Alto, SonicWall, and Cisco but have now expanded to also include web apps that use Active Directory for authentication.
Brutus rotates its IPs every six attempts to evade detection and blocking, while it uses very specific non-disclosed usernames that are not available in public data dumps.
This aspect of the attacks raises concerns about how these usernames were obtained and might indicate an undisclosed breach or exploitation of a zero-day vulnerability.
Though the operators of Brutus are unknown, Martin has identified two IPs that have been associated with past activities of APT29 (Midnight Blizzard, NOBELIUM, Cozy Bear), an espionage threat group believed to work for the Russian Foreign Intelligence Service (SVR).