I’ll admit, it’s not something I expected to have to relay through a client during a breach investigation but there it was…

How did we get to asking what kind of car the user drives? Location, Location, Location.

A client came to us during a breach of their Office365 tenancy looking for help with incident management. The client had been struggling to rollout out Multi-Factor Authentication (MFA), with the all too familiar issues that some organisations face with MFA – a user base resistant to change and some users working from their own devices.

Whilst they were struggling with their MFA rollout, disaster struck, a phishing campaign, brute force attacks and weak passwords (no stronger than Shatter08 (password changed to protect the innocent). Suddenly a number of accounts had been exposed; these suspicious logons had gone unnoticed and when an opportunity arose to try and intercept funds the attacker took it. Fortunately, they failed in this instance, but it could have been very different.

Clearly, a number of things had gone wrong, however, assisting with the MFA rollout and improving security operations monitoring would wait – first things first – response – who has been breached?

One of the things we immediately did was grab the logs from Azure for analysis and presto amongst other things we can see a whole bunch of non-local logons at all times of the day.

Obviously, location derived from IP address is not accurate. We could see evidence of Tor Nodes, obvious VPN hopping and brute-forcing as a service. Ignoring the brute forcing for now, we can then focus on the other records. It’s possible (if a little time consuming if you do it manually) to highlight the Tor nodes as issues (let’s presume none of the client’s users are Tor users), but what about the other IP addresses and their Geo-location data?

Immediately we saw a bunch of accesses from Oxfordshire, not where the client is based and its users have no reason to be there, but looking up the IP’s in use we see it’s the mobile telecom provider.

Then we are down to a lot of non-GB locations, 400+ in fact.

In tracing all the locations, we found a few false positives. Because of the way many multinational organisations work and the ever-increasing speed of the internet we found a company who sent all their British guest Wi-Fi traffic out of one of their offices in the US, whereas their own users’ traffic was being presented as coming from Germany. So visits to their offices and collaboration with their users showed a number of false flags.

But the Audi? We found a small number of non-GB logons, only for a specific user coming from Ireland, from an IP range owned by Cubic Telecom. Who are they? They provide the internet capabilities for Audi’s Virtual Cockpit.

When the Scottish user logs on to read their email from their Chinese phone, in their German car, the logs say the user is in Dublin, Ireland.

The world is a smaller place every day, with any number of services a user has access to potentially being sourced from anywhere in the world.

Location based locking – Geo-Locking is a feature that can be enabled in many providers, including Office 365 / Azure / Intune. But is it strong enough? You can blacklist everywhere except known safe locations, but you will end up blocking legitimate traffic. Location can be a factor in your security model – it could be one of your multi-factors, but only if it’s accurate and unfortunately IP address based derivation of location is not a strong enough factor.

Location based restrictions are still problematic as a factor – it’s not hard to spoof most methods of reporting location – so white-listing logons from a particular location will help protect from random attacks but will do little to prevent a serious targeted attack.

Multi-Factor Authentication takes away the need for geographic restrictions, blocks phishing, and vulnerabilities from weak passwords. If you can enable it in your organisation, do it.