Account Takeovers: Detection and Prevention

Recently, someone close to me asked for some recommendations on how to build a system to prevent potential account takeovers. This person was looking for some good readings on the subject and, to my surprise, the topic is full of security vendors trying to sell their software and “AI-powered” solutions to this problem.

I disagree companies need such expensive software, whether big or small, mostly because they already possess most of the information they need to build the basics.

In this article, I want to think out loud about some strategies I have seen in the industry to detect, alert and prevent account takeovers. This should be helpful to you if you are looking for a starting point on how to tackle this problem.

Account Takeovers (ATO): The Problem

In this digital world, a considerable amount of threat actors try to perform identity theft in web services to use that identity maliciously, or to leverage that account’s data elsewhere (sell it, for instance).

Regardless of your product, I am sure this is an issue to you too, as I have seen it in various industries.

Unlike many might think, this is not just a problem for customers. Customers can start perceiving your solution as prone to security mistakes and indeed you should do something about it - Sometimes it feels like it is impossible to mitigate security issues like this, but doing small actions is enough to prevent some, if not most, of these cases.

The first step: Logging

As with any security issue, the first step is to have something in place to detect the issue. This can be achieved through basic logging, without any AI-fancy-gimmicks. Logging is a must in today’s software architecture, not just for security, but to help debug situations, to understand what is going on in your application at all times.

I should write another reflection on logging some other time.

When discussing today’s applications and industry practices, logging is indeed a science of its own. It is quite challenging to come up with a logging policy that suffices all needs, to ensure it allows easy debugging, it does not expose customer personal identifiable information (PII), that logs are connected, it’s cost efficient, data retention, legal requirements, …

However, logging is indeed key to detect and identify security issues and malicious activities, particularly account takeovers because one of thing that should be logged is the authentication system.

Nowadays, specially with the rise of micro-service oriented architectures, there’s an added layer of complexity on how to make sense of it all. A login request on one service has to be easily related with other actions that were triggered afterwards. Only this way you can detect and anomalous behaviours.

Detecting Cases

You now have the logs in place, what do you do with them? Well, for many other security issues included, there should be alerts built on top of these. There are many alerts you can build for security reasons, but let’s focus on account takeovers for now.

Account takeovers involve somehow bypassing authentication or appropriate legit credentials somehow. The first, although harder because there are numerous ways authentication can be bypassed, can still be detected through application logs.

The latter, perhaps as common, involves attackers sending what is known as dictionary attacks, or credential stuffing.

There are a lot of places out there attackers can obtain password and user lists, as well as leaked user and password combinations. The difference is the first is more like guessing, while the second list is worth for trying to look for re-used passwords. Password reuse is a common security mistake a lot of people make, so why not try previously leaked credentials?

What both attack forms have in common is the number of requests these usually trigger. There are a lot of tools to perform this attacks automatically by just providing the user and password lists, but attackers can also build their own scripts. It’s relatively straightforward to do so. What most ignore, is rate limiting.

More serious threat actors will of course throttle the request volume to ensure it will not trigger these kind of systems or any other really. These are basic measures and the most reactive too which is prone to failure. Unless you have a Security Operations Center working 24/7, there is a chance you validate the issue only after there was damage done.

Alternatively, we can use cookies for a more detailed tracking. This might help detecting anomalies in stealthier attacks and also gives us a few more possibilities to work with.

Cookies are used for multiple reasons - commercial, performance, tracking… Just to name a few. To detect odd login attempts (or successful ones) though, we need some robustness and thinking first to ensure attackers cannot replicate it easily. On the other hand, using cookies and alerting users of suspicious behavior can do wonders to proactively prevent account takeovers. Furthermore, users should have a chance to report if indeed the login is illegitimate and thus you can focus only on cases you know are true positive cases of takeovers.

Many services nowadays do have an implementation similar to the above. I can name a few: Google and GitLab do this extremely well. When you login from a “new” location (and by new this means without this cookie) the user receives a warning email and the cookie is set in the browser. An important detail of HTTP cookies is the Expires attribute; This can be set to expire some day (which is recommended when managing sessions anyway and you can read more in OWASP’s Session Management Cheatsheet) and until then, sessions can be refreshed without triggering a new alert. This implies using a different cookie or (preferably) another mechanism to manage sessions (like JWT tokens). This cookie should be specific for this and nothing else. Lastly, whether you notify the user directly as GitLab or Google do is a business decision to make.

As mentioned above, this system requires thinking about some details though, to ensure attackers cannot simulate a legitimate session that easily. We need to ask, at least, the following:

• How random/unpredictable is/should this cookie be? If its value is legit=true or something easily perceived then an attacker can easily set one up mistaking your system.
• Should it have Expires date set? How can this be renewed safely and, again, unpredictably?
• What will be considered as the first legit login if anything? Probably with this cookie mechanism, there will not be a first valid login - if the cookie is not sent, then a notification is sent to the user.
• Do you have application protections to ensure attackers cannot exfiltrate cookies from another place first? Like using
  http-only attribute, a good Content-Security-Policy header, or both.

I have seen systems use IP geolocation measures too. Nowadays though, I believe this approach will lead to lots of false positives for two reasons alone: VPNs and travelling. People use VPNs a lot these days and can change location in a matter of hours… It is not super efficient for these type of applications. This approach should be used on systems you know people will only login from one location, IP range or private network: Like internal applications/systems. Only then, using geolocation is actually a great option.

In summary, I believe these are the three top measures to build your own detection system for account takeover attempts. From most reactive to most proactive:

• Create and monitor a rate limit for failed logins in your systems;
• Use special-purpose cookies to monitor new devices and consider notifying your customer; and
• Use IP Geolocation to detect user movements (only if it makes sense to your customers).

Involving the Customer

So far, we have mostly discussed approaches we can take to stay on top of these cases without discussing when to contact the customer and how.

When I discussed the cookie approach, I openly mentioned GitLab and Google email users when they detect odd behaviours. This is the most proactive posture to protect against account takeovers. Essentially, emailing customers about a new login should let the users report if it is definitely illegitimate or not reduces the number of false positives by a lot, and immediately lets users take action - something threshold mechanisms do not. Which brings me to the topic of this very short session - When to involve the customer. This is highly subjective to how you usually communicate with your customers but the intention is to provide a few ideas to you.

In all cases I had to investigate for potential account takeovers, the steps I took where very straightforward:

1. How many IPs can I get using this email? How many were involved in excessive failed attempts?
2. Have the IPs had any successful login? If so, which emails and accounts?
3. Did this IP try other emails? (Repeat the above if any)
4. (If the attacker was successful) What actions have been performed? What can be reverted?

From step 2 and 3, we typically involved the account manager to know if the customer was having any issues logging in or knew something that could justify the excessive number of failed logins we were seeing. In some applications and setups this might be the case, since users could be trying to integration automated systems.

For step 4, we start touching the surface on another complex topic in Cyber Security: Incident Response. It is important to study if there were any data breaches, how and when, so it can be communicated to any authorities you need to respond to. Once again, this topic is subjective to the laws of the country you are working in and I do not want to go deep about it on this post.

We want to tread carefully when we reach out to users. We do not need them to panic, perhaps, but they still need to protect themselves and check the damage. This is probably a good occasion to remind users they should change passwords (to a safe one and not one reused) and enable multi-factor authentication (if you provide that). It would be great to hear back from the customer to confirm if it’s a true or false positive. Only then we can take measures to prevent more damage coming from this IP.

Prevention Strategies

Preventing account takeovers is an effort that can be split into two fronts mostly: User-land and Application-land.

From the Application-land, we have already discussed a few strategies to help notice and trigger a process to handle these situations. There are, essentially, three more things I find important for prevention ATOs:

1. Multi-factor Authentication: If possible, allow users to enable MFA and, if there are multiple user role types in your environment, consider enforcing MFA for admin-type users.
2. Write and raise awareness about password safety measures, like no re-using passwords, use a password manager to more easily pick and store a random and long passphrase, etc.
3. Block traffic coming from countries where there is no business value.

The first two points are kind of straightforward to understand - if you have means for added security layers, raise awareness for your clients to use them. Of course, MFA is not a foolproof solution and it can still fail but it definitely makes it harder for attackers. Advocating for good security practices might not be the most fruitful strategy either, but it’s something.

The latter point though, it is rather controversial and might not be suitable for all cases, but I have seem this being applied in some industries. As usual in this article, it depends a lot on your business, what is the stage of your company, what is the legal framework, and so on.

You can leverage web application firewall (WAF) solutions or even in a simple blacklist mechanism to block specific IPs, and one rule can simply be based on the IP source location. Sure, this can be masked through VPNs but it does wonders.

When you find any country without business value (like you have no clients at all, it proportionally represents no value in your income, or you simply cannot exercise there), you can/should block it in your WAF or Firewall rules. This requires some research beforehand but will definitely do wonders for troublesome locations as you will dig which ones are usually used by malicious actors, you will study if there is a business reason to keep allowing this traffic and then you will decide whether you can block that or not.

If it is not worth the risks, just shut it down.

In the above, I have discussed some approaches I have found out there to prevent account takeovers. There are likely more ideas, strategies and approaches that I don’t know about. If you have more ideas about this topic you would like to discuss, feel free to tweet them at me!

Thanks for reading, I’ll see you next time.
gsilvapt