Webinar Recap: Phishing on Mobile - From Fraud to Deterrence

Guardsquare Product Manager Anton Baranenko recently took an in-depth look at how phishing campaigns are designed, how they typically unfold, and what can be done at each stage of an attack to keep mobile applications secure.

Phishing remains one of the most effective tools for launching mobile fraud attacks. Today’s campaigns may employ sophisticated phishing manipulations with malware to trick users and ultimately steal sensitive data and then monetize it.

The challenge is that no security solution can block every phishing attempt. Mobile app attackers can shift tactics from tampering and malware injection to API abuse and cloned applications. Deterring these attacks requires making data as hard to exfiltrate and exploit as possible.

Two methods of phishing

There are two main ways for an attacker to approach a phishing campaign. The first is by targeting lots of people. By choosing this approach, the campaign funnel will become quite aggressive. This means that at every stage of the phishing funnel, there will be many people who grow suspicious and stop participating. The funnel will be very wide at the top (lots of potential targets) and quite narrow at the bottom (many fewer actual victims).

As an alternative, you can target fewer potential victims by focusing on people for whom you have additional information, making your campaign much more believable. The top of the funnel on your phishing campaign will become much smaller, but your selection and conversion process is going to be much more effective because the messages you use will be much more convincing. This approach is called spear phishing.

Sometimes you’ll see in the press that a certain company leaked data about their customers. For example, a couple of years ago there was an airline company that leaked data on ticket purchases for a certain set of flights. The company might say after the breach that it’s not really a problem because credit card data and credentials weren’t leaked.. But what will happen later is that this leaked data is going to be used to design customized spear phishing campaigns.

Let’s look at how that works…

The Line

Phishing campaigns start with a social component. Before any techniques like overlays or accessibility services and before any malware takes effect, attackers must first employ some kind of social approach. The goal of the social component is to make the victim take the first step that allows the rest of the campaign to unfold.

Social components typically include three steps. First, the attacker needs to get a victim’s attention. In Figure 1, the example on the left (“Hey check out this new cat video!”) casts a wide general net to entice potential targets at random. With this approach, the attacker doesn't need to know anything specific about the demographics of targets. Success typically depends on approaching high volumes of targets with these campaigns.

The spear phishing campaign example on the right, however, immediately takes a more personalized and convincing approach. Subsequently, it’s much more likely to capture the target’s attention. It uses the victim’s name. It uses a fact from their life that (they’ve previously purchased banking forum tickets). It even knows how much the tickets cost. These details make the initial approach much more believable and therefore more likely to gain the interest of the target.

Figure 1: Phishing “Line”

The Sinker

The goal of the next stage of a phishing campaign is to get the first action, such as by clicking a link or scanning QR code. This action typically will not immediately compromise your security (though there have been rare instances where clicking a malicious link starts to do harmful things to a device). But it gives the attacker important feedback about which message attracted your attention and successfully triggered a response, and this way they can iterate and improve their methods. It works the same way as marketing telemetry, measuring click rates to determine which versions of a banner ad work better than others. With the help of GenAI, a phishing attacker can even automate A-B tests that will continuously improve a phishing campaign for maximum effectiveness.

Figure 2 shows how the general phishing campaign (left) differs from a spear phishing campaign (right) at this stage of an attack.

Figure 2: Phishing “Sinker”

The Hook

When a victim clicks the link, they will be taken to a place where they will be asked to perform an action that will compromise their security. In the general phishing example on the left side in Figure 3, the victim is asked to download a “secure video player” to watch the promised cat video. But instead of a video player, the victim instead will download malware that will infect the device and power the campaign going forward.

The spear phishing example on the right side uses a different approach. The attacker already knows a lot about the victim, including their name and which applications they’re using. At this point, an attacker might want to immediately “go for the win” and trick the target into providing their login credentials (or some other sensitive information). The victim in this example clicked to fix a seemingly legitimate issue (a potential problem with a bank payment). The next step would logically be to see some kind of support web page from the bank. The victim is asked to login to their bank account to get the support they need to fix the transaction. This login screen will look exactly like the legitimate bank app or wallet. But if the user name and password are entered here, these credentials will be sent directly to the attacker.

Figure 3: Phishing “Hook”

In both examples, once the action is taken by the victim, the attacker is able to switch to the technical phase of the campaign. First, they will exfiltrate the victim’s credential data. Then they will reuse those credentials to perform a fraudulent action, such as gaining control of the victim’s bank account and draining their funds.

Let’s break this process down into each step to understand the specific attack techniques before we look at how to counter with effective defensive strategies.

Attack Techniques: Getting the Data

In the general phishing campaign examples above, the attacker doesn’t know anything about their targets – not even their names, let alone which applications and services they’re using. So the simplest method to steal credential data would be using malware to automate the process.

There are different common techniques that malware can use to capture and exfiltrate sensitive data. For example, a fake accessibility service offers a perfect way to maliciously monitor what’s happening on the device. The malware can then see which applications the victim is running and it can get all kinds of information from those apps.

Some applications might have secure PIN pads that prevent fake accessibility services from stealing credential data. In those instances, there are other techniques that an attacker can use – such as an invisible layer on top of the PIN pad screen, which is called an overlay. Overlays can capture credential data entered by a victim in the app (e.g., user names, passwords, account numbers, credit card details). It can also capture statistical information about which applications are being used at scale to improve the effectiveness of the campaign going forward.

Figure 4: Fake accessibility service and overlay attacks

Hookbot was a simple but effective type of malware for its time because it could disguise itself as several different types of applications through the use of fake screens. It would use the accessibility service to determine which applications the victim had. As soon as the real application was launched, Hookbot would pop-up a fake screen on top of that application. With modern AI-based development tools, it’s very easy to create fake skins or fake screens to impersonate a real application and trick the user into entering their private information.

Figure 5: Hookbot malware can simulate the screens of many popular financial apps.

Defensive Strategies Against Phishing

Because there is no universal solution to prevent phishing, we need to focus on deterrence – using two main strategies that mirror the aforementioned attack techniques:

1. Make data very hard to exfiltrate.
2. Make any successfully stolen data very hard to reuse.

Making data hard to exfiltrate

If an attacker uses malware to exfiltrate credentials and other sensitive information, this is pretty universal. Malware can arouse suspicion, but mainly at the stage of installation. Assuming a campaign gets beyond that point, we need to defend against all the different tools that malware could maliciously use to steal data, such as:

• Accessibility services
• Screen recording
• Overlays (aka “View Injections”)
• Activity injections

Defenses against these kinds of attacks require application protections like runtime application self protection (RASP), which injects different kinds of security checks in the mobile app code, as well as real-time threat monitoring capabilities to detect malicious activities.

If a mobile application uses these sorts of malware defenses, the attacker may next try to reverse engineer and disable the built-in malware checks. They can then use spear phishing to trick the target into installing a repackaged defenseless version of the application. Another option for an attacker would be to reverse engineer and maliciously modify the application. Tampered clone apps can be distributed via spear phishing in the same way as defense-disabled apps.

To protect against reverse engineering and tampering attacks, applications need code hardening, which is essentially multiple layers of obfuscation and encryption techniques that make it extremely difficult for an attacker to understand the application code.

But even with sophisticated malware security checks (RASP) and anti-tampering protections (code hardening), there are still things an attacker can try. Even without being able to successfully reverse engineer the actual application, they can create a look-alike that impersonates a legitimate app. It doesn’t necessarily need to function like the original app; it just needs to convincingly simulate the login in order to steal credentials. The most important defensive measure that you can use to prevent this sort of attack method is multi-factor authentication (MFA). Just keep in mind that not all methods of MFA are equally effective or 100% foolproof (for example, text messages can be spied on to also steal authentication codes).

Making stolen data hard to reuse

Once an attacker gets ahold of a victim’s banking credentials, they now have two main options for next steps:

1. They can manually paste your information into your original application and try to impersonate you.
2. They can automatically send your data to the bank servers, attempting to simulate your environment.

Manual impersonation is very simple. Someone with terminal access just has to enter the login and password information, and then the account can quickly be drained of funds. It’s not very scalable, but it’s very reliable. An effective defensive technique to counter manual reuse of stolen data is device binding. This simply means that the legitimate user’s application must be used on their specific mobile device in order to validate account access and any subsequent transactions. Device binding provides a safeguard against an attacker reusing credentials to login on a different device. Another type of defense that is frequently used in banking apps is called “know your customer” (KYC) which verifies the user’s identity through things like imaging or biometric input.

With automatic impersonation, a bot will use the stolen data to directly interact with a server API. This bypasses the banking application altogether by feeding your credentials directly into the servers. Some bots even automatically prepare deepfake images from the victim’s Linkedin profile or other social media photo/video libraries in order to bypass KYC checks.

So how does the application defend against an attack where the application itself is bypassed? An effective defensive technique against these sorts of server-side attacks is called application attestation. This defensive technique can ensure that only legitimate mobile applications can interact with APIs and access backend services. App attestation uses token exchanges that allow only genuine mobile apps to call server APIs and block bot scripts, unauthorized third-party clones, and tampered/modified apps from using stolen credentials or performing any other malicious activities on the server-side.

Figure 6: How Guardsquare Application Attestation works.

Phishing Attacks Require Disciplined Defenses

It’s important to remember that there is no “silver bullet” to protect mobile applications from phishing attacks. The next best thing, however, are the methods and discipline with how you secure your mobile apps.

Guardsquare offers a comprehensive set of all the defensive techniques referenced above:

• Device binding
• Anti-reverse engineering measures and code obfuscation
• Advanced RASP
• Server-side monitoring and application attestation

Our portfolio includes DexGuard (Android) and iXGuard (iOS) mobile app protection solutions, ThreatCast threat monitoring and app attestation, as well as AppSweep mobile application security testing (MAST).

To learn more about phishing attacks and protection, access the full webinar here.

Executive Summary (TL;DR)

• Today’s phishing campaigns may employ sophisticated tools like automated bots, malware, and adaptive strategies from GenAI to exfiltrate credentials and ultimately take over a user’s account.
• Deterrence first requires making data very hard to exfiltrate through mobile app security capabilities like RASP, code hardening, and threat monitoring.
• As an additional protection, developers can make any successfully stolen data very hard to reuse through mobile app security that uses device binding and application attestation.