Prevent hackers from performing fraudulent transactions after asking the victim to install a remote support tool.
Get in Touch Download Whitepaper"Fake Support" Calls
So-called "Fake Support" attacks target individuals and companies alike. The remote attacker, pretending to call in the name of a financial institution support, or a generic vendor support (e.g., Microsoft), asks the victim to install a remote controlling application (such as TeamViewer, AnyDesk, etc.). The victim is persuaded to follow the instructions from the attacker, as they seem to try to fix computer problems (which are typical) or checking if all is well following an update on the financial institution end. The attacker pretends to want to assist the victim in making sure that they can still access the e-banking portal and perform transactions.
Once the “test” transaction is submitted successfully, the attacker takes control of the victim's machine through the remote software, asks the victim to leave the computer on for a few minutes, and proceeds to perform a number of payments, typically to the same money mule account.
Nothing suspicious detected by the fraud engine: the user manually approves a first transaction.
The attack is successful, for a number of reasons. First of all, the fraud detection engine of the financial service typically works on the following data points: IP addresses/location, Abnormal user behavior, Unknown recipients whitelisting. Second, unlike remote phishing attacks, or session hijacking attacks, this information is reported to the fraud engine.
IP Address
The usual victim's IP address/location, overall generating from known networks (the IP address is the victim's ISP address, and not the remote attacker's).
Abnormal User Behavior
The victim performs standard operations, such as entering a new payment and approving it when the step-up process is initialized, including performing the relevant MFA step.
Unknown Recipients Whitelisting
Following the first payment, the money mule account is whitelisted and, no additional steps are required for performing subsequent transactions to the money mule account.
The feedback loop can be performed backend to frontend (typically used during PoC), or backend to backend (typically used for production systems). Furthermore, the solution can also be integrated with existing fraud detection mechanisms already in use by the financial institution.
Backend to Backend
Backend to Frontend
The blitz.js component needs to be embedded on the e-banking website pages and initialized with a random identifier, that persists throughout a user session. We refer to the technical documentation for a correct initialization and usage.
The JavaScript component will perform the following operations, reporting to the Futurae server:
The Blitz JavaScript operations have been tested on a variety of browsers (Chrome, Firefox, Safari, Opera, Internet Explorer down to IE11). Incompatible browsers would fail gracefully, with no degradation on user's experience (and, clearly, no possibility of attack detection).
The Futurae servers analyze in real time the information captured and detect anomalies
The Futurae Server accepts incoming measurements only when properly authorized by a shared API key. For each session that is created, the server measures a variety of analytics and reports back through the feedback loop channel whether a remote user is interacting with the website.
The Futurae server does not store any sensitive user information or Personally identifiable information and is hosted on a FINMA-compliant Swiss cloud data center.
Blitz Detection Analysis
A visualization of two user sessions can be seen, as follows. First a legitimate session, second an attack session.
Try the Futurae Authentication Suite today - 3 months for free.