Reducing false positives from failed password spraying attempts

I’ve started getting a lot of auto-opened investigations from attempts to password spray my VPN. The investigations are always opened as “low” priority, because the attempts fail, but it creates a lot of unnecessary noise in my environment. Any recommendations on how to tune that particular rule?

Depending on your organization ingress map I would suggest to set up alerts if accesses from unexpected countries materialize, and at the same time create a brute force alert with a less noisy threshold

Are you able to block the offending IPs using your firewall? You might be able to use a feed of malicious IPs to block a lot, or make your own feed with a list generated from IDR or other sources.

I have the same problem when a user changes his password, and his VPN session continues to attempt connections, generating false positives. More than 300k logs coming from this issue

What is your process for identifying true positive or false positive?

With InsightConnect you can perform log search query’s. You can have your alerts create a record that is able to be referenced by other workflows.

If you describe your process of knowing how this is true positive or false positive I can probably give you the steps you need within InsightConnect to determine if these are true positive or not, and auto close them out.

For those who might be following the thread and are not aware what InsightConnect is, it is the SOAR solution that is provided by Rapid7.

It is essentially an easy way to perform various automations without needing to be a scripting wizard, but also allowing the flexibility of using scripts for those who are comfortable scripting.