When Security by Obscurity Blinds the WAF: From Client-Side Encryption to Critical SQL Injection —…

TL;DR#1: Since 2025, Just Mobile Security's offensive team has been tracking a recurring pattern identified across multiple mobile assessments in banking and fintech applications throughout Latin America: additional client-side encryption over TLS used to encapsulate complete requests and responses.

TL;DR#2: To validate whether the behavior was isolated or transversal, the research team analyzed a limited sample of applications by combining traffic capture, static analysis, dynamic analysis, Tungstenic , and local storage review.

TL;DR#3: This first post explains how the pattern was confirmed and what signals allowed us to prioritize the research. The full exploitation, including the reproduction of the cipher in Burp and its impact on the WAF, will be published in the second part.

Disclaimer

This investigation was based on multiple production applications downloaded from the Play Store. The integrity, confidentiality, and availability of the applications, their APIs, and backends were not affected at any time. The impact of this exploitation pattern ranges from client-side to server-side.

None of the applications mentioned in this publication are vulnerable to SQLi code injection or properly confirmed WAF Bypass; the aim is simply to demonstrate how the implementation of security through obscurity is common in Latin America.

Index

1. Introduction
2. Context that led to the research
3. Sample Construction
4. Massive Tungstenic Analysis
5. Signs of interest during the analysis
6. Traffic capture hypothesis
7. Hypothesis by static analysis and initial reverse engineering
8. Pattern confirmation
9. What we will see in Part II
10. Final Thoughts

1. Introduction

This first post covers the beginning of the research: how the team identified the pattern, how they confirmed it in a sample of 50 banking and fintech applications from LATAM, and what signals allowed them to move from an initial suspicion to a solid technical hypothesis.

During assessments of modern mobile applications, the Just Mobile Security offensive team is increasingly encountering implementations that add an encryption layer on top of TLS. In these scenarios, simply capturing traffic with a proxy is not enough: what is observed is not always the application's functional JSON, but rather encrypted structures that encapsulate entire requests and responses

At first glance, this type of implementation might seem like an additional layer of protection against man-in-the-middle attacks, certificate pinning bypass, or traffic manipulation. However, the point that motivated this research was different: if WAF/firewall protections cannot see the actual content that the backend processes after decryption, the protections may lose visibility precisely where it is most needed.

2. Context that led to the research

The starting point wasn't a single application. During multiple assessments, the offensive team and the JMS research team observed many attempts to reduce traffic visibility using two common layers: certificate pinning, additional encryption of requests, and application-level responses.

To massively test various banking and fintech applications from LATAM, the team downloaded 50 arbitrarily selected apps directly from the Play Store and analyzed them using the Tungstenic tool , developed by Just Mobile Security .

This allowed us to obtain crucial information for the research without needing to perform active penetration tests directly on the applications or their backend.

These security implementations can make analysis from a traditional proxy more difficult, but they do not replace robust server-side validation. If the mobile application contains the logic necessary to construct, encrypt, or decrypt messages, that logic can be examined from a controlled device during an authorized assessment.

Based on these observations, the team decided to analyze whether these were isolated cases or a recurring pattern in banking and fintech applications in the region. To do this, they looked for signs on three main fronts:

1. Encrypted traffic over TLS observable from Burp or other capture mechanisms.
2. Client-side encryption logic within the code, network modules, helpers, or interceptors.
3. Artifacts related to local storage, SharedPreferences, Keystore, or runtime values that help explain how the flow was built.

3. Sample Construction

To confirm whether the pattern was widespread, the team assembled a limited sample of public mobile banking and fintech programs from Latin America. This sample allowed for comparison of behaviors across applications, platforms, technologies, and frameworks; this was sufficient to observe that the pattern appeared in more than one case and under different implementations.

The sample was used as a starting point to organize the research, compare repeated behaviors, and select representative cases for further analysis.

From approximately 50 applications, the team identified at least 8 cases with patterns compatible with client-side encryption and additional information about TLS . That result was enough to confirm that the behavior was not an isolated case…

4. Massive Tungstenic Analysis

To accelerate triage, the team used Tungstenic as an entry point to process binaries, centralize results, and prioritize relevant signals. This allowed them to combine static observations, application metadata, safeguards, libraries, framework indicators, and preliminary findings into a single working view.

In addition to encrypted traffic, the analysis revealed other elements relevant to the mobile pentesting context: custom protectors or RASP, KYC SDKs, certificate pinning, use of WebViews, local storage, and important differences between technologies such as native applications, Flutter, Genexus, or other hybrid frameworks.

5. Signs of interest during the analysis

Observing encrypted traffic was just the first sign. From there, the team tried to understand whether behind those encrypted blobs/data there was an architecture where the client actively participated in building, encrypting, decrypting, or storing the values necessary for the backend to process the messages.

5.1 Encrypted traffic over TLS

The first sign appeared during traffic capture: even with MITM configured, the proxy did not show clear functional parameters, but rather fields with encrypted data, opaque structures, or extensive blobs that encapsulated the complete request or response.

5.2 Client-side encryption in code

The second sign appeared upon reviewing the application's code. It was found that in some cases, network modules, interceptors, or helpers performed transformations on the data body before sending it to the backend or after receiving the response. This logic showed that the client was actively participating in the cryptographic process and helped explain why the traffic observed from the proxy appeared encapsulated.

5.3 Internal Storage, SharedPreferences and Keystore

The third clue came from reviewing local storage and runtime available values. Examining Internal Storage, SharedPreferences, and references to Keystore provided additional context on how some applications stored, derived, or retrieved information related to their cryptographic flow.

5.4 Protections and additional context

RASP, certificate pinning, KYC SDKs, and other protections were also part of the context. These layers helped prioritize which applications required further analysis and what techniques would be needed to observe their runtime behavior.

6. Traffic capture hypothesis

With the initial signals sorted, the team compared different traffic samples to confirm that the behavior was consistent. The hypothesis didn't arise from a single request, but from observing the same pattern across several applications.

• The proxy could intercept the communication, but the functional content was still not directly available.

All together, these images reinforced the central hypothesis: the content that the backend processed was not always available to intermediate controls, monitoring tools, or traditional testing from the proxy.

7. Hypothesis by static analysis and initial reverse engineering

With the hypothesis formed from traffic analysis, the next step was to validate whether a correlation existed in the code. In this first part, reverse engineering is approached as part of cross-sectional research, using representative examples from different applications where equivalent patterns appeared.

The visual examples in this section should show encryption helpers, network interceptors, payload serialization, or references to Keystore, fingerprint, or device id in applications different from those discussed in Part 2.

This stage confirmed that the pattern observed from the traffic had a technical basis within the mobile client: the encryption was not just a visible artifact in Burp, but a logic implemented in the client itself.

1. By combining traffic capture, static analysis, dynamic review, and local storage, the team confirmed that the pattern was not isolated.
2. In several applications, a combination of opaque traffic over TLS, client-side logic related to encryption or payload transformation, and local or runtime artifacts were observed that helped explain how the flow was constructed.
3. The pattern confirmed by the research team points to an architectural visibility problem : when content travels encrypted between the client and the backend, intermediate controls can lose visibility if they are not located after the decryption point or if the backend does not apply robust validations on the already normalized content.

That was the question that remained open at the close of this stage: if the client can build, encrypt and decrypt that content, what happens when the team reproduces that flow from their own test environment?

9. What we will see in Part II

In the following publication, the team takes a representative case and shows the complete process: reverse engineering the encryption and decryption flow, extracting values at runtime, reimplementing the routines in external scripts, integration with Burp Suite, and validating the impact when functional content travels encrypted to the backend.

Part I establishes the context and pattern. Part II shows the technical impact when that pattern is combined with a backend vulnerability and controls placed in the wrong part of the architecture.

10. Final Thoughts

This research began as a repeated observation during mobile assessments and ended up confirming a pattern relevant to banking and fintech: additional encryption over TLS can make analysis from a proxy more difficult, but it can also reduce the visibility of intermediate controls if the architecture does not consider where and when the data should be inspected.

Effective security doesn't depend on making traffic difficult to read from the proxy. It depends on server-side validation, proper trust boundary design, and controls capable of evaluating the actual content that the backend processes.

Stay tuned to the following posts and don't forget to follow us!!

Just Mobile Security | LinkedIn

Just Mobile Security — Medium

Just Mobile Security Blog

Juan Urbano Stordeur (@juanurss) / Twitter

Juan Martinez Blanco / LinkedIn

If you need to analyze your application contact us here:

sales@justmobilesec.com | Sales

Any other doubts or questions, don't hesitate to write to us!

info@justmobilesec.com | Contact

Join us! | Jobs

#justmobilesecurity #android #tls #sslpinning #network #intercept #cybersecurity #mitm #mobilesecurity #mobilepentesting #flutter #tungstenic #ia #automated #pentesting #jms