4 Reasons Existing WAF Anti-Bot Solutions Fail To Protect Mobile

Mobile apps are now the dominant channel, and the threat landscape is shifting, with bad actors focusing malicious bot activity to conduct mobile-based attacks. Malicious bots, also known as “bad bots,” are automated programs designed to carry out harmful or deceptive actions, such as fraud, data theft, and financial theft and more. Botnet attacks are growing in sophistication, mimicking human behavior, and exploiting legitimate mobile app activities, making them challenging to detect. Traditional anti-bot solutions, like Web Application Firewalls (WAFs), struggle to protect against most mobile-based attack vectors, resulting in significant blind spots in organizations’ API defenses, highlighting the need for advanced mobile-specific bot defense solutions.

Limitations of Traditional Web and Cloud-based Anti-Bot Solutions

Many organizations use WAFs as the front-line defense against malicious bots. Traditional anti-bot offerings have struggled to keep pace with the evolving diversity and sophistication of mobile applications, often trying to force-fit bot defense methods designed for web applications onto mobile frameworks. This mismatch often requires mobile app developers to change the mobile application network stack, remove valuable TLS-protecting network connections, or limit bot defense to singular hosts. The result, for the mobile app-driven economy, is that larger parts of the mobile infrastructure are left vulnerable to mobile bot attacks, fraud, ATOs, API abuse, credential stuffing and more.

Why are WAFs ill-equipped to protect against most threats and attacks that exploit mobile apps and channels? It comes down to fundamental design. Simply put, WAFs are specifically designed to protect web applications. They typically do this by filtering, monitoring and blocking HTTP requests between a client (such as a mobile app or web browser) and a website or backend server. This works well in dealing with threats that attack web apps, websites and web-based communications channels. But now that most internet and network traffic comes from the mobile channel, and mobile apps are different from websites or web apps. Mobile apps do not behave the same way as websites, and they do not face the same types of threats. Defending against malicious bots in the mobile channel requires a fundamentally different approach than solving for web-based attacks.

When it comes to detecting and preventing malicious bots, mobile differs from web in four key areas:

1. Fingerprinting & Networking differences  
2. Attack and threat vector differences  
3. Telemetry and threat intelligence differences  
4. API and business logic differences  

Let’s review the differences, which result in significant blind spots with WAF anti-bot solutions in protecting backend APIs.   

Fingerprinting & Networking Stack Differences

The base requirement of any anti-bot solution is the ability to differentiate between legitimate connection requests and malicious ones. But in the mobile-first world, this requires an in-depth awareness of all potential threat vectors, attack methods, tools and techniques used to compromise the back-end APIs that mobile apps use.

It all starts with fingerprinting the endpoint that initiates a connection request. Fingerprinting mobile apps accurately requires using multiple methods that capture device-specific details, app characteristics and session information utilizing unique identifiers and sensor data. These are things that can only be known at the source. Conversely, fingerprinting for web involves browser interactions with web content, such as JavaScript, things that are evaluated on the network side. Because WAF vendors do not have an efficient method to deploy fingerprinting and detection technology inside mobile apps, they are incapable of understanding attacks or manipulations that occur on the mobile app itself. As a result, they rely on the same methods used to fingerprint web-based traffic, which do not work well with mobile apps. This makes web-based anti-bot solutions susceptible to false positives, false negatives and spoofing when it comes to the mobile channel.

Mobile Apps Face Unique Attacks & Threats

Mobile apps typically face a much larger attack surface than web traffic and the threats are much more varied and complex. There are thousands of unique attack vectors attackers can exploit within the mobile channel, attacking the device, the mobile app and the network. Among the mobile-specific attack methods that traditional anti-bot solutions are incapable of detecting:

• Device & OS Threats: Rooting/Jailbreaking, emulators/simulators/virtualization tools (eg: Bluestacks, Memu, Nox), abusing Accessibility services, kernel-based attacks, custom bootloaders, rootkits, root cloaking, Jailbreak/root detection bypass frameworks (eg: Magisk);
• Application Threats: Auto-clickers, code injection, overlay malware, keyloggers, key injection, fake apps/clones, trojans, accessibility malware, dynamic binary instrumentation (Frida), reverse engineering (static and dynamic analysis); and
• Network-based Threats: MitM attacks, fake certificates, SSL pinning bypass, session replay attacks, malicious proxies, fake Wifi, TLS downgrade attacks.

Blended attacks, combining more than one of the vectors above, make this even worse. For example, bad actors can extract the anti-bot SDK of an unprotected, legitimate mobile app and place it inside the malicious clone to gain access to and compromise back-end servers using a technique called credential stuffing. To achieve this, they often reverse engineer the legitimate mobile app to understand the inner workings of the login flow and build a clone app based on that info. Then they insert the SDK into the fake app/clone and use emulators or other virtualization methods to conduct brute-force login requests against backend APIs using stolen credentials. Traditional anti-bot solutions only partially defend against some of the techniques and methods used in credential stuffing, but not nearly all. For example, WAFs cannot protect apps against reverse engineering or against advanced virtualization and automation techniques typically used in credential stuffing. Nor can a WAF detect if malware or a malicious clone is being used in an attack. Each of these limitations significantly impairs the WAF’s ability to protect against credential stuffing, leaving crucial APIs exposed.

Telemetry & Threat Intelligence Differences

Telemetry for mobile bot attacks requires information from sensors, such as GPS, accelerometer, gyroscope, and OS-specific elements that are not available to web apps or browsers. Effective telemetry for mobile bots should include information about touch gestures, multi-touch events, and other interactions with the device’s touchscreen, along with accessibility events, app permission abuse and other critical app interactions, none of which are accessible to WAFs or web-based bot detection solutions. These are critical blind spots of WAFs, especially because attackers often abuse these legitimate OS or mobile app functionalities to disguise their malicious activity or elevate privileges.

Take the BrasDex or Xenomorph banking trojans as examples. These Trojans abuse Android Accessibility Service features to intercept events between the operating system and the app. They also leverage a specialized malware payload called “ATS” or Automated Transfer System, which allows the malware to enter information into fields or screens inside the mobile app. This allows the trojan to masquerade as the mobile banking user, bypass MFA, and complete end-to-end transactions such as money transfers – all without the knowledge or involvement of the user. Detecting such sophisticated and dynamic threats is impossible for web-based anti-bot products because they do not have access to the telemetry required to perform this detection.

API and Business Logic Differences Between Mobile and Web

In mobile apps, APIs are used for a majority of the app’s core functions. WAFs are limited to protecting a single API, domain, or host — even though there are many other APIs that require protection against bots. For example, in a mobile banking app, money transfers, payments, and other mission-critical functions all use different APIs, all of which require protection. In addition, mobile apps are heavily dependent on APIs between the app and external services, databases, or other software components such as payment gateways or social media platforms, as well as connecting hardware features of the device (e.g., GPS, camera). Traditional web-based bot solutions will miss attacks that target these APIs as well.

Performance, Compatibility, Agility, and Security Challenges

To overcome these limitations, existing anti-bot solutions attempt to bend their products to address mobile-based threats. For example, some require the implementation of an SDK into the mobile app, because that’s the only way the mobile app can respond to the main methods used by WAFs to identify bots from humans (ie: CAPTCHAs, JavaScript challenges, or JWT tokens).

Such solutions also typically require separate servers to be deployed behind the WAF, which are used to evaluate connection requests to discern legit connections from malicious ones. These “workarounds” impose single points of failure, performance bottlenecks, and latency, and they often come with unacceptable capacity limitations (such as limiting anti-bot protection to a single host or API). On top of that, WAF mobile SDKs also have limitations in terms of the dev framework support and can require developers to rewrite the network stack to achieve compatibility with the WAF. Such workarounds create more work and more expense for mobile brands. To make matters worse, because most anti-bot solutions on the market are not sufficiently hardened to protect against clones, spoofing, malware, or tampering, hackers can easily compromise, bypass, or disable the anti-bot solution if it’s implemented inside a mobile app that is not sufficiently protected against reverse engineering and other attacks. Check out this blog on reverse engineering to understand the magnitude of this problem.

The following chart provides a summary of the main reasons why existing anti-bot solutions do not adequately protect against mobile-based threats.   

Figure 1: Critical limitations of Web-based anti-bot solutions which render them ineffective in protecting against mobile attack vectors 

A New Approach Is Required for Mobile Bot Defense

Addressing the deficiencies of web-based anti-bot solutions requires a product that has been specifically designed to protect the mobile channel and mobile apps. A modern mobile anti-bot solution should offer multiple unique fingerprinting methods, detect and defend against mobile-specific threat vectors, and collect real-time threat intelligence from inside the mobile app. A successful mobile bot defense strategy requires solutions tailored to the mobile ecosystem, seamlessly integrating with existing infrastructure, providing real-time threat intelligence, and offering self-defending capabilities.

Appdome MobileBOT™ Defense is the first and only anti-bot solution built from the ground up for mobile that works with any WAF, providing the rich telemetry required for the mobile channel. In the next post, we discuss how Appdome’s MobileBOT™ Defense addresses all the deficiencies of existing anti-bot solutions to provide mobile brands an easily configurable bot defense solution, comprehensive threat intelligence and rapid defense against malicious bots, credential stuffing attacks, ATOs, and attacks against backend APIs. Furthermore, MobileBOT™ Defense allows organizations to preserve their existing infrastructure investments because it’s fully compatible with any industry-standard WAF, including full portability across any WAF for customers who use multiple WAFs or who need to switch WAFs.

Want to learn more about how to use Appdome MobileBOT™ Defense to protect backend APIs against malicious bots? Click the button below to get a free 20-minute demo.