11 min read • Deepfake Detection • Published on October 6, 2026

Social Engineering Fraud: Scam Calls, Remote Access

Social engineering fraud tricks people into handing over money or account access themselves. In its most damaging form, a scammer calls the victim, persuades them to install a fake app, then watches the screen and moves money remotely. Because the real customer passes every login check, defences must also read the device, such as an active call or screen sharing.

Social engineering fraud is any scheme where the criminal manipulates a person instead of breaking a system. Rather than hacking a database, the fraudster simply convinces the customer to act. The victim reveals a password, approves a payment or installs a tool that hands over control.

Most schemes follow a few repeatable patterns, and many campaigns combine several of them:

Type	How it works	What the fraudster wants
Vishing (scam calls)	A caller poses as a bank, tax office or police officer and creates urgency	First a one-time password, then a transfer or an app install
Smishing and chat scams	A text or chat message carries a link, usually with an urgent reason to tap it	So the victim visits a phishing page or downloads a fake app
Impersonation	The scammer copies a trusted brand, agency or even a family member	Trust, because trust makes the next request feel normal
Remote access scams	The victim installs an app that lets the scammer see or control the phone	Full control, so the fraudster can act inside real sessions
Authorised push payment scams	The victim sends the money personally, believing the story	A payment that, in many markets, banks treat as authorised

The last two types cause the largest losses for banks and e-wallets. In both, the customer is genuine, so the usual identity controls have nothing to catch.

How a Scam Call Turns Into an Account Takeover

How a scam call becomes an account takeover - the hook, the install, the call, the permissions, the capture and the takeover

Remote access scams in Southeast Asia now follow a recognisable script. Each step looks harmless on its own, which is exactly why victims keep going.

The hook. First, a message arrives from an account that looks like a tax office, a bank or a courier, warning of a problem that needs action today.
The install. Next, the message links to an installation file outside the official app store, presented as the “official app” for fixing the problem.
The call. Then a scammer phones the victim, often posing as an officer, and stays on the line to guide every tap.
The permissions. During the call, the victim grants the fake app powerful permissions, such as screen recording, because the caller says verification requires it.
The capture. After that, the app records PINs, passwords and one-time passwords as the victim types or receives them.
The takeover. Finally, the scammer uses the captured details, or controls the phone directly, to empty the account into mule accounts.

In other words, the phone call is the engine of the fraud. Without a live voice creating pressure, few victims would grant those permissions.

Case Study: Fake Tax-App Scams in Indonesia (GoldFactory, 2025-2026)

A campaign tracked by Group-IB shows this script running at national scale. According to Group-IB, it began in July 2025 and escalated in January 2026, when Indonesian taxpayers were busy with the annual filing season.

Coretax, the tax authority’s new system, is a website and has no official mobile app. Even so, scammers built fake Coretax apps and contacted victims through WhatsApp accounts that impersonated the tax authority. Once installed, the fake app froze the screen while it collected device details. Shortly afterwards, a “tax officer” called the victim and pressed them to settle an alleged tax debt immediately.

Meanwhile, the malware asked for Accessibility and SMS permissions and recorded the screen continuously. Group-IB linked the operation to the GoldFactory group and to two malware families, Gigabud.RAT and MMRat. With that access, the fraudsters logged into victims’ bank accounts and moved funds through mule networks. In total, the same infrastructure impersonated more than 16 brands, including government services, airlines and pension funds.

According to Group-IB, total losses across those brands reached an estimated USD 1.5 million to 2 million. Note that the firm extrapolated this figure from observed infection rates rather than counting cases. Later, in September 2026, Group-IB reported a newer Gigabud variant. It creates an Android work profile and runs a tampered banking app inside it, away from the genuine app’s checks.

The lesson for banks and e-wallets is uncomfortable. The attackers did not need any vulnerability in the banking app. Instead, the victim did every step, on their own phone, while a stranger talked them through it.

Why the Victim Passes OTP, Device Binding and Biometrics

Most digital banking controls ask one question: is this really the customer? In a coached scam, the honest answer is yes. That is why the scam slips through.

Control	What it proves	Why the scam still gets through
One-time password	The customer holds the registered phone	The victim reads it out, or the malware captures it as it arrives
Device binding	The session comes from the customer’s own device	Indeed, the scam runs on that very device
Face and liveness check	A real, present person matches the account owner	Yet that person is the victim, acting under instruction
PIN or password	The user knows a secret	However, screen recording captures the secret as the victim types it

Each of these controls still works as designed. Liveness checks, for example, still stop fake faces and replayed videos. But social engineering changes the question. Rather than “is this the customer?”, the bank now needs to ask “is the customer acting freely, alone, on an unaltered app?”

The device can partly answer that second question. While the scam is happening, the phone usually shows conditions that a normal banking session rarely has.

Signal	What it can indicate	When it matters most
Active call	The customer is on a phone call, possibly with someone coaching them	During transfers to new payees and limit changes
Screen sharing	Meanwhile, someone else may be watching PINs and one-time passwords	At login, PIN entry and transfer confirmation
VPN or proxy	Someone is hiding where the session really comes from	Especially when it appears on a known customer’s device for the first time
Cloned app	A second copy of the app is running, so someone else may operate it	At login and on any change of device or credentials
Virtual OS or secondary user	The app runs in a separate environment, out of view of normal checks	Likewise at login, and again before high-value transfers
Debug mode	Someone has prepared the device for inspection or automation	Mainly as supporting context, because it is weak on its own

No single signal proves a scam. Plenty of customers bank while on a call. Still, context changes the picture. An active call, screen sharing and a large first transfer to a new payee tell a very different story from a routine bill payment.

For teams building this layer, Verihubs Device Intelligence reports active call, screen sharing, VPN, cloned app and virtual OS among its device signals. These signals do not replace malware scanning. Instead, they tell your risk engine what is happening around the session at the moment it makes a decision.

Combine Device Signals With Transaction Context

Device signals become far more useful next to transaction data. In particular, check three things. Is the payee new? Is the amount unusual for this customer? And did someone open the recipient account only recently? A transfer that ticks all three, during an active call, deserves attention. These checks fit naturally into existing banking fraud controls rather than replacing them.

Intervention Design: Warn, Delay, Block

Scam intervention design - log, warn, delay and block responses matched to active call and screen sharing signals

Once the signals are in place, the hard part is deciding what to do with them. Too much friction drives honest customers away, while too little lets the scammer finish the script. The answer is to match the response to the combination of signals and the action at stake.

Situation	Response	Why
Active call during login or a balance check	Simply log it, with no friction	Because the risk is low until money moves
Active call during a transfer to a new payee	Warn with a scam-specific message	So the warning can break the caller’s script at the right moment
Active call plus screen sharing on a high-value transfer	Delay the payment, then confirm through a separate channel	After all, time is what the scammer cannot afford
Screen sharing while the PIN or a one-time password is on screen	Block that screen until sharing stops	Otherwise the secret leaks the moment it appears
Cloned app or virtual OS on a withdrawal	Block, then ask for verification in the genuine app	Since nobody can trust the app environment itself

Warnings That Actually Interrupt the Script

Generic pop-ups fail because victims tap through them while the caller says “just press continue”. Effective warnings are specific. For example: “Is someone on the phone asking you to move this money? Banks and tax officers will never ask you to do this.” Ideally, the message should appear before the final confirmation and require a deliberate choice.

Delays work for a similar reason. In Singapore, for instance, banks now make customers wait at least 12 hours before a new digital token goes live on a device, according to the Monetary Authority of Singapore. That kind of cooling-off period gives the victim time to hang up, talk to family and realise what is happening.

Finally, any block needs a clear, fast route back for genuine customers. Treat these rules as one layer within a layered fraud prevention setup, where case teams can review and release legitimate payments quickly.

A common example is a fake tax officer who calls a taxpayer and persuades them to install a fake tax app. The app then records the screen, so the scammer can capture banking details and transfer the money out.

The main types are vishing (scam calls), smishing and chat scams, impersonation, remote access scams and authorised push payment scams. Many real campaigns combine several of them in one attack.

How does a remote access scam work?

The scammer convinces the victim to install an app that can see or control the phone. Once the victim grants the requested permissions, the scammer watches every PIN and password the victim types. Then the scammer moves money using the victim’s own device.

One-time passwords prove the customer holds the registered phone. In a social engineering scam, the customer does hold it, and the scammer either asks for the code or captures it with malware on that same phone.

Can a banking app tell when a customer is on a call?

Yes. A banking app can detect that a phone call is active during a session without accessing the call’s content. Combined with signals such as screen sharing and a new payee, an active call helps flag possible coaching.

Should banks block transfers when a customer is on a call?

Usually not outright. Many customers bank while on a call. A better approach is to warn on transfers to new payees, delay high-value payments when several risk signals appear together, and block only the riskiest combinations.

Social engineering fraud succeeds because it turns the customer into the attacker’s tool. Passwords, one-time codes and face checks all confirm the right person is present, and in these scams that is precisely what the fraudster wants.

For that reason, defences need a wider view. Read the device for signs of coaching and remote viewing, connect them with the transaction, then respond in proportion: warn, delay or block. Teams that do this protect customers at the one moment that matters, before the money leaves.

Worried that scam calls are draining customer accounts despite strong logins? Talk to Verihubs about adding device risk signals to your payment flows.