Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

Impossible travel alerts on failed logins

Copper Contributor

I am picking up impossible alerts that are not relevant. I have specified successful logins only for the Impossible Travel policy but it still alerting on what seems like failed logins. It is also displaying all the failed logins on the details.

My goal is to use flow and email the user to the activity and if they are unaware of the travel they can contact support. The issue is that it is reporting all the impossible travel in the details of failed logins which will only confuse the user.

Is there a way to only report successful events for Impossible Travel policy?

 

EXAMPLE DETAILS OF EVENT - These are all failed logins outside the US though.

The user was active from 210.217.32.25 in Korea and 8.41.93.10 in United States within 270 minutes.
The user was active from 85.175.226.82 in Russia and 8.41.93.10 in United States within 382 minutes.
The user was active from 182.71.16.42 in India and 8.41.93.10 in United States within 686 minutes.
The user was active from 222.223.41.92 in China and 8.41.93.10 in United States within 690 minutes.
The user was active from 210.217.32.25 in Korea and 2600:387:9:5::b6 in Puerto Rico within 317 minutes.
The user was active from 8.41.93.10 in United States and 2600:387:9:5::b6 in Puerto Rico within 46 minutes.
The user was active from 182.71.16.42 in India and 2600:387:9:5::b6 in Puerto Rico within 732 minutes.
The user was active from 222.223.41.92 in China and 2600:387:9:5::b6 in Puerto Rico within 736 minutes.
The user was active from 85.175.226.82 in Russia and 2600:387:9:5::b6 in Puerto Rico within 429 minutes.
The user was active from 2600:387:9:5::b6 in Puerto Rico and 201.140.110.78 in Mexico within 35 minutes.
The user was active from 210.217.32.25 in Korea and 201.140.110.78 in Mexico within 353 minutes.
The user was active from 182.71.16.42 in India and 201.140.110.78 in Mexico within 768 minutes.
The user was active from 222.223.41.92 in China and 201.140.110.78 in Mexico within 772 minutes.
The user was active from 85.175.226.82 in Russia and 201.140.110.78 in Mexico within 465 minutes. 

17 Replies

@Tim Settar 

 

Just to make sure I'm properly tracking your question, you want to be able to filter not just for impossible travel events but also only when those impossible travel events lead to a successful logon?  Is that correct?

Correct. 

 

Ultimately I am trying to find a way to automate some of the user alerts to email them suspicious activity and give them the option to go change their password. The alerts need to be digestible and understood by them though. If they are traveling and access email on their phone and then get into RDS or VPN.. boom! impossible travel. The Impossible Travel alerts description also includes all those failed login locations.

For accounts that we know have been compromised based on some criteria, I see an automated flow that logs them out of all apps, resets their password and then text them that password to their MFA phone number. I know I'm dreaming but one day we will get there.

 

Thanks for taking the time to get back to me!

@Tim Settar 

 

We have been experiencing the same issue with impossible travel alert,  I wonder if you managed to find out a solution for this issue which you can share with the community.

 

Many thanks in advance,

 

@jvaidya No, I never did. Our new security team has taken over management so I'm no longer working on it.

@Tim Settar 

 

Thanks for sharing the feedback, much apprecited!

I know this topic is about a year old but it's still an ongoing problem with our tenant.

 

 

Because the alert is a built in anomaly alert, we can't tune it to avoid this.  Due to the size of our tenant  and (faculty, students, alumni), I can see nearly 200 of these alerts open and almost every one of them is the result of a successful, legitimate, login in the US followed by a failed login elsewhere.

 

If any malicious actor wishes to overwhelm a security team with alerts, they could easily just begin generating failed logins from around the world.

 

Please tune the alert (or allow users to tune the alert) to exclude failed logins. Other than tracking possible brute force attempts there is zero useful intelligence gained from knowing there was a failed login at an impossible travel distance.

@jvalente 

 

We are having the same issue.  The Alert is not useful at all because 99% of the time it is a failed login.  So after a while you start to ignore what could be a very useful and important alert.

 

Any help Microsoft guru type people?

 

Paul

We have started receiving Impossible Travel alerts for AT&T via Puerto Rico for people using email on their AT&T mobile devices while located in Florida and Illinois. The IP comes through as 

2600:387:9:5::c4, (matched the OP), because I have verified with the users and now know that this is legitimate work being done, I am likely going to alter the policy to known IP addresses.

This really doesn't solve the problem, just masks getting the error from reporting. The real issue is why is AT&T is saying this traffic is from PR.

@James Jones We had the same issue. Seems to be with AT&T IPv6 routing.

Are we asking this question in the wrong place?  This question has been sitting here since May with no response other than others having a different issue.  Meanwhile I am still getting a bunch of impossible travel alerts from failed logins that aren't helpful because they are masking the real events that I should be paying attention to.

 

I have it set to text me when I get one of these alerts which is wonderful when I know that it is actually a successful login but I now just ignore these texts because there is so much to sift through.

 

Can we get any help here?  Surely there is a way to change these options.

 

Thanks,

 

Paul 

I can confirm this is still an issue. 

Hey Paul,

I should have updated on this but that got overlooked. I am now wondering if the solution is licensing related, and the inaction by MS is intentional to annoy users into paying for a higher tier. Over the summer we went from A3 to A5 licensing (Not sure what those are in non-educational plans) and one thing I found is that I suddenly *do* have the ability to tune the policy triggering the alert. Under advanced configuration there's "Analyze sign-in activities" and it can be set to only successful sign-ins, which has eliminated the problem for me.

jvalente_0-1605708412916.png

 


the only change in my environment between me not having the option and having it is the licensing. If that's the case it's highly frustrating that they put such a basic thing behind a paywall that can add six figures to your licensing *and* a MS employee responded to this thread and just couldn't clarify that and has left everyone scrambling for over a year.

I am just wondering here why this is an option - why should I track the non-legacy failed sign ins? Is it a higher risk if there is a non-legacy failed sign in compared to a legacy failed sign-in?
Anyone got an answer to this? Even with Successful login selected it still picks out unsuccessful.
I'm even getting impossible travel alerts for DISABLED accounts.
This alert is totally useless in its current form
in my tenant, when I change it to successful sign-ins, I stopped getting the false positives about the failed logons. Perhaps you just need to give it a bit more time.
you have to create an authentication policy to block sign-in attempts using legacy protocols such as IMAP, POP and SMTP. Just disabling these protocols in Exchange is not enough, otherwise you will still have people trying to brute force against these disabled accounts.
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authen...