Last updated at Tue, 14 May 2019 19:34:01 GMT
Account takeover (ATO) is difficult to prevent against because it can go unnoticed for years until a customer notices something is amiss. It’s tedious and requires detailed logging as well as flexible query ability to survey for it ‘by hand’.
Many consumer-facing companies try to create in-house solutions, but it can take years to develop the tools to even do ‘machine assisted’ ATO detection. Even then, it still requires a large human component. We saw an opportunity to help our customers by making ATO easier for security teams to prevent against as well as remediate in a matter of minutes, not years.
There are two primary incentives behind account takeover, active prevention, and quick remediation. The key is to identify attacking entities (IPs or groups of IPs for instance) that are attempting to compromise user accounts – and block them and to identify accounts that may have been compromised – so that your incident response team can remediate.
In order to simplify this, we identified signals to monitor by working backward from what an attacker would likely attempt. Namely, an attack would probably come in one of a few different ‘modes’.
5 Common Types of Account Takeover
– Attacks targeted at compromising one high-value account.
– Credential stuffing
– Dictionary attacks of common passwords
– Phishing
– Session hijacking
For dictionary attacks (at a minimum), this would appear as repeated failed login attempts on a user from an IP where they have not logged in before, and likely where no other user has logged in before. The same signals apply to less targeted attacks where the attacker attempts login on many accounts using a list of possible passwords. We would identify that by sensing a high rate of login attempts from an IP or set of IP addresses along with a low concentration of ‘non-login’ page views, and hopefully a low login success rate.
If an attacker is attempting to validate a pastebin credential dump, say for another website, we may see a large number of invalid user IDs, since the attacker does not know whether they exist on the customer site or not.
In all of these cases where we’re looking for a ‘large’ or ‘high’ rate of something like login failures, this is relative to normal traffic for an IP or global traffic across the customer’s property. So, it’s essentially outlier or anomaly detection.
After being alerted to the high login failure rates, a next step may be a session analysis by attempting to identify suspicious activity from a successfully authenticated user that may indicate a compromise. tCell also watches for some other simple signals of account compromise. One example is geo-hopping: if an account is active in one geographical location, but then is shortly active again in a distant geographical region, and on a completely different browser (to rule out a user hopping on VPN, etc), the account may have been compromised.
Another simple check is for session hijacking, where a user’s session token is used from a completely different browser. This is an almost unlikely scenario except for the case that user copied their own cookies. More likely, malware has stolen an active session cookie and used that cookie to access the user’s account.
tCell detects these things by collecting per-user and per-IP counts of login attempts, successes, and failures, and aggregating them at different time scales; hours or days to identify low volume slow attacks, minutes to identify rapid acute attacks. These metrics are checked against heuristics to identify attackers. Attacks can merge if two independent attacking entities, IP addresses in this case, have overlapping sets of users being attempted, which may indicate that they are using a distributed network to spread out their attempts.
If your team is looking to do ATO as a part of a larger initiative, using a partner that can provide you with a full suite of ATO protection capabilities will enable you to focus your time on prevention and remediation instead of building it yourself.
Thanks for reading!