What is Account Takeover (ATO) and 5 Best Practices to Prevent Account Takeover

What is Account Takeover?

Account takeover, or ATO, is a form of digital identity theft or fraud in which a malicious third party gains access to an online user’s account information. In a successful ATO attack, the attacker can change account details, access and steal financial information including stored credit card numbers, plant ransomware or other malware, and perform other nefarious acts. The FBI estimates that ATO fraud costs businesses $12.5 billion dollars globally — including 41,058 victims in the US who lost nearly $3 billion.

What types of organizations are targeted by ATO attacks?

ATO attacks have expanded far beyond the initial focus on financial institutions. ATO attacks can affect any organization with a customer-facing login. According to the 2021 Data Breach Investigations Report from Verizon, the most prevalent goal of ATO attacks — including the insertion of ransomware, cryptocurrency theft, and the sale of private/personal information — is fraudulent financial gain. Personal information can be leveraged to falsely apply for lines of credit, commit insurance fraud, and used to make phishing and spam campaigns more believable, especially in targeting the healthcare industry, the public sector, and academic institutions. Bad actors also use ATO attacks against eCommerce websites, taking over a legitimate account to purchase items.

How Does Account Takeover Happen?

Attackers are aware that users often fall into the bad habit of using similar usernames and/or passwords across multiple services. The sheer volume of online services that the average person uses is large, and thus account name and password re-use is commonplace. Bad actors easily obtain credentials to billions of compromised accounts through prior data breaches or data leaks. After compiling the data set of pilfered credentials, the attacker will target a service and launch an attack against respective login APIs. These attacks can be manual or automated with bots, botnets, scripts, custom code, or security tools. Attackers also may use a variety of techniques to compromise credentials, including credential stuffing or brute-force attacks or targeting authentication and authorization mechanisms directly, which we will explore in depth in this article. It’s important to note that these techniques can work for user or machine identities, and both types of account compromises can be equally destructive.

Broken Authentication

Broken authentication refers to a flaw that allows a bad actor to log into an account and perform actions under the guise of an authenticated user. The flaw ranks high on the OWASP API Security Top 10 due to its prevalence in API designs. Exploitability is heightened when APIs also exhibit weak session management and/or credential management. Note that while OWASP calls out “user authentication” specifically, potential problems are just as prevalent if not worsened with authentication of machine identities.

Effective authentication in APIs is a complex and confusing topic. Software and security engineers often have misconceptions about authentication requirements or are unsure how to correctly implement it. Prompting an API consumer for credentials and additional authentication factors is also not feasible in direct API communication or automation scenarios. Authentication mechanisms are easy targets for attackers, particularly if the authentication mechanisms are fully exposed or public. These two points make the authentication component potentially vulnerable to many exploits. Advanced attacks that target authentication include brute forcing (of authentication) and credential stuffing, both of which we will cover in more detail below.

An attacker who is able to successfully exploit vulnerabilities in authentication mechanisms can take over user accounts, gain unauthorized access to another user’s data, or make unauthorized transactions as another user. In cases where an API is designed explicitly for machine communication, an attacker who compromises the related authentication mechanism or authenticated session can potentially gain access to all of the data that machine identity is entitled to access. In addition, other attack patterns emerge in cloud-native designs with compromises of workloads and server-side cloud provider metadata services.

How to Protect Against Broken Authentication Attacks

To protect against broken authentication attacks, an API security solution must be able to profile the typical authentication sequence for every API flow. The solution can then detect abnormal behavior such as missing credentials, missing authentication factors, or authentication calls that are out of sequence. Determining the baseline and identifying abnormal behavior can be done only by analyzing large amounts of production API traffic. This form of analysis is critical for mitigating advanced attacks that target authentication such as credential stuffing and credential cracking. API security solutions with on-premises deployments will lack the breadth of data needed to accurately identify these types of attacks.

Organizations should also employ other authentication best practices such as enforcing MFA, strong password policy, session timeouts, and account lockout thresholds. For machine identities, organizations should not rely solely on API keys as the primary means of machine authentication. Any API keys should be rotated at reasonable intervals and API callers that use API keys should be monitored for excessive or abusive consumption.

Credential Stuffing

The credential stuffing attack technique relies on lists of compromised username/password combinations, and the common bad habit of users implementing the same credentials across multiple services. The success of credential stuffing attacks increases when the username is an email address, since this information is easily obtained or guessed by attackers. Credential stuffing attacks can be mitigated to an extent by implementing policies that lock an account after multiple failed login attempts. Setting an aggressive account lockout policy can inadvertently create a bad user experience, however. Organizations look to balance these demands and will sometimes implement a more lax policy, such as locking the account after 10 bad attempts in an hour. Attackers can take advantage of these relaxed settings — in this instance, attackers could set their tooling to try nine attempts then back off and not resume the attack campaign until 60 minutes have passed.

How to Protect Against Credential Stuffing

Credential stuffing can be mitigated with a combination of practices and tooling, including the implementation of behavioral analytics and anomaly detection, multi-factor authentication, and denying requests from known malicious IP addresses. But to stop credential-stuffing attacks without negatively impacting user experience or deploying client-side code controls that attackers are able to bypass, you need to start with the ability to analyze as much data as possible to understand normal behavior, identify the outliers, and put together the pieces to form a bigger picture.

Because credential stuffing attacks can “hide in plain sight,” evading existing security measures, especially with login APIs that regularly experience massive traffic flows, baselining and analyzing traffic will help to identify anomalies. A dedicated API security solution like the platform provided by Salt Security can differentiate between user mistakes or behavior that changes in response to a changed API and malicious activity, such as an attacker probing an API and manipulating API logic.

Brute-Force Attacks

The brute-force attack technique consists of an attacker enumerating through alphanumeric and special character sequences to find working username and password combinations that provide authenticated context. Brute-force attacks often combine each username in a one (username)-to-many (password) attack. Attackers may also attempt to brute force usernames as well, depending on how much information they have at the start of their attack campaign. Brute force attacks are more successful when users choose simple or easy-to-guess passwords.

How to Protect Against Brute-Force Attacks

Password strength is paramount when it comes to mitigating  brute-force attacks. Long, sufficiently random, unique passwords can thwart most dictionary attacks. Users sometimes prefer the use of password managers that can automatically generate random, strong passwords for each application. You can add an additional layer of security against brute force attacks by implementing multi-factor authentication or two-factor authentication. Organizations will need to acknowledge the risk inherent with SMS-based 2FA challenges mechanisms that are prone to brute-force attacks or susceptible to other mobile attacks such as SMS swapping. Realistically, organizations will need to continuously monitor login activity and behaviors to detect new attack campaigns.

Password Spraying

Password spraying is a type of brute-force attack in which an attacker will “spray” the same password – for example “password123” — at a list of usernames hoping to gain access to the account. This approach is especially effective against applications or account admins that have a default password for new accounts, expecting the user to change the password upon first login.

How to Protect Against Password Spraying

Best practices to use against password spraying include account lockout policies after a defined number of failed login attempts, generating unique passwords for new accounts, forcing the user to change their password on the initial login, and the implementation of CAPTCHAs. Multi-Factor Authentication (MFA) can also add an additional layer of security without negatively affecting the user experience which is sometimes inherent with CAPTCHAs.

Broken Object Level Authorization

Broken Object Level Authorization (BOLA) is the most common and severe API vulnerability today, according to the OWASP API Security Project. BOLA occurs when an API does not correctly validate that the identity performing a request has the required privileges to access the requested resources.

Attackers can easily exploit API endpoints that are vulnerable to broken object level authorization by manipulating the ID of an object that is sent within an API request. These vulnerabilities are extremely common in API-based applications because the server component usually does not fully track the client’s state. Instead, the server component usually relies on parameters, such as object IDs sent from the client, to decide which objects can be accessed.

Failure to enforce authorization at the object level can lead to data exfiltration as well as unauthorized viewing, modification, or destruction of data.  BOLA can also lead to full account takeover such as in cases where an attacker can compromise a password reset flow and reset credentials of an account they aren’t authorized to. As an example, an attacker may abuse a password reset mechanism by manipulating an API call and altering the intended target of a request to be that of a victim account rather than their own account. Variations on this attack also include altering intended targets for SMS-based 2FA challenges.

How to Protect Against BOLA Attacks

To prevent BOLA attacks, an API security solution must be able to learn the business logic of an API and detect when one authenticated user is trying to gain unauthorized access to another user’s data. As one particular case, the logic could be that two object identifiers should match and that the authenticated user is authorized to access the requested object. This kind of detection requires the analysis of large amounts of API traffic to gain context and understand the normal usage for each API. It needs cloud-scale big data, not simply the amount of data available in an on-premises solution, to have sufficient context. A solution with a baseline of normal API usage can identify abnormal behavior like an attacker manipulating the userId in a query parameter in GET requests, or a userId variable within a message body of POST requests.

Five Best Practices to Prevent Account Takeover

1. Assume your APIs are a known quantity and can be called directly. Attackers discover the URLs of API endpoints and how to exercise them by sniffing application traffic and reverse engineering front-end code. While the bar for attackers to discover APIs in mobile or IoT channels may be slightly higher than web channels, it’s a trivial jump at best. Attackers also move between channels and target the most vulnerable path. If you have weaker security controls for a particular channel, assume that it will become a  prime attack vector.
2. Always authenticate and authorize your API consumers. OWASP lists broken authorization and broken authentication as the highest priority flaws in the API Security Top 10 for a reason – these API flaws are highly prevalent and destructive. You should always authenticate API callers where data or functionality is sensitive or private. It’s also critical that you continuously validate the authorization level of authenticated users to ensure they are entitled to given data or functionality.
3. Provide only the data that is necessary for a front end to function. Attackers easily expose the API communications of front ends through the use of intercepting proxies on endpoint devices they control. This reality holds true even in cases where encrypted transport — such as TLS — is in use to protect data in transit. Such data is readily harvested and scraped by attackers to aid in ATO attack campaigns and more.
4. Baseline typical account behavior. Analyze your API traffic and establish a granular baseline of legitimate behavior for your organization’s unique APIs. This analysis should include login APIs (for risk concerns about authentication attacks) as well as sensitive functionality or data access APIs (for risk concerns about authorization attacks). Using the Salt platform, you can easily create baselines of typical API behavior and identify any API consumption that deviates from those baseline. The Salt platform can detect deviations such as excessive login errors and the attempted manipulation of tokens, user IDs, or API parameters. Anyone who relies solely on authentication mechanisms to stop account takeover will remain vulnerable and exposed.
5. Pinpoint attackers. You need sufficient data baselines to see the correlated activity of an attacker. You can leverage the Salt Security API Protection Platform to gain full context of API traffic. It will distinguish between “different” and “malicious” activity, and it correlates all activity of any given identity. It can pinpoint an attacker trying to take over accounts, block that attacker automatically, or send the security team an alert, via their SIEM or any other workflow.

Using Salt to Avoid Account Takeover

The Salt platform uses cloud-scale big data and patented AI/ML to detect malicious activity and prevent data exfiltration and unauthorized access to accounts, resources, and data. The Salt platform understands the typical consumption patterns for each user and API endpoint. It immediately and continuously detects deviations where an attacker might be trying to gain unauthorized access to accounts. You can configure the Salt platform to automatically block such malicious account takeover activity or send alerts with a full attack timeline to incident response teams for further analysis. To see the Salt platform in action, you can schedule a customized demo.