8lz1q (8lz1q) asked a question.
We are experiencing multiple user lockouts from geographically diverse locations. The attacks are coming through Office 365, where we utilize Okta to authenticate.
We have offices or users in the US, Europe and India to name a few. Restricting by country unfortunately will not be completely within bounds because **some** of the attacks are coming from countries where we do have a presence or where users are traveling. Blacklisting specific IP addresses is not optional because the list is rapidly changing (we tried).
Multifactor is turned on, however you must enter credentials BEFORE you a solicited for a second factor which is an ENORMOUS problem and so we are being brute-forced into powerlessness.
I’ve disabled SMTP authentication (via Powershell and O365 GUI) for some of the affected users as a test, however this has not slowed the attacks. I opened a case with Microsoft and I specifically asked them (three times) is there a way to turn off web authentication, REST API (thinking that should arrest this issue) but that question has not been answered.
Microsoft’s provided solution is to enable their Premium Azure security feature for the entire tenant, which they state may not be effective because “Opting for Azure Conditional Access may also not be a 100% full proof plan…”
In terms of Okta authentication, reversing the MFA order, by making the second factor be the first thing an attacker enters renders the attack ineffective but does expose the factor. This prevents the lockout in Okta and in Active Directory. Adding a “Softlock” to Okta prevents the user from being locked of Active Directory but still renders Okta useless because the user is locked out of all of the functionality we provide under their Okta sign-on.
We are quickly being crippled and I’m reaching out to anyone who has some ideas. I opened a ticket with support a few days ago with Okta and even escalated it. I've been given some guidance but I am not making progress. There must be some intervention that can be inserted that prevents these brute-force attacks that I’m not seeing.
Hi Waverly- I see the case you submitted has been resolved- please let us know if there are any remaining issues and we'll escalate for you
You may want to check with end user first. This case was not resolved.
Previously, when looking at the logs you would see the attacks coming from multiple countries. Now, they primarily show from the United States. However, if you look at the IP chain, you will see numerous request from multiple countries.
outcome.result eq "FAILURE" and outcome.reason eq "INVALID_CREDENTIALS"
using the above query for the logs
When you export the logs, they show show a high use of "unknown" in the fields named "client.user_agent.os" and "client.user_agent.browser ". This should provide a pretty high confidence this is a bad actor attempting to authenticate or wreak havoc. An actual user utilizing an application or a browser is not going to generate high traffic from a mysterious or anonymous application with an unknown agent, routed through multiple countries.
This issue has been ongoing and we really need to find an intervention.
Did you receive an answer to this?
Did you receive an answer to this?
I did not receive an answer, however as I recall it, the day after I made the discovery about the IP chains with the unknown clients and OS, and posted here, the attacks came to almost an abrupt halt. I had been digging through the IP chain and working backwards to see the correlations. I thought the attacker was lulling me into complacency and about to change strategies but that didn't occur. Because there was so much noise (events triggered) and subterfuge, it was hard to determine the damages and effects, since the attack surface was the entire organization.
outcome.result eq "FAILURE"
outcome.result eq "FAILURE" and outcome.reason eq "LOCKED_OUT"
outcome.result eq "FAILURE" and outcome.reason eq "INVALID_CREDENTIALS"
request.ipChain.geographicalContext.country eq "Russia"
What I learned is to utilize the above queries and inspect the IP chains for each failure (that is out of the ordinary). Blacklisting became my number one tool for remediation.
Actually, my first line of defense