Detecting Account Compromise through Land Speed Violations OR How High School Maths Help Catch Bad Guys…
I’m Mike, and I’m a Security Consultant with Adarma. One of my main responsibilities is to work with some of the UK’s (and world’s) best known & loved brands and onboard them into our multi-tenant managed Security Operations Centre. In fact, I’ve not long started an engagement doing just this with an international lottery-based cause marketing organisation (https://en.wikipedia.org/wiki/Cause_marketing).
One of my favourite parts of an onboarding engagement is talking about security monitoring use cases because it’s really one of the first opportunities we get to show off the cool things we can do for our customers. One of my favourite use cases of all time is how we detect potential account compromise by identifying where a land speed violation has occurred between logon locations for a given user. Our sales team call it the Superman Use Case.
At its core, it’s a really simple principle that makes it all work and I think that’s why I like it so much (That and I love seeing the look on people’s faces when they find out). I’ve yet to find a time when I’ve wondered (or needed to figure out) when two trains that depart separate stations at different times will meet, but I use the same principle to power my use case. Have you worked it out yet?
No, really.
Stacie Ellis is a colleague that works for one of our customers. Recently, like a lot of us, Stacie has been working from home due to the COVID pandemic and has been connecting to the corporate network using her VPN. The VPN is hosted in AWS, so seeing Stacie authenticating from Dublin, where AWS region eu-west-1 is hosted, is nothing out of the ordinary.
What is interesting, however, is that Stacie is then seen logging in from Qingdao in China. This isn’t a known AWS data centre here, nor does our customer have any business in China and so the question arises, is this really Stacie?
A lot of customers are really quite surprised when we reveal that the deep, dark secret is really just Speed = Distance/Time. It takes a little bit more work to get it into this form, so let’s step through how we get these factors.
Working out Time is pretty simple — We just subtract the two date/time stamps which gives us 86,400 seconds, or 24 hours. Easy!
Distance is a little bit more complicated. We take the IP Addresses that Stacie has logged in from and we compare them against a Geo IP database (like Maxmind) to find out relevant information such as the city, region & country the address originates from and, most importantly, longitude & latitude coordinates (Disclaimer: YMMV if you live in Kansas (1)).
Using the Spherical Law of Cosines (basic trigonometry for circles (yes that is a thing), which is another blog post for another time), we can use the longitude & latitude co-ordinates to work out the distance between the two points, which is 5484.93 miles.
Speed = 5484.93 / 24
In order to have covered this distance, Stacie must have been travelling at least 228.54 miles per hour (on average). This is above the threshold we have in our detection rule and so an alert is sent to our Security Operations Centre for investigation by one of our SOC Analysts.
So at face value, this looks like an easy one, but before we jump to conclusions let’s talk about how one of our SOC Analysts would approach an alert like this.
· Is Stacie travelling for business, or on leave? We’ll look to see if Stacie has enabled her automatic Out of Office response and if it mentions that she is travelling, or on leave. We’ll also maybe have a quick glance at recent email subject lines — Do they indicate that Stacie has plans to/is currently travelling or on leave? It’s not unusual to not find anything here — People forget to set their OOO responses & not everyone discusses their personal life over email subject lines (Don’t worry, I can’t read your emails).
We can also reach out and speak to Stacie’s Line Manager. Who in the customer organisation is going to know if you’ve been at work recently, if not your direct supervisor/manager?
· Is it feasible to travel the distance in the identified time frame? 24 hours between logons seems like a feasible timeframe to travel between Ireland & China if you take a plane and if you checked Google Maps, you’d be right. Flight time from Dublin to Qingdao is just upwards of 21 hours.
If you looked for flights, however, you’d be out of luck — There are no flights from Ireland to Qingdao between now and the end of February 2021 (at least, accurate at the time of writing). If you travel to Edinburgh, or to London, you can get flights but these are 50 hours with 2 layovers & 31 hours with 2 layovers, respectively. This is of course before we factor in time spent travelling to the airport, checking-in, clearing security, etc. In short, you’re not getting from the UK to China in under 24 hours unless you are, of course, Superman or Superwoman.
So it looks pretty likely that unfortunately, Stacie’s account has been compromised. This is where our Analysts will work through a Playbook, use their judgement to triage the potential impact and engage the appropriate escalation processes. Some of the information our analysts will look at:
· What did “Stacie” log in to from the rogue address? Was it a Cloud-based service like Office 365 or a server in a physical data centre? Although the compromise of an Office 365 account is far from ideal and significant damage can still be caused, there is a layer of separation that limits the attacker to the contents of the O365 account & prevents them from traversing the physical network. An attacker that has logged on to a Domain Controller now potentially now has a route directly to critical assets & crown jewel systems with the keys to the kingdom in their possession.
· What is Stacie’s role within the organisation? Is Stacie in a front line customer-facing role, and so potentially handling sensitive & private customer information? Is Stacie perhaps in an IT support role, and so might have low level but far-reaching privileges that could be used to spread malware? This helps us to determine what the impact of having Stacie’s account compromised might be to the customer — A colleague who is store-based and interacts with IT systems solely for operating the point of sale device is a lower priority than a colleague who sits on the board with access to confidential commercial information.
· What does Stacie’s email & web traffic look like? What emails has she received in the lead up to the account compromise, and who were they from (Who does it say it’s from, and who is it really from)? Has Stacie been a victim of phishing herself? What about email activity post-compromise? Has Stacie suddenly started emailing senior colleagues for the first time? What about email volumes in general, has there been an increase in emails to colleagues (indicating potential internal phishing) or externally (indicating potential data exfiltration or more phishing)? Can we see regular & repetitive web traffic patterns that could indicate attempts to contact command & control infrastructure?
· What’s been happening on Stacie’s device? Assuming that Stacie is using a corporate device, we can examine a range of event logs from the applications, software and operating system of the asset in question. Has the on-board AntiVirus/AntiMalware solution recorded events that might not appear suspicious on their own, but do when viewed in the current context? Has the operating system recorded scripts, files and/or executables being created in the downloads and/or temporary folders? Have there been suspicious changes to the device registry, such as changes to core/critical keys or an anomalous volume of changes? New services, anyone?
These are just some of the considerations that our analysts make when looking after a range of issues on behalf of our customers. The information they gather is used to identify the potential impact to our customers and will inform the priority at which the incident is escalated. From there, our analysts will work to support & guide our customers through an Incident Response process that seeks to identify, contain, eradicate and then learn.
And so there we have it, how Speed = Distance/Time helps real-life cybersecurity analysts catch bad guys. Sound interesting? Contact careers@adarma.com if you’re interested in a career in cyber security.
