co-authored by Nadav Katzenell, Head of Machine Learning, Data & Research, IBM Trusteer
This article explores how an aggressive and elusive remote overlay PC malware that is attacking Latin American banks met its match in a solution built from behavioral biometrics, deep research, reverse engineering and finely tuned threat modeling.
It’s not easy to beat cunning malware at its own game.
Wrapping up 2018 with a proof-of-concept project for a banking client, the IBM Trusteer fraud analytics team spotted malicious activity that was out of the ordinary for the bank. While the project easily detected phishing and other account takeover fraud mechanisms, one remote overlay malware threat was very hard to detect on user devices. Recent regional media reports on banking fraud had made the malware an important point of focus for the bank. Frustrated but undaunted, the Trusteer research team got to work.
The malware in question was no small matter, its variants attacking many banks in the region. As reported by 24 Horas, banks are facing ever higher stakes to protect against fraud: Chile’s supreme court recently decided for a bank’s customer, ordering the bank to return to the customer all funds that an attacker had stolen from the customer’s account. While this may be the law in many countries, it was not customary in Chile.
Why was this specific remote overlay malware more difficult to detect? With the daring of a fox and versatility of a chameleon, it managed to circumvent most standard remote access Trojan (RAT) detection tools. Once the malware identified a banking session, it pushed overlay screens to the unknowing end user, plastering them over the original browser screen where the user had initiated an online banking session.
The malware’s operator could then receive notification of any provided credentials and have a heyday, taking over the victim’s device with the RAT capabilities and transferring funds or committing other fraud within the authenticated session.
Malware overlay looking like an authentic — and important — notification from the bank urgently requests the user’s physical token data
Anatomy of a Counterattack
To better understand the malware and its tactics, our team had to build an environment that could replicate its behavior and effects.
Step 1: Recreating the Attack
The first step was to build a fully working client-server malware lab, including a command-and-control (C&C) center, so the Trusteer team could recreate the attack and carry out deep research into the malware’s in-session behavior.
Step 2: Modeling
The team focused on recreating the malware session on the bank’s actual web application. By analyzing the behavioral biometric data throughout the affected sessions, the researchers were able to track anomalies, develop the features and devise an algorithm to build a model for detecting the attack. The team tested the model on both the bank’s recorded sessions and the lab-built malware. The assembled model started producing favorable lab results.
Step 3: Activation and Validation
At this point, with the working malware on hand, the team activated the mature model on the bank’s applications in production. They worked with the bank to refine qualifying questions posed to end users to ensure the most accurate outcome. Then the wait for feedback from the bank began — and the results were not long in coming. Within 24 hours, the first alert indicating detection of the malware was received, followed by a steady stream of detection instances. Fraud rates at the bank fell noticeably within two months.
To keep pace with the malware’s dynamic nature, the team designed the model for fast implementation of ongoing — even daily — updates and return to production. The model is designed to detect different variants of remote overlay malware common to the region.
The fraudster has captured the end user’s login and physical token data, and is now attempting to pass through the bank’s SMS-based third-factor authentication
Good for the Village
A boon to the bank that needed it, the solution can now be applied to other banks facing the same cyberthreat. Implementation involves a consolidated process that adapts the solution to the organization:
- Collect the relevant behavioral data, including addressing any necessary legal amendments.
- Validate that the relevant data collection takes place on the pages subject to attack.
- Activate the model and validate the results.
- Implement policies relevant for that organization.
- Monitor and fine-tune the results.
- Go into production.
IBM Security report identifying the remote overlay malware and its characteristics, and confirming that IBM Trusteer Rapport protects against this threat
“Several key factors contributed to the project’s success,” observed Nadav Katzenell, head of machine learning, data and research at IBM Trusteer. “While the model uses behavioral biometrics, what really worked here was our ability to take a layered approach that included not just the behavioral data, but also deep research and reverse engineering experience, combined with powerful and flexible data collection.
“It’s this mix,” explained Katzenell, “that empowered us to turn data into an ally and build a model that was able to hone in on the threat. And like a gift that keeps on giving, the validated solution and mechanism we built means our clients are prepared for the next remote overlay threat.”
Attending Cyber Week’s FraudCON 3.0? Join the Trusteer session to learn more about how a layered AI infused solution gives the context to outwit fraud and improve your customers’ experience.
The post How a Cunning Remote Overlay Malware Met Its Match appeared first on Security Intelligence.
