Account Takeover (ATO): Types, Detection, Prevention and Protection

In the previous installment of our blog series on the modern threat landscape, we looked at how attackers can use credential stuffing attacks to break into valid user accounts.

Today, we will continue to follow that theme by diving into the world of account takeovers (ATOs) to see how attackers use compromised accounts to commit fraud. 

What is account takeover (ATO)?

Like other threats covered in this series, account takeovers are problematic for traditional OWASP-style WAF rules. While these rules look for overt malicious actions such as injections or XSS attempts, an account takeover involves an attacker who has already gained credentialed access to a user’s account. At this point, there is typically no need for a traditional exploit as the attacker will perform various types of fraud with the compromised user’s account. 

Security teams will need new tools and perspectives that are designed for this growing class of threat. So let’s dive in to better understand what ATOs are and what organizations can do to protect their applications and users.

Causes of Account Takeovers

Account takeovers represent one of the latest stages in the lifecycle of an attack in which an attacker attempts to turn previous hacking efforts into some form of profit. Security teams are naturally motivated to disrupt these attacks as early as possible before the ATO can ever take place. However, there are many ways attackers can gain initial control over a user’s account; some will directly involve the application, and some will not. As a result, it is often impossible for an organization to fully prevent ATO attacks upstream.

Some of the most common ATO enablers include:

Credential Stuffing
Credential stuffing attacks attempt to break into an account by reusing account credentials exposed in a previous breach. This technique takes advantage of the fact that users will often reuse the same password on multiple online accounts. These efforts naturally involve trying large numbers of credentials and thus are typically the work of large-scale botnets. It is important to note that credential stuffing does involve attackers directly testing the application, meaning that using anti-bot protections can significantly reduce this precursor of an account takeover.

Phishing and Social Engineering
Phishing is one of the most tried and true methods of gaining a victim’s credentials. Attackers will often spoof emails that appear to come from a particular application encouraging the user to login, only to lead the user to a fake version of a site where the user’s credentials can be harvested. Phishing attacks can also lead to the installation of malware or keyloggers that can capture credentials to any number of applications over time. It is very difficult to fully prevent these techniques since they involve actions that users take when not on the application itself. However, support for multi-factor authentication can help to mitigate the impact of stolen credentials.

Malware, Trojans, and Man-in-the-Browser
Instead of using malware to harvest credentials, attackers can also use malware to directly manipulate an application while the user is logged in. These techniques were pioneered by banking trojans but have since spread to other forms of malware. In this case, the malware can act as somewhat of a parasite, riding along with the valid user through the authentication process, then automating malicious actions in the background once the user is connected. These techniques are particularly insidious as they will use the valid end-user to complete any secondary factors of authentication.

How do account takeovers result in fraud?

Account takeovers have long been associated with financial fraud, and while this remains a primary motivation today, it is important to remember that many types of accounts can be abused by an ATO. This can include:

• Direct Financial Fraud – A compromised financial account can let attackers initiate fraudulent transfers to directly steal funds. Attackers can also open additional accounts or credit cards that can then be abused. 
• Indirect Financial Fraud – Attackers will also abuse accounts in more indirect ways to make money. For example, they can buy gift cards or steal a user’s points, which can then be resold. This may seem like small impacts, but gift cards are heavily used by criminal groups as a way to launder money.
• Spam and Phishing – Many applications are inherently social and foster user interaction. By compromising an account, attackers can use this trusted position to lure other users into making dangerous clicks. 
• Fake Reviews, Astroturfing  – Applications can also be abused in order to manipulate public opinions. For example, an attacker can use compromised accounts to create fake reviews for fraudulent products. Similarly, fake user clicks and comments can be used to manipulate social media and trending content.

How to detect account takeovers?

Detecting account takeover requires the ability to identify the reconnaissance activity that occurs leading up to the takeover. This activity often isn’t easily identified as malicious, because attackers are using/abusing the exposed functionality of an application or API in unexpected ways, such as scanning the application, mapping of endpoints, fuzzing techniques, and method enumeration. 

Look for solutions that can detect attackers early on in the mapping phase and then fingerprint them to track future behaviors such as progressing to brute force techniques.

How to Protect Against Account Takeovers?

Key tactics to protect against account takeover include the following: 

Active Interrogation of Visitors
Actively challenge visitors in ways that are completely transparent to valid users while reliably revealing malicious automation. These challenges can detect and block attacker attempts to use bots both before and after an account is compromised. This can prevent the overall number of ATOs while also disrupting ATO abuse that is already in progress.

Fingerprinting and Entity Tracking
Advanced fingerprinting techniques can track attackers even as they change IP addresses, user agents, or other identifying characteristics. This ensures blocking decisions can see all preceding malicious or suspicious events in context in order to make ATO blocking decisions based on a complete view of risk.

Automated Deception Techniques
Introduce deceptive techniques such as fake fields that are readable to bots but invisible to users. Any interaction with these fields or functions can reveal that the visitor is a bot and not a human. Additionally, tarpit or further deceive attackers to monitor and observe ongoing malicious behavior.

Application Profiling and Behavioral Analysis
Baseline and monitor the normal behavior of applications. Since many ATOs rely on malicious automation, it’s important to be able to detect anomalous and suspicious application behaviors to reveal a previously undetected account takeover.

These techniques represent just a few of the techniques and countermeasures that ThreatX uses every day against account takeovers. Many of these same techniques are used to combat other types of threats, and this is by design. Instead of designing specialized countermeasures aimed at specific threats, our philosophy at ThreatX is to build blended protection strategies capable of dealing with any threat. All available perspectives and techniques are applied and correlated to every event. 

How to Prevent Account Takeovers?

Every feature of your API is a potential attack vector. If you simplify your APIs, you reduce your attack surface area and can better focus your security efforts. A few recommendations:

• Use existing standards and conventions whenever possible
• Use a stateless authorization model (and make sure your JWT tokens are encrypted)
• Deprecate old endpoints: Implement a deprecation and end-of-life policy.
• Push functionality to clients when possible: For example, instead of rendering HTML in your API, require the client to render HTML appropriate for the application. 
• Be conservative about returned data: Identify the “least common denominator” of functionality needed.
• Reduce variant resource representations 
• Separate endpoints into read vs. write permissions
• Align resource boundaries to permission boundaries: Attackers will seek out complicated endpoints and attempt every possible combination of unexpected inputs in order to trick the system into behaving in unexpected ways. Aligning your resources to your permission structure will help keep your implementation simple. 
• Implement generic audit logs