ATO Blog

ATO Attacks: Defending Against Browser Automation

Account takeover (ATO) remains one of the most pervasive threats in the modern cybersecurity landscape.  Since 2019 there has been a 100% increase in reported account takeovers, primarily due to the growing availability of stolen credentials and password-cracking tools on the dark web.

For attackers attempting ATOs, Command-Line Interface (CLI) tools have been the weapon of choice as they are fast, scriptable, easy to automate, and available for most systems. However, as authentication systems become more sophisticated, attackers are shifting tactics — moving away from CLI tools in favor of browser automation frameworks. In this post, we explore why (hint: they better mimic real-user behavior), which tools are in use today, and how organizations can defend themselves effectively.

Not Your Grandfather’s Login

In ATO scenarios, CLI‑based automation is typically used for username enumeration, credential stuffing, password spraying, and other types of authentication probing. The targets tend to be APIs, password‑reset endpoints, and other rate‑limited services.

But today’s logins are not the simple, static HTML forms of the past. Modern authentication pages often include security measures such as client-side logic (JavaScript and cookies validation, dynamic field changes), multi-step flows (email confirmation, SMS code, authentication apps), human‑verification challenges, device fingerprinting, browser integrity checks, and WAF and anti-bot protections.

Those features make traditional CLI attack tools, like Hydra, less effective because they operate outside the browser. They send basic HTTP requests and cannot interact with dynamic content, such as JavaScript and cookies. CLI tools lack stateful session handling, while modern authentication flows often rely on client‑side tokens (like JWT) bound to a session and created through a browser. And anti-bot measures like CAPTCHAs and browser integrity checks are essentially instant roadblocks in CLI-level ATO attempts.

Why Use Browser Automation Tools?

In addition to the aforementioned limitations, CLI tools tend to leave trace patterns that are easier for security systems defenders to detect because they’re repetitive and structured, lacking the “messiness” of real browsing. Browser automation frameworks, on the other hand, are specifically designed to simulate actual browser activity and user behavior.

Browser automation tools mimic human interaction with websites, including page loads, timing variation, navigation of conditional login flows, and bypassing basic user challenges. They complete the illusion by handling dynamic client-side content such as JavaScript execution, cookies, and session management. Attackers will therefore typically turn to browser automation tools for ATO attempts targeting sites with strong bot detection, multi‑step logins, CAPTCHA‑protected pages, JavaScript‑rendered login forms, and the like.

The Main Tools in Use Today

There are several browser automation tools currently available to hackers intent on attempting ATOs at scale, each with its own advantages and disadvantages.

• Selenium – This is the oldest and most established browser automation framework, widely used in QA and testing. It supports multiple languages (Python, Java, C#, etc.) and real browsers (Chrome, Firefox, Edge). For attackers, its main limitations are that it is easier to detect due to default WebDriver fingerprints (for example, Imperva ABP contains a dedicated detection rule for Selenium) and its work synchronization is slower than newer frameworks.
• Playwright – A newer automation library from Microsoft, it supports all browsers and includes multi-page, multi-context support with high-speed performance. Its main advantages over Selenium for ATO purposes are its ability to orchestrate parallel login attempts and its minimal fingerprint.
• Puppeteer – This is Google’s Node.js library for automating Chromium‑based browsers. Originally designed for testing, it can be easily configured for high-speed ATO attacks. Its limitation, from the attacker’s perspective, is also an advantage: it’s highly specialized for Chromium-based browsers like Chrome.

We increasingly see these tools and techniques in the wild. Attackers rely on automated browsers to execute password‑cracking ATO attempts, layering on additional capabilities to evade detection. These often include outsourced or AI‑driven CAPTCHA solving, aggressive proxy rotation using residential IP networks, frequent user‑agent changes, and randomized interaction timings. Browser automation frameworks make all of this trivial to orchestrate, with many other techniques enabled by these platforms.

How Can You Mitigate Browser-Automation ATO Attacks?

Generally, defending against scripts that mimic real browsers is much harder than defending against CLI tools. But there are layered strategies that can significantly reduce the effectiveness of these attacks.

• Layer 1 — Strong access management policies. These might include a single sign-on domain (SSD), device‑level fingerprinting, and multifactor authentication. MFA remains one of the strongest barriers to ATOs, as even an attacker who has identified valid credentials will be stuck without access to the second factor device.
• Layer 2 — Tighter WAF rate limits and stronger bot detection. Defenders should look for things like unusual browser fingerprints, repetitive navigation patterns, timing anomalies, and headless browser signatures.
• Layer 3 – Red teaming and continuous testing. This is best accomplished by simulating automated attacks against your own systems, using the latest hacking techniques and tools, to validate defenses.
• Layer 4 – Threat intelligence integration. Feed known botnet IPs and automation script indicators into firewalls, for example, and leverage behavioral analysis to identify risk. This allows you to introduce friction selectively, without degrading the experience for legitimate users.

Finally, consider your entire login architecture. How are authentication, authorization and secure access managed across your system? Is it consistent everywhere users can log in or are there some unsecured “back doors”?  

Conclusion: Evolve Your Defenses to Match the Threat

Attackers have evolved from simple CLI password crackers to sophisticated browser automation frameworks that closely mimic human behavior. Selenium, Playwright and Puppeteer, developed as tools for dev and QA, have become accessible, powerful components in an attacker’s toolkit. They allow ATO attempts to bypass basic challenges, execute on the browser level, and blend into normal traffic patterns in ways that older hacker tools never could.

Defending against this shift requires organizations to modernize their controls and adopt a layered approach. Strong authentication policies and MFA form the foundation, reinforced with hardened WAF rate‑limit rules, robust bot‑detection signals, behavioral analysis and continuous monitoring for suspicious patterns. When these defenses work together, they raise the cost of automation, reduce the success rate of credential‑based attacks, and help organizations stay ahead of the growing risk posed by automation‑driven ATO campaigns.