Modern Phone Scammers: Stealing Money with a Phone Call

research vulnerability

In today's interconnected world, mobile applications play a vital role in our daily lives.

person typing on laptop holding phone

They handle sensitive data and facilitate various functionalities, including secure transactions and authentication processes. With the increasing reliance on mobile applications, ensuring their security has become a paramount concern. This blog post describes a vulnerability in a banking application that lets attackers perform unobtrusive money transactions of up to 5.000€ in the name of other users. Furthermore, additional possible attack scenarios that allow personal information to be tapped are also described.

Through this publication, we aim to raise awareness among developers, security experts, and end-users about the importance of adopting secure practices and the danger of installing applications from untrusted sources.

Telephone Banking

SEC Consult recently assessed a mobile banking application that offered users the option to use telebanking features via phone calls. However, on the bank's side, no real person has to pick up the phone - the whole process is carried out by a computer system and the user can initiate a money transfer via voice input or by pressing the dial buttons on the phone. To initiate the call from within the application, the users have to first authenticate themselves using their app password or their fingerprint. Once authenticated, the app generates a One-Time Password (OTP), which is valid for a short duration. Next, the app dials the banking hotline, transmitting the necessary information, including the OTP, by appending it to the phone number. The banking hotline then verifies the received information for validity and proceeds with the call after successful validation. From that point onward, the user is considered authenticated and gains access to perform tasks such as initiating bank transfers of up to 5.000€.

Stealing Money with a Phone Call

The way the application initiates the phone call is vulnerable and can be intercepted and modified by any other installed application. The receiving application is not specified explicitly but rather any application that can handle calls can process it. Any malicious application installed on the device that advertises to handle outgoing calls, can intercept the action to trigger the phone call, retrieve the phone number including the secret OTP, which authenticates the user, and change the payload of the action in such a way that the banking application will stay open without any error messages. The retrieved OTP can then be transferred to the attacker and be used to call the banking hotline. As the OTP authenticates the user and no further checks will be done during the phone call, an attacker can use it to transfer up to 5.000€ to their bank account.

Technical Analysis

In order to understand how the phone number including the secret OTP that authenticates the user can be stolen by a malicious installed application, we first need to clarify what "Intents" in Android are.

What are Intents in Android?

Intents are a fundamental component of Android, enabling messaging between various components of an application or even between different applications. They serve as a fundamental building block of the Android operating system and play a crucial role in enabling various functionalities and interactions.

An intent can be viewed as an abstract description of an operation to be performed, typically consisting of two essential components: the action and the data. The action represents the type of operation to be performed, such as "view", "edit", or "send". The data, on the other hand, specifies the content or target of the operation, such as a specific URL, a file, or a piece of data.

Types of intents in Android

  1. Explicit Intents: An explicit intent is used when the developer knows the specific target component (e.g., an activity, service, or broadcast receiver) that should handle the intent. It explicitly specifies the target component's class name or package name, ensuring a direct and specific delivery.

  2. Implicit Intents: An implicit intent is more flexible and allows the system to determine the appropriate component to handle the intent based on its action and data. Implicit intents are useful when developers want to delegate a task to another component without specifying the exact target component. For example, if an application wants to share an image, it can create an implicit intent with the ACTION_SEND action and the image's data, allowing the user to choose from a list of available applications to handle the sharing operation. If only one application that can handle the specific intent action is installed on the device, the operating system will automatically choose it without user interaction.

Intents are not only used for launching activities or services within an application but also for inter-app communication. They enable developers to leverage functionalities provided by other applications by sending intents with appropriate actions and data. This inter-app integration empowers developers to create rich and interconnected user experiences.

Overall, intents in Android serve as a versatile mechanism for communication and coordination between different app components and enable seamless interactions, data sharing, and inter-app integration.


Intents in Android have various use cases and are a fundamental part of inter-component communication. The following is just an excerpt:

  1. Starting Activities: Intents are commonly used to start activities in Android. By creating an explicit or implicit intent with the appropriate action and data, developers can launch activities within their own app or in other apps. For example, clicking a button to open a new screen or launching the camera app to capture a photo.

  2. Service Invocation: Intents can be used to start or interact with background services in Android. Developers can create an intent to start a service and provide necessary data or commands for the service to execute. This is useful for long-running background tasks, such as downloading files, playing music or performing computational intensive tasks without freezing the UI.

  3. Broadcasting Events: Intents are used for broadcasting events or messages across different components or apps. By broadcasting an intent, developers can notify interested receivers about certain events or trigger actions. For example, sending a broadcast intent to notify other apps about the device's network connectivity change or battery level.

Intent Broadcasts

As mentioned, intents can be broadcasted. To interact with such an intent, a BroadcastReceiver can listen for them and respond appropriately. Broadcasting an intent is like shouting out a message for anyone interested to hear. Any component that's interested in receiving that message can register a BroadcastReceiver with the system to listen for that particular message.

Intent broadcasts are often used for various purposes in Android development, such as system events (e.g., device boot completion), notifying components about changes (e.g., network connectivity, battery status), sending notifications to multiple receivers, or triggering custom events within an application.

Security Considerations

Implicit broadcast intents in Android are of special interest when they are supposed to be used for transporting (sensitive) data to other app components or apps, since they can be intercepted and received by unintended or malicious applications. When an implicit broadcast intent is sent, it is not explicitly targeted at a specific application but rather broadcasted to all applications that have registered to receive that particular type of intent. This can potentially lead to unintended exposure of sensitive information or unauthorized access to certain functionalities.

For example, if an implicit broadcast intent containing sensitive data, such as user credentials or personally identifiable information, is sent, any application with the appropriate permission can intercept and access that information. Malicious apps can exploit this by registering to receive the same intent and retrieve sensitive data without the user's knowledge or consent.

Furthermore, implicit broadcast intents can be used to trigger unintended actions or disrupt normal app behavior. Malicious apps can register to intercept and cancel certain broadcast intents, leading to unexpected consequences or denial of service attacks.

Dual-Tone Multi-Frequency (DTMF) Signaling

In the high-level vulnerability description we mentioned that the generated OTP is appended to the phone number. This is actually not completely true. Instead of simply appending it to the phone number, it is transmitted to the banking system using DTMF signaling.

DTMF allows users to input numeric or alphanumeric characters using their phone's keypad while engaged in a phone call. When a user presses a digit on their phone's keypad, it generates a unique combination of two specific frequencies, known as dual-tone multi-frequency signals. Each digit corresponds to a specific pair of frequencies. These signals are transmitted over the voice channel of the phone call and decoded at the receiving end. DTMF signaling is widely used for various purposes, such as automated phone systems, interactive voice response (IVR) systems, phone banking, entering passwords or PINs, conference call access codes, and menu navigation within voice-based systems. The receiving end, typically a telephone exchange or a computer system, decodes the DTMF signals and processes the entered digits accordingly. This allows users to interact with automated systems, enter numeric inputs, or navigate through menu options during a phone call. DTMF signaling has become a standard method for inputting digits during phone calls and is supported by most modern telecommunication systems and devices, including landline phones, mobile phones, and Voice over IP (VoIP) services.

The call intent used to initiate the call to the banking hotline already includes the OTP which authenticates the user via DTMF Signaling.

permission request of a malicious application

Intercepting the Intent

An attacker can build a malicious application that observes all outgoing calls using a broadcast receiver.

For this, the attacker's application requires the android.permission.PROCESS_OUTGOING_CALLS permission.

This permission is classified as "dangerous" by Android and must be explicitly granted by the user to the application. However, since this permission is also required by many popular messenger apps, the likelihood of a user granting this permission to the application is correspondingly high.

The following screenshot shows this permission request of a malicious application.

A broadcast receiver is defined in the AndroidManifest.xml file of the app, which is informed about outgoing calls using an intent filter.

Broadcast Receiver

        <category android:name="android.intent.category.DEFAULT"/>
        <action android:name="android.intent.action.NEW_OUTGOING_CALL" />


The receiver can extract the dialed phone number, including the DTMF signal, from the intent when an outgoing call is made. Additionally, the receiver can remove the dialed phone number from the intent. As a result, the outgoing call is suppressed, and the OTP retains its validity.


public class CallReceiver extends BroadcastReceiver {
    public void onReceive(Context context, Intent intent) {
        Log.d("CallReceiver", "Initiated call detected");

        // extract the dialed phone number from the call intent
        String phoneNumber = getResultData();
        if (phoneNumber == null) {
            phoneNumber = intent.getStringExtra(Intent.EXTRA_PHONE_NUMBER);

        Log.d("CallReceiver", phoneNumber);

        // set the dialed phone number to null to prevent the outgoing call


An attacker can now utilize the extracted data to impersonate the user over the phone to the bank.

Stealing the Intent Data

The malicious application can masquerade as a benign app and be installed alongside the user's vulnerable banking application on their device. When the user intends to utilize the telephone banking feature of the banking app, they are prompted to authenticate using their set password or fingerprint. After authentication, the device's phone application briefly opens and immediately closes since the received intent no longer contains a phone number. The banking app reappears seamlessly, without displaying any error messages. The user remains unaware that another installed application on the device intercepted the call, including the OTP.

Technical Mitigation

To protect against such an attack, intents containing sensitive information should always be explicitly sent to a specific target application. In the present case, this would be the phone application. However, since different OEMs and users may utilize their own phone applications, it is not possible to set the package name of the target application in advance, as the default Android phone call application might not be installed and different vendors might use different phone apps. In this situation, the preferred solution is to implement VoIP (Voice of Internet Protocol) in the application, so no implicit intent has to be sent at all. This enhances the user experience with the application, as the user does not have to leave the application to use the phone banking functionality.

Technical Conclusion

Implicit intents in Android applications have long been valued for their convenience and flexibility. However, their inherent security risks cannot be ignored. In this blog post, we have examined the dangers associated with implicit intents, focusing on a specific scenario where a malicious app intercepts sensitive data transmitted through DTMF signals during a phone call.

The consequences of falling victim to such an attack can be severe, ranging from identity theft to financial damage. To safeguard against these threats, developers must adopt secure coding practices that prioritize the use of explicit intents, ensuring that sensitive data is transmitted only to the intended recipient.

As the Android ecosystem continues to evolve, it is vital for developers, security experts, and users to collaborate and prioritize security measures. By promoting awareness and implementing robust security practices, we can enhance the overall protection of sensitive data and fortify the integrity of Android applications.

Let this blog post serve as a call to action, inspiring a collective effort to secure our digital experiences and create a safer Android ecosystem for all.

Man looking at phone

Social Engineering Attacks

With this vulnerability it is not only possible to read the phone number of the initiated call, the phone number can also be modified. This allows an attacker to redirect the calls from the banking application to an arbitrary number. An attacker could exploit this to redirect calls to their phone number and impersonate a bank in order to obtain further private information (perform a so-called social engineering attack) from the user. Because the phone call was initiated from the legitimate banking application this attack is difficult to detect even for security-aware users.  


To protect against such an attack as an end user, it is important to not install applications from untrusted sources. It is always recommended to download apps from the well-known stores only, as a pre-screening of the apps takes place. If a malicious application does make it through the security checks of the stores, it can still be classified as malicious afterwards and users who downloaded the application will be notified. 


The consequences of falling victim to such an attack can be severe, ranging from identity theft to financial damage. 

By staying vigilant and exercising caution when granting permissions to applications, end-users can mitigate the risks. Additionally, staying informed about potential security vulnerabilities and regularly updating devices and applications can help maintain a safer digital environment.

Let this blog post serve as a call to action, inspiring a collective effort to secure our digital experiences and create a safer Android ecosystem for all.


This blog post has been written by Fabian Densborn and Leonard Eschenbaum and published on behalf of the SEC Consult Vulnerability Lab.

Are you interested in working at SEC Consult?

SEC Consult is always searching for talented security professionals to work in our team.