Alert on successfull password login but when MFA fails, and from a suspicious IP/country
under review
T
Thomas Waterhouse
Twice this week I have seen where hackers have gained a users password and the sign in logs in 365 show they tried it and it was successful, but failed to complete MFA so didn't get in. The sign ins were from new IPs, overseas and completely out of character. If the login succeeded we'd likely have received an alert from Huntress about an unusual country login at the least, but we don't seem to when the login didn't complete. Yet we definitely want to know about these ones, this means hackers have the users password even if they didn't actually get into 365 with it, and we still need to change it.
We only knew about the two this week due to 365 itself alerting us through Lighthouse about a risky sign in.
Surely firstly Huntress can see these logins just from the sign in logs and alert us, but secondly does it not monitor the 365 risky sign ins feature? I'd have thought that was easy and essential.
Rich Mozeleski
updated the status to
under review
Rich Mozeleski
Merged in a post:
Alerting for O365 Login Attempts Using Known Compromised Credentials
B
Brandon Szych-Brown
During a recent incident, we observed multiple login attempts from foreign countries using a user's compromised credentials. However, Huntress did not generate any alert because the logins were unsuccessful. While we understand Huntress focuses on alerting only for successful logins to reduce noise, we believe this presents a critical visibility gap and is aiming to be reactive and not so much proactive in compromises which is equally if not more important.
In this case, the password was already compromised, and the attacker was likely attempting to bypass MFA (e.g., via fatigue attacks). Knowing that someone is attempting logins using a valid password regardless of MFA is a strong indicator of credential compromise and warrants at least a low-severity alert or informational escalation.
Being notified in such scenarios could help partners respond before an attacker successfully completes a login and takes further action.
We suggest adding an option to alert on:
- Repeated login attempts from unusual locations using a valid password (even if blocked by MFA)
- Patterns indicating MFA prompt bombing
- Any use of a correct password from suspicious geolocations or out of country logins (Similar to out of country logins for successful logins)
Rich Mozeleski
Merged in a post:
conditional access failures
Walt Shank
We're using SaaS Alerts currently and one alert I would like to see in Huntress is when an account has authenticated with a valid password but fails a conditional access policy that otherwise blocks the sign-in. This is common when a user submits creds to a phishing message but the threatactor attempts to sign-in from a unauthorized location. The account is still considered compromised thus requiring remediation.
T
Thomas Waterhouse
Just want to bump this once again. Just had a lighthouse/365 alert email come in for a risky user, 3 days after it happened! got to love MS. Nothing from Huntress.
There were multiple logins with successful password but blocked by MFA, from different countries, they were obviously trying VPNs to see if they could avoid the MFA prompt.
While problematic if Huntress alerted on every password success but MFA failure (users would do it all the time), Huntress should detect a overseas login even if only the password was right and MFA failed. Surely this can't be hard to do at all. And we see it quite often, but 365's own alerts are so delayed and unreliable it is a big risk.
C
Chris Bareham
+5 -- This is something we currently report monthly to one of our customers. They have their IdP locked down pretty good now, but they want to know if/when a user successfully logs in outside of one of a few states (where they have offices) but with failed MFA.
Autopilot
Merged in a post:
Alert on Successful Password Entry (MFA Failed)
Y
Yidel Steinfeld
We would expect an alert for suspicious login attempts where the password succeeds, but the sign-in is halted by MFA.
Problem: Current alerts fire only on successful sign-ins.
Need: Successfully providing a password means a valid credential pair (UN/PW) is compromised, necessitating password rotation, even if MFA blocked the access.
Actual Example: A login attempt for an identity from an unusual location using an "axios" user agent provided the correct password but failed due to MFA not being completed. There was no alert/investigation.
E
Eyal Gallico
Great idea, might add maybe after the second MFA entry to get an alert, just in case its the user that made a mistakeentry
J
Josh OMealey
Eyal Gallico, yes, ideally a threshold of 2 or 3 failures before an alert, or a way to choose how many failures before you are alerted.
Y
Yidel Steinfeld
Josh OMealey
In my example, the sign in itself had malicious indicators based on agent/IP, so it's more than just an MFA failure.
J
Josh OMealey
Yidel Steinfeld, yes being notified right away for that scenario would be great.
Troy Gerrie
I was a bit disappointed to find that this wasn't a think with Huntress as we otherwise have full trust in the system.
I would flag that this should be for any failure, not just MFA. We are seeing instances whereby a compromised password is being tested but blocked by a geo blocking CA policy.
Our security provider should be able to tell us these credentials have been compromised.
Another suggestion is to ingest the risky user information from Microsoft 365
M
Mathisen Bjã¸rn
The system wouldn't even need to alert immedately, but could correlate it with other markers. If a completely new IP subnet / location is being used, then a successful password use followed by a failing MFA attempt should be more likely to trigger an escalation.
Autopilot
Merged in a post:
Alert on Successful Login with Password and MFA but blocked by Conditional Access Policy
T
Tim Bixley
Currently if credentials have been compromised and logins are attempted but are stopped by a conditional access policy, Huntress does not use this as an indication of an issue. eg, Token theft or token replay attack.
I treat these as a breached account, even though they couldn't get data, it's only a matter of time before they work around the conditiona ccess policy logic.
Early response to this indication of compromised credentials is essential.
Load More
→