This post was made possible through the research contributions of Amir Gendler.

In our most recent research in the Latin American (LATAM) region, we at IBM Security Lab have observed a surge in campaigns linked with malicious Chrome extensions. These campaigns primarily target Latin America, with a particular emphasis on its financial institutions.

In this blog post, we’ll shed light on the group responsible for disseminating this campaign. We’ll delve into the method of web injects and Man in the Browser, and how Telegram is utilized to transmit data about the compromised machines and share more about the campaign.

Malicious Chrome extensions pose a significant threat beyond mere annoyance. These sophisticated tools can perform various operations on a victim’s machine, such as gathering technical information from the compromised browser, capturing screenshots of active browsing tabs and accessing the browser’s clipboard to overwrite its contents. Additionally, they can inject malicious scripts into web pages, steal login credentials and cookies, track browsing history and redirect users to phishing sites. The versatility of these extensions makes them potent tools for cyber criminals, capable of executing a wide array of harmful activities with minimal detection.

To ensure its persistence, the malware employs a flexible command and control (C2) system and adaptive configuration, often communicated via a Telegram channel. The ultimate objective of these malicious activities is to install a harmful browser plugin on the victim’s browser and use the Man in the Browser technique. This allows the attackers to illegally collect sensitive banking information, along with other relevant data such as compromised machine information and on-demand screenshots.

Who is CyberCartel?

Since 2012, the cyber criminal group CyberCartel has been active in Latin America, recently emerging with a new threat. Instead of developing its own malware, CyberCartel uses Malware-as-a-Service from established malware families. Their latest variant targets Chromium-based browsers like Google Chrome, focusing on high-value entities such as government offices and financial institutions. They employ sophisticated techniques to avoid detection, maintain long-term access and inject phishing sites into legitimate sessions. Additionally, they trick users into downloading malicious files from domains resembling legitimate government or billing websites, such as facturacionmx[.]autos and facturacionmexico[.]net (factura in Spanish is bill).

Are web injects still alive?

Web-injects, a favored technique employed by various banking trojans, have been a persistent threat in the realm of cyberattacks. These malicious injections enable cyber criminals to manipulate data exchanges between users and web browsers, potentially compromising sensitive information. So, are web injects still alive? The answer is a resounding yes.

The scale of threat activity is vast, affecting more than 40 banks across North America, South America, Europe and Japan. The intention of the web injection module is likely to compromise popular banking applications and, once the malware is installed, intercept the users’ credentials to then access and likely monetize their banking information.

Web injects are back on the rise. They are powerful malicious tools integrated with multiple banking trojans that permit a threat actor to bypass two-factor authentication (2FA) and compromise a user’s bank account. The primary methods used by threat actors to distribute banking web injects are phishing and exploit kits.

In our scenario, the method uses the same web injects technique as we mentioned in our last blog. But now, browser-based extensions are mimicking Google Drive extensions and can employ web injects to pilfer confidential data from the compromised system. Additionally, Telegram is also being utilized as a resource for updating Command and Control (C&C) servers.

Malicious Chrome extension campaign

The first campaign related to the LATAM region is a generic malware that uses a malicious Chrome extension to inject it into the victim’s machine and steal sensitive information. In the past, we saw similarities in different malware. You can find more information here.

Main Features Attack:

TTP:

• The Victim unknowingly visits a phishing website and downloads a file
• The victim clicks on a file (fake pay tax document) not realizing it’s malicious
• Their machine becomes infected with malware as a result
• The malware proceeds to install a rogue extension on the user’s Chrome browser
• Updates and configurations are disseminated via a Telegram channel by the threat actors
• The Victim logs into their bank account, unaware of the lurking danger
• The malicious extension includes an internal script designed to steal the user’s information
• The stolen information is then sent to a Command and Control (C&C) server

Malicious Chrome extension mimicking Google Drive

In this section, we will focus on the malicious Chrome extension. Once the user is infected with the malware, the malware is added to the Chrome browser extension by the name of Google Drive (which is fake).

(attached is the content of the malicious extension)

Manifest.json:

The manifest.json file for a Chrome extension describes various properties and permissions required by the extension. Here’s the explanation of the permissions specified in this manifest file:

• Scripting: Allows the extension to execute scripts on web pages
• WebNavigation: Allows the extension to observe and react to navigation events within the browser
• System.cpu: Grants access to information about the system’s CPU
• System.display: Provides access to information about the system’s display
• System.storage: Allows access to information about the system’s storage devices
• System.memory: Grants access to information about the system’s memory
• Management: Enables the extension to manage other extensions, apps and themes
• Storage: Allows the extension to use the Chrome Storage API to store and retrieve data
• Cookies: Provides access to read and modify cookies
• Notifications: Grants the ability to display notifications to the user
• Tabs: Allows the extension to interact with browser tabs, such as getting their information or creating new tabs
• History: Grants access to the user’s browsing history
• WebRequest: Allows the extension to observe and analyze web requests
• DeclarativeNetRequest: Permits the use of declarative rules to block or modify network requests
• Alarms: Allows the extension to schedule code to run at specific times or intervals
• ClipboardRead: Grants the ability to read the content of the clipboard
• ClipboardWrite: Allows the extension to write data to the clipboard
• Windows: Grants access to interact with browser windows
• UnlimitedStorage: Allows the extension to use an unlimited amount of storage

These permissions allow the extension to perform a wide range of actions, from interacting with system resources to manipulating web content and user data. The extension appears to be quite powerful, with the ability to access and modify many aspects of the user’s browsing experience and system information.

Content Scripts:

These are also malicious scripts that the extension runs on specific web pages. In this case, the extension can inject scripts on all websites to enhance or change the content:

• Main script: The core script that runs on every page
• Email scripts: Specific scripts that are injected into platforms such as Gmail, Hotmail and Yahoo Mail

This is an example of a fake verification code from a bank:

This script is designed to run on Gmail and modifies the content of emails related to banking withdrawals. It performs the following actions:

• Check if the user is on Gmail
• Defines the bank’s function:
  • Finds and replaces specific text related to withdrawal requests
  • Updates memo fields to show a message about authorizing a new device
  • Extracts additional information from styled div elements

Background Scripts:

The extension also runs a background script that operates behind the scenes, helping it manage tasks and stay responsive even when you’re not actively using it.

Network Request Rules:

The extension has rules to manage network traffic, such as blocking certain types of content. These rules can be enabled or disabled as needed.

Config.js:

It includes default settings for how the extension works. It sends a request to get the current domain of the command and control (C2) server.

The code dynamically updates the application’s domain configuration based on the latest message from a specified Telegram chat. Using a configuration file, it either retrieves a default URL or fetches updates from Telegram if the “useTelegramPanel” option is enabled. This approach allows attackers to easily update the domain setting in real-time by simply sending a message in the Telegram chat, making the application more flexible and responsive to changes.

The Web-Injections Part:

The malicious Chrome extension is used to inject malicious code on the victim’s side to steal sensitive information such as credit card, user, password and more.

The first mechanism for the injection on the malicious Chrome extension is to fetch injection data which means it uses the domain and UUID, constructs a URL and sends a fetch request to retrieve JSON data related to the injections. It looks like this:

Once the victim enters one of the targeted URLs mentioned in the screenshot, it will inject the value. Inside the value, more external JavaScript is injected from a different domain.

Some of the values also use phishing/redirection:

All the sensitive data is sent to the C&C; here’s the login page for the C&C:

Template builder sold on underground forums

Our threat intelligence team researched and discovered a malicious Chrome extension builder being sold on underground forums. This builder provides fraudsters with pre-made templates for Chromium extensions and accompanying backend files, making it easier to deploy harmful extensions that can compromise users’ data and security. These extensions can be disguised as legitimate tools, tricking users into installing them and subsequently stealing sensitive information such as banking credentials and personal data. The ease of access to such sophisticated tools lowers the barrier for cyber criminals, leading to an increase in targeted attacks, especially in regions like LATAM where banking trojans are prevalent.

From the screenshot, we see a topic about a Chromium Botnet Extension, with a user selling it and offering support once the fraudster purchases the kit. This indicates a well-organized marketplace where cyber criminals can easily obtain tools and assistance to launch malicious campaigns, further highlighting the sophisticated nature of underground cyber crime ecosystems.

Template builder with extension and backend files.

Caiman malware campaign:

Caiman malware is a banking trojan malware that has specifically targeted the LATAM region. This malware is designed to steal sensitive financial information from users by infecting their computer devices.

The malware also uses the same technique to install malicious Chrome extension, not mimicking the Google Drive extension, but rather using the name “Chrome Notification”:

But the extension injecting script redirects the victim to a phishing site that impersonates the targeted bank:

Caiman Malware using AutoIT script to use the web inject technique:

The screenshot shows an AutoIT script designed to check if the user is browsing bbvanet.com.mx/mexiconet. Upon detection, it injects an external JavaScript file located at hxxps://www.cssangular[.]com/jquery.js. The script uses the key variable to denote the current date and r to represent the bank URL encoded in base64. The primary objective of this malicious activity is to harvest as much sensitive information as possible, including account balances, usernames, passwords, screenshots and more.

OTPBypass/Figrabber attack

In the latest research, we’ve observed new activity in the Colombia region, utilizing an ATS Engine injection panel to steal information. The primary objective of this injection is to carry out OTP (One-Time Password) bypass attacks, which are commonly used in phishing and other fraudulent activities.

There are two main features of this web inject:

• Communicate function:

The communication function is responsible for sending data to the attacker’s server. It constructs a URL with various parameters and dynamically loads a script from the attacker’s server. Data sent to the C&C (Command and Control) server includes:

• • action=comunicate: Specifies the action to be performed
  • login: The login credentials entered by the user
  • password: The password entered by the user
  • otp_token: The OTP token entered by the user
  • state: The current state (e.g., log-in or OTP submission)
  • pkey, botid, bank: Additional identifiers used by the attacker
  • ssid: A unique identifier based on the current timestamp
• Deception of Victim:

The attacker requests the OTP from the victim and then tricks the victim into believing that there are “technical difficulties.” Meanwhile, the OTP has been stolen and sent to the C&C server. Additionally, the attacker also steals more information such as credit card numbers, CVV, ID, telephone numbers and more.

The attacker is using a Full Info Grabber C&C panel, referred to as OTPBypass:

IOC

Web injects:

hxxps://facturacionmexico[.]net/ok[.]js

hxxps://dlxfreights[.]site/mx/sbi/main[.]js

hxxps://css.imagesccs[.]com/jquery.js

hxxps:/www.cssangular[.]com/jquery.js

hxxps:/www.angularcss[.]com/jquery.js

C&C:

hxxps://dlxfreights[.]site/uadmin/gate.php

hxxps://facturacionmx[.]autos/api

hxxps://facturamexico2023[.]com/api

hxxps://russk22[.]icu

hxxps://jogjaempatroda[.]com

Phishing/Redirect:

hxxps://s2conexion[.]info/?s=2

hxxps://s2conexion[.]info/?s=1

hxxps://ww15[.]mxbbua[.]net/index.php

hxxps://bbua[.]mxacceso-portal[.]com/ingreso_opt.php

hxxps://s1conexion[.]info/?s=12

hxxps://www.citlibanamex[.]group

hxxp://banamexunopaboti[.]run

How to stay safe from malicious Chrome extensions

To protect against these malicious extensions, it’s important to be vigilant when installing any new browser extensions. Users should only download extensions from trusted sources and carefully review the permissions requested by the extension before installation. Additionally, they should use two-factor authentication and regularly update their browser and extensions.

The rise of malicious Chrome extensions is a worrying trend that highlights the need for users to be vigilant when browsing the web.

It is suspected this malware campaign may potentially spread to the North American and European regions.

To learn how to authenticate customers, detect fraud and protect against malicious users across all channels, explore IBM Security Trusteer solutions.

The post Unveiling the latest banking trojan threats in LATAM appeared first on Security Intelligence.

Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme.

PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this malware attacking banks in Brazil.

A hidden threat

Within IBM Trusteer, we saw several different techniques to hide malware from its victims. Most banking malware conceals its existence on the mobile device by hiding its launcher icon from the victim using the SetComponentEnabeldSetting application programming interface (API). However, since Android 10, that technique no longer works due to new restrictions imposed by Google.

To address this new challenge, PixPirate introduced a new technique to hide its icon that we have never seen financial malware use before. Thanks to this new technique, during PixPirate reconnaissance and attack phases, the victim remains oblivious to the malicious operations that this malware performs in the background.

PixPirate abuses the accessibility service to gain RAT capabilities, monitor the victim’s activities and steal the victim’s online banking credentials, credit card details and login information of all targeted accounts. If two-factor authentication (2FA) is needed to complete the fraudulent transaction, the malware can also access, edit and delete the victim’s SMS messages, including any messages the bank sends.

PixPirate uses modern capabilities and poses a serious threat to its victims. Here is a short list of PixPirate’s main malicious capabilities:

• Manipulating and controlling other applications
• Keylogging
• Collecting a list of apps installed on the device
• Installing and removing apps from the infected device
• Locking and unlocking device screen
• Accessing registered phone accounts
• Accessing contact list and ongoing calls
• Pinpointing device location
• Anti-virtual machine (VM) and anti-debug capabilities
• Persistence after reboot
• Spreading through WhatsApp
• Reading, editing and deleting SMS messages
• Anti-removal and disabling Google Play Protect

Thanks to its RAT capabilities, PixPirate can perform on-device fraud (ODF) and execute the fraud from the victim’s device to avoid detection by the bank’s security and fraud detection systems.

PixPirate infection flow

Most financial malware comprises one main Android Package (APK) file. This is not the case for PixPirate, which is built of two components: a downloader APK and the droppee APK. The use of a downloader app as part of a financial attack is not new; however, unlike most financial malware today that uses a downloader as a service, both the droppee and the downloader for PixPirate were created by the same actor.

In addition, the PixPirate downloader role in the infection flow of the malware is different from other financial malware. Usually, the downloader is used to download and install the dropped, and from this point on, the droppee is the main actor conducting all fraudulent operations and the downloader is irrelevant. In the case of PixPirate, the downloader is responsible not only for downloading and installing the droppee but also for running and executing it. The downloader plays an active part in the malicious activities of the droppee as they communicate with each other and send commands to execute.

Usually, victims get infected with PixPirate by downloading the PixPirate downloader from a malicious link sent to them through WhatsApp or an SMS phishing (smishing) message. This message convinces the victim to download the downloader, which impersonates a legitimate authentication app associated with the bank. Once the victim launches the downloader, it asks the victim to install an updated version of itself, which is, in fact, the actual PixPirate malware (the droppee). After the victim approves this update, the downloader either installs the droppee embedded in its APK or downloads it directly from the PixPirate command and control (C2) server. If the droppee is embedded in the downloader’s APK file, it is encrypted and encoded in the downloader “/assets/” folder, masquerading as a jpeg file to lower suspicion.

Next, the downloader sends a command to the PixPirate droppee to activate and execute it. On the first run, the droppee prompts the victim to allow its accessibility service to run. In the next stage, PixPirate abuses the accessibility service to grant itself all the necessary permissions it needs to run and successfully perform financial fraud.

After the malware gets all the necessary permissions it needs to run, it collects some information and data regarding the infected device to decide if this is a legitimate device and a good candidate for fraud (anti-VM/anti-emulator, which bank apps are installed on the device and so on) and then sends all this data to the PixPirate C2.

New hiding technique in the wild

Malware has always tried to hide and conceal itself from its intended victim. The most obvious and effective way is to hide the launcher icon of the malicious APK because most users do not look at the app settings screen to check which apps are installed, so they won’t notice the malicious app and will not try to remove it.

Traditionally, financial malware hides the launcher icon using the “SetComponentEnabledSetting” API. This technique does not require any permission to be granted by the victim. However, from Android 10, this technique became ineffective for malware and could not be used anymore. We will explain how the technique works using the FakeChat malware that also uses this technique.

The malware declares in the manifest the MainActivity that will be executed once the victim launches it by pressing its icon on the home screen of the mobile device.

In the following image, we can see in the FakeChat manifest the malware’s app tag and the path of the app icon in the icon value. Also, the manifest contains the MainActivity with the name “com.eg.android.AlipayGphone.MainActivity” with the action “android.intent.action.Main” and the category “android.intent.category.LANUCHER.” This activity will be run and executed once the user presses the app’s icon and launches the app.

In the first run of the malware, it makes the launcher icon disappear by calling the Android API “SetComponentEnabledSetting” with the following parameters:

• ComponentName: the component that represents the MainActivity related to the icon for launching the app.
• NewState: the new state of the component. In this case, the malware specifies the state “COMPONENT_ENABLED_STATE_DISABLED” to disable and hide the APK icon.
• Flags (optional): Value is either 0 or a combination of DONT_KILL_APP and SYNCHRONOUS.

In the following image, we can see how it is done programmatically:

From Android 10, all app icons are visible in the launcher unless it is a system app or it does not ask for any permission at all (look at the documentation and the guide). Those limitations made this technique irrelevant for malware from Android 10 and later. Therefore, malware could no longer hide its launcher icon and its existence.

PixPirate’s new innovative hiding technique

When examining PixPirate, IBM Trusteer detected a new technique to achieve the same goal that works in all Android versions to date. To accomplish the goal of hiding malware from the victim, the PixPirate droppee does not have a main activity; that is, it does not have an activity with the action “android.intent.action.MAIN” and category “android.intent.category.LANUCHER.” This change in behavior means that the app’s icon does not exist on the home screen of the victim’s device at all. However, this also presents a new problem. If the droppee’s icon does not exist on the victim’s home screen, how will the victim launch the app in the first place?

The new technique requires the malware to have two applications: in this case, the downloader and the droppee that operate together. The downloader is the app that runs. The downloader then runs the droppee, which would not be executed otherwise since its icon does not exist.

How the droppee runs

So, how does the droppee run? PixPirate built a mechanism that triggers the droppee to run when different events occur on the device.

In the following image, we can see the service used to launch the droppee replacing the activity (“MainActivity”) used in other apps and APKs. The service is exported and can be run by other processes running on the device. This service has a custom-made action triggered by binding to this specific service. The downloader uses this to create and bind to this service and run the droppee every time it is required.

The method works as follows:

• The droppee has a service called “com.companian.date.sepherd” exported and holds an intent-filter with the custom action “com.ticket.stage.Service.”
• When the downloader wants to run the droppee, it creates and binds to this droppee service using the API “BindService” with the flag “BIND_AUTO_CREATE” that creates and runs the droppee service.
• After the creation and binding of the droppee service, the droppee APK is launched and starts to operate.

The BindService API has the following parameters:

• The service intent “com.ticket.stage.Service”
• The flag “BIND_AUTO_CREATE” (0x01) that creates and binds to the service (if the service does not exist)
• ServiceConnection object that connects to the droppee service and consists of an interface to monitor the state of the application service

In this way, the downloader succeeds in triggering the droppee to run. The ServiceConnection object is used as an interface to maintain communications between the downloader and the droppee and allows them to send messages between themselves and communicate through this interface.

In the following image, we see the code from the downloader APK that creates and binds to the exported service of the droppee APK, which we saw in the previous image, to trigger the droppee to run and send it commands to execute.

This code must run at the first running and execution of the droppee, just after the downloader installs the droppee. Later, to maintain persistence, the droppee is also triggered to run by the different receivers that it registered. The receivers are set to be activated based on different events that occur in the system and not necessarily by the downloader that initially triggered the droppee to run.

This technique allows the PixPirate droppee to run and hide its existence even if the victim removes the PixPirate downloader from their device. PixPirate malware is the first financial malware observed by IBM Trusteer researchers that uses this technique to hide itself and its launcher icon so that victims won’t notice that malware is installed and running on the device.

Fraud modus operandi

PixPirate campaigns mostly target customers of banks in Brazil. It mainly attacks the Brazilian payment service called Pix, the standard instant payment platform in Brazil. Most of the banks in Brazil implement the Pix API to support Pix transactions from within the banking app itself.

What is Pix?

Pix is an instant payment platform that enables the quick execution of payments and transfers between bank accounts. Customers receive a Pix string or QR code that contains the amount to pay for services or goods to complete a transaction. Then, customers pay the Pix payment using their bank apps or through internet banking. They can pay or transfer money using Pix through their banking app.

The Pix payment service launched in November 2020 was heavily adopted by users and businesses in Brazil and broke records in the number of users, financial transactions, and volumes. In the following graph, we can see the number of Pix transactions (in thousands). In March 2023, it reached 3 billion transactions in a single month.

Financial transaction volume reached 1,250,000,000,000 Brazilian reals in March 2023, which is about $250 billion. By May 2023, the number of Pix users reached 140 million.

Pix fraud MO

PixPirate Pix fraud occurs by initiating a new Pix transaction from the victim to the fraudster’s Pix account or by changing the Pix details of the receiver of a legitimate Pix transaction initiated by the victim to the fraudster’s Pix details.

Technically, Pix fraud is performed thanks to PixPirate RAT capabilities gained by abusing the Android accessibility service. The malware monitors the victim’s activities on the device and waits for the user to launch a targeted banking application. On each accessibility event, it checks the type of event that occurred. If the event type is “TYPE_WINDOW_STATE_CHANGED,” it retrieves the name of the package of the app from the window. If the app is in the target list, the malware can start its malicious activities.

When the victim launches their bank app, the malware grabs and collects the user credentials and account info while the user enters their credentials to log in. The malware sends the stolen info and credentials to the attacker’s C2 server. The victim is not aware that the malware is stealing credentials as everything seems legitimate, as the malware hides itself and operates in the background.

When the malware decides to carry out the fraud, it pops up a new screen on top of the current screen of the device that hides the malware’s malicious activities from the victim. The malware launches the bank app (if it’s not running yet) and goes to the Pix page by pressing the app buttons programmatically. Once on the Pix transfer/payment page, the malware executes the Pix money transfer.

In the following image, we can see the different functions the malware calls to enter the relevant details and execute the money transfer (Pix details, amount, password and so on).

The main function responsible for the fraud is “strictPay_js.action.transfer,” which automatically executes the fraud. First, it calls SendPageNode(1) with the argument “1”. This function navigates to the Pix page in the banking application. The next function is sendBalance(), which consists of three subfunctions:

• inputPix(): Enters the Pix details for executing the Pix money transfer
• continue2Password(): The malware enters the stolen victim’s credentials
• waitUntilPassword(): Waits until the Pix money transfer is completed and validates that it was successfully executed

The same technique is used by PixPirate for the second Pix attack MO of intercepting the victim operations and changing the Pix details while the victim transfers the money without the victim knowing. PixPirate can manipulate both the target account and the Pix transaction amount.

If 2FA is needed as part of the banking flow, the malware can also intercept SMS messages that the user receives from the bank.

Automatic fraud capabilities

PixPirate fraud occurs automatically, as this malware contains code for all the different activities that are required to complete Pix fraud — log in, enter Pix details, enter credentials, confirm and more. PixPirate is not only an automated attack tool, but it also has the capability of becoming a manually operated remote control attack tool. This capability is probably implemented to manually execute fraud if the automatic fraud execution flows fail because the user interface of the banking app changes or if a new lucrative target presents itself.

The manual fraud is initiated by popping up an overlay screen on the victim’s device and disabling the user control on the infected device to hide the fraudster’s activities in the background. Next, the malware connects to the C2 and receives commands from the fraudster to be executed. This remote-control capability gives the fraudster control of the victim’s device, including accessing private information and manipulating applications on the victim’s device.

Stay up to date on PixPirate’s capabilities

With nuanced methods of staying hidden and the capacity for serious harm, PixPirate presents a troubling new threat on the malware playing field. We will discuss more on PixPirate’s functionality, capabilities and commands it can receive from the C2 server in part two of our PixPirate blog.

PixPirate IOCs:
Downloader: 019a5c8c724e490df29020c1854c5b015413c9f39af640f7b34190fd4c989e81
Droppee: 9360f2ee1db89f9bac13f8de427a7b89c24919361dcd004c40c95859c8ce6a79

The post PixPirate: The Brazilian financial malware you can’t see appeared first on Security Intelligence.

This article was made possible thanks to contributions from Itzhak Chimino, Michael Gal and Liran Tiebloom.

Browser extensions have become integral to our online experience. From productivity tools to entertainment add-ons, these small software modules offer customized features to suit individual preferences. Unfortunately, extensions can prove useful to malicious actors as well.

Capitalizing on the favorable characteristics of an add-on, an attacker can leverage attributes like persistence, seamless installation, elevated privileges and unencrypted data exposure to distribute and operate banking trojans.

In November 2023, security researchers at IBM Security Trusteer found new widespread malware dubbed Fakext that uses a malicious Edge extension to perform man-in-the-browser and web-injection attacks.

Here’s what cyber professionals need to know about the Fakext campaign and the different attacks the extension performs. Lastly, we will explore some indicators of compromise (IOCs) and a remediation guide for this malware.

Fakext campaign targeting Latin America

Since the start of November 2023, our team has seen over 35,000 infected sessions, primarily originating from Latin America (LATAM), with a smaller number from Europe and North America. The extensive number of infected sessions indicates an exceptionally successful and widespread campaign. We have also seen that when Fakext injects content onto the screen, such as error messages, user forms and notifications, it is displayed in Spanish.

The list of targeted banks extracted from the initial loader comprises 14 banks operating in LATAM, particularly in Mexico. Furthermore, the loader is programmed to halt code execution if the current website does not match the specified targets. These collective observations strongly indicate that this variant is tailored to specifically target banks in LATAM. However, the methods employed here are generic, and with slight content alterations could pose a threat to other regions. We are already aware of previous instances where malware originating in Latin America has transitioned to Spain and subsequently spread to other parts of Europe.

Step 1: Infection

The sole purpose of the extension is to provide a persistent mechanism to inject scripts into the victim’s HTML page.

The loader script is fetched from one of the many command and control (C2) servers the threat actor maintains and runs in the current page context. In addition to regular HTTP traffic, Fakext uses Telegram’s application programming interface (API) as another communication channel with the C2 servers. The current state of the injection and even screenshots are sent using Telegram.

Fakext downloads the fingerprintJS library as a legitimate external resource from its official content delivery network (CDN) and uses it to generate the victim’s user ID. The browser’s fingerprint is added as an HTML document attribute named “fkr-client-uid,” which signals that the extension is installed and running.

The loader script then looks for the previously mentioned ID and the current page URL to see if it’s one of the targeted banks and fetches extra modules, depending on the outcome.

There are two main modules that Fakext runs on targeted sites:

• A form grabber that logs all input fields on the page
• An overlay that injects content onto the page to alter victims’ behavior for further fraud opportunities.

Step 2: Evasion

This malware tries to hide its network traffic with seemingly legitimate domain names that are similar to known CDNs and frameworks, such as:

• fastify[.]sbs (like fastify[.]io)
• jschecks[.]com
• cdn[.]jsassets[.]sbs
• javascrip12[.]com
• fastify[.]elfaker[.]workers[.]dev

For a full list of IOCs, see the IOCs section below.

The threat actor uses Cloudflare’s workers to distribute the web injections. The extension itself (which currently has over 10,000 users) describes itself as a tool to help facilitate the use of Mexico’s SAT portal, which is a government tax agency website.

Figure 1: SATiD extension page from the Edge store

Fakext also uses popular anti-debugging techniques we have already seen in past web injections. The use of code obfuscation, native function overrides and deliberate code sections designed to crash development tools collectively contribute to rendering the code more challenging to detect and analyze.

Step 3: Interception

Fakext runs a generic form grabber on the current page that hooks into all input fields and waits for an input event. Once a keypress occurs, the entire input element, including style, ID, type and value, is sent to the C2 server.

In addition, the current page URL is sent, which allows the fraudster to know the exact type and owner of the credentials they have stolen.

In the case of specific targets with known HTML page structures and element IDs, only the pertinent inputs are intercepted. These fields are identified by their specific IDs hardcoded in the script, suggesting that certain injections were customized exclusively for selected targets.

Figure 2: Example GET request with exfiltrated data

Step 4: Data theft

In some targets in the lists, Fakext uses a different attack vector. In those cases, it injects an overlay onto the page that matches the current page styling and prevents the user from continuing the usual behavior.

Under the false presence of the bank’s IT support, the popup prompts the user to download a legitimate remote access tool (RAT) and provides the fraudster with the tool’s credentials.

Figure 3: Prompt to install “security software” before continuing with bank operations.

The rest of the page is dimmed and unresponsive and the prompt can’t be removed.

Figure 4: Instructions on how to download and install TeamViewer.

Figure 5: Instructions recognize the credentials the victim needs to provide.

This injection constantly sends information to the C2 servers about the current state of the overlay, such as which popup page the user is on, which banking page the user is on (pre or post-login) and what type of RAT the user installed.

With RAT credentials, knowledge of the user, banking app state and the ability to inject certain pages onto the victim’s screen (such as a fake one-time password (OTP) page), the fraudster can perform transactions and other types of financial fraud.

Figure 6: Fake token input.

Native security measures, such as content security policy (CSP), secure socket layer (SSL) certificates or cross-origin resource sharing (CORS) limitation, don’t remediate this threat because the browser extension overrides them.

The victim can’t identify that external content was injected, and the whole overlay seems like a legitimate security procedure.

In addition, an optional credit card information form is often presented for further data theft.

Figure 7: IT support loading page

Figure 8: Credit card theft form.

Common indicators of compromise

The following IOCs were detected by IBM Trusteer research as Fakext:

Domains

• hxxps://fastify.elfaker.workers.dev
• hxxps://prod.jslibrary.sbs
• hxxps://javascript[number].com
• hxxps://screen-security.com
• hxxps://cdn.lll.yachts
• hxxps://browser.internalfiles.sbs
• hxxps://jschecks.com
• hxxps://fastify.sbs

HTML document attributes

fkr-client-uid (attribute of the top-level document element)

Malicious extension (Edge store)

https://microsoftedge.microsoft.com/addons/detail/satid/odpnfiaoaffclahakgdnneofodejhaop

Files hash:

Remediation and general guidelines

If installed, immediately remove the “SATiD” add-on from your Edge browser.

Users should practice vigilance when using banking apps. This includes contacting their bank to report potentially suspicious activity on their accounts, not downloading software from unknown sources and following best practices for password hygiene and email security hygiene.

We emphasize that legitimate banking apps do not ask you to download a remote access tool and provide the credentials to someone else. In addition, it’s important to periodically review the extensions you have installed. If you no longer use a particular extension or you found an extension that you aren’t familiar with, consider removing it to reduce the potential attack surface.

Individuals and organizations must also remain vigilant, implement robust security measures and stay informed about emerging malware to effectively counteract these threats.

IBM Security Trusteer helps you to detect fraud, authenticate users and establish identity trust across the omnichannel customer journey. More than 500 leading organizations rely on Trusteer to help secure their customers’ digital journeys and support business growth.

The post New Fakext malware targets Latin American banks appeared first on Security Intelligence.

Quantum computing is a new paradigm with the potential to tackle problems that classical computers cannot solve today. Unfortunately, this also introduces threats to the digital economy and particularly the financial sector.

The Digital Operational Resilience Act (DORA) is a regulatory framework that introduces uniform requirements across the European Union (EU) to achieve a “high level of operational resilience” in the financial services sector. Entities covered by DORA — such as credit institutions, payment institutions, insurance undertakings, information and communication technology (ICT) service providers, etc. — are expected to comply by January 17, 2025.

New requirements for financial entities in the EU

DORA lays out a set of requirements across ICT risk management, incident reporting, operational resilience testing, cyber threat and vulnerability information sharing, and third-party risk management. As part of those requirements and in the context of data protection and cryptography, it lays out in Article 9 (“Protection and prevention”) that financial entities “shall use ICT solutions and processes” that “(a) ensure the security of the means of transfer of data” or “(c) prevent […] the impairment of the authenticity and integrity, the breaches of confidentiality and the loss of data.”

Further elements to consider in the context of Article 9 are referred to in Article 15 and laid out in the related (draft) regulatory technical standards, which the ESA published on January 17, 2024. Particularly, JC 2023 86 provides detailed requirements on cryptographic guidance. In addition, in its preambles, the following is stated:

“Given the rapid technological developments in the field of cryptographic techniques, financial entities […] should remain abreast of relevant developments in cryptanalysis and consider leading practices and standards and should hence follow a flexible approach based on mitigation and monitoring to deal with the dynamic landscape of cryptographic threats, including those from quantum advancements.”

Below, we will further elaborate on the referred ‘cryptographic threats’ and the implications they could have on financial institutions in the context of quantum computing.

Quantum threats and quantum-safe cryptography

While current quantum computers still struggle with noise and are not yet “fault-tolerant,” impressive milestones have been reached already proving their utility. Given the number of investments being made in both the private sector and academia, it is expected that this technology will scale and drastically improve over time. As it does, the potential threat to the digital economy will grow.

In 1994, the physicist Peter Shor introduced an algorithm that, when run on a large-scale quantum computer, could break public key-cryptography algorithms such as Rivest-Shamir-Adleman (RSA), Diffie-Hellman and Elliptic Curve Cryptography (ECC). The financial sector relies on these algorithms to ensure the confidentiality and integrity of bank transactions, the authenticity of its customers, the validity of digitally signed documents and the confidentiality of customer financial data. If the supporting cryptography can no longer be trusted, the entire financial sector is at risk.

Quantum threats posed to cryptography

To break today’s cryptography, a so-called Cryptographically Relevant Quantum Computer (CRQC) would need to be realized (some experts estimate it could happen in the early 2030s). However, while the impact is in the future, we are at risk already. One can imagine an attacker harvesting encrypted confidential data today to decrypt it later.

Fast-tracking quantum-resistant cryptography

Fortunately, new “quantum-safe” cryptography is being standardized, with the most noteworthy effort being run by the National Institute of Standards and Technology (NIST). In 2016, NIST launched a competition with more than 80 submissions to standardize a new form of cryptography that will run on ordinary systems (e.g., laptops, cloud, etc.) but will be resistant to a quantum attacker because it relies on mathematical problems that are hard to solve by a quantum (and classical) computer.

The first four algorithms for standardization were selected by NIST in July 2022 (out of which three were co-contributed by IBM). While the standards are planned to be released in 2024, additional alternate candidates are still being considered.

NIST standardization timeline for quantum-safe (aka ‘post-quantum’) cryptography

A quantum-safe cryptography standard is in sight. Unfortunately, due to the complexity of the financial sector in particular, a lengthy journey lies ahead. NIST assumes that “five to 15 or more years will elapse […] before a full implementation of those standards is completed.” If we overlay this with the development timelines of a CRQC, one realizes that entities have to start this journey today.

Why quantum has an impact on DORA

Quantum threats, when they materialize, have the potential to drastically impact the operational resilience of financial entities and could disrupt the economy globally. Fortunately, new quantum-safe cryptography algorithms are available (with standards very soon to be published), which will be needed to mitigate those threats.

If we relate this to the requirements of DORA, we can draw several direct links. To satisfy Article 9, financial entities will need to adopt quantum-safe means of data transfer, as well as quantum-safe mechanisms to “prevent […] the impairment of the authenticity and integrity, the breaches of confidentiality and loss of data.”

This implies the need to adopt upcoming, quantum-safe data-in-transit protocols such as quantum-safe transport layer security (TLS) or quantum-safe virtual private networks (VPNs), as well as quantum-safe mechanisms for signing (legally binding) documents or bank transactions. As a result, financial entities will need to implement supporting infrastructure such as quantum-safe public key infrastructure (PKI) and key management systems.

Additionally, implementations today are often in the hands of third-party suppliers. To add to the complexity, in many cases, existing programs, such as a “move to cloud” or “zero trust” implementation, will be impacting several of the above-mentioned elements.

Quantum threats can have serious consequences

In a worst-case scenario, if financial services organizations do not remediate quantum threats in their digital ecosystem, this can impact the resilience of their business by:

• Being unable to verify authorized users on their network leads to confusion and a complete lack of trust in their digital ecosystem.
• Being unable to fulfill their data privacy regulations due to a lack of trust in the mechanisms (e.g., encryption) used to protect such data.
• Increased risk of exposure to external threats from the presence of vulnerable cryptography protocols and algorithms on business-to-business and supply chain networks.
• Disruption of day-to-day business from downtime required to remediate digital services and applications.

Given current draft requirements as per JC 2023 86, one can anticipate that soon after quantum-safe cryptography is standardized, it will be considered an account-leading practice. Hence, regardless of when quantum threats might materialize, regulatory requirements, such as DORA, will soon implicitly mandate the adoption of quantum-safe cryptography in the financial industry.

At the same time, organizations should seize the opportunity to improve their overall cryptographic agility by modernizing the way cryptography is implemented today and making future changes much more timely and cost-efficient.

Implement your quantum-safe migration

It is clear that implementing quantum-safe cryptography will not be an easy endeavor. Such a migration program will require agility and also offers the possibility to exploit an early mover advantage. It will require a multi-pronged approach, including top-down business priorities as well as bottom-up technical capabilities.

We recommend the following steps that organizations impacted by DORA should take at a minimum:

• Assess and review your enterprise cryptographic posture and identify elements (applications, networks, strategic projects, etc.) potentially impacted by quantum threats.
• Develop a plan based on business priorities and take into account synergies with existing transformation programs, laying out an approach to remediation for the impacted digital services and corresponding systems.
• Improve your cryptographic posture by introducing cryptographic discovery and inventory capabilities. Introduce cryptographic observability to validate cryptographic compliance on an ongoing basis, including leveraging “cryptography bills of material.” Such elements will increase the cryptographic agility of your organization.
• Ensure current change processes and strategic projects take into consideration the impact of cryptography and provisions are made to implement remediation on the least disruptive basis.
• Sponsor a program to continue the steps above continually.

Above all, do not wait to begin tackling these steps. We strongly recommend that organizations define a quantum-safe migration program today.

The post DORA and your quantum-safe cryptography migration appeared first on Security Intelligence.

Web injections, a favored technique employed by various banking trojans, have been a persistent threat in the realm of cyberattacks. These malicious injections enable cyber criminals to manipulate data exchanges between users and web browsers, potentially compromising sensitive information.

In March 2023, security researchers at IBM Security Trusteer uncovered a new malware campaign using JavaScript web injections. This new campaign is widespread and particularly evasive, with historical indicators of compromise (IOCs) suggesting a possible connection to DanaBot — although we cannot definitively confirm its identity.

Since the beginning of 2023, we have seen over 50,000 infected user sessions where these injections were used by attackers, indicating the scale of threat activity, across more than 40 banks that were affected by this malware campaign across North America, South America,  Europe and Japan.

In this blog post, we will delve into an analysis of the web injection utilized in the recent campaign, its evasive techniques, code flow, targets and the methods employed to achieve them.

A dangerous new campaign

Our analysis indicates that in this new campaign, threat actors’ intention with the web injection module is likely to compromise popular banking applications and, once the malware is installed, intercept the users’ credentials in order to then access and likely monetize their banking information.

Our data shows that threat actors purchased malicious domains in December 2022 and began executing their campaigns shortly after. Since early 2023, we’ve seen multiple sessions communicating with those domains, which remain active as of this blog’s publication.

Upon examining the injection, we discovered that the JS script is targeting a specific page structure common across multiple banks. When the requested resource contains a certain keyword and a login button with a specific ID is present, new malicious content is injected.

Credential theft is executed by adding event listeners to this button, with an option to steal a one-time password (OTP) token with it.

This web injection doesn’t target banks with different login pages, but it does send data about the infected machine to the server and can easily be modified to target other banks.

Code delivery

In the past, we observed malware that directly injected the code into the compromised web page. However, in this campaign, the malicious script is an external resource hosted on the attacker’s server. It is retrieved by injecting a script tag into the head element of the page’s HTML document, with the src attribute set to the malicious domain.

HTML snippet:

During our investigation, we observed that the malware initiates data exfiltration upon the initial retrieval of the script. It appends information, such as the bot ID and different configuration flags, as query parameters. The computer’s name is usually used as the bot ID, which is information that isn’t available through the browser. It indicates that the infection has already occurred at the operating system level by other malware components, before injecting content into the browser session.

Figure 1: The initial obfuscated GET request fetching the script

Evasion techniques

The retrieved script is intentionally obfuscated and returned as a single line of code, which includes both the encoded script string and a small decoding script.

To conceal its malicious content, a large string is added at the beginning and end of the decoder code. The encoded string is then passed to a function builder within an anonymous function and promptly executed, which also initiates the execution of the malicious script.

Figure 2: Encoded string passed to de-obfuscation function, followed by removal of artifacts used for decoding the script. Two long strings were added to the beginning and end of the string to make it harder to find the code manually.

At first glance, the network traffic appears normal, and the domain resembles a legitimate content delivery network (CDN) for a JavaScript library. The malicious domains resemble two legitimate JavaScript CDNs:

In addition, the injection looks for a popular security vendor’s JavaScript agent by searching for the keyword “adrum” in the current page URL. If the word exists, the injection doesn’t run.

Figure 3: Searching for a security product’s keyword and doing nothing if it’s found

The injection also performs function patching, changing built-in functions that are used to gather information about the current page document object model (DOM) and JavaScript environment. The patch removes any remnant evidence of the malware from the session.

All of these actions are performed to help conceal the presence of the malware.

Dynamic web injection

The script’s behavior is highly dynamic, continuously querying both the command and control (C2) server and the current page structure and adjusting its flow based on the information obtained.

The structure is similar to a client-server architecture, where the script maintains a continuous flow of updates to the server while requesting further instructions.

To keep a record of its actions, the script sends a request to the server, logging pertinent information, such as the originating function, success or failure status and updates on various flags indicating the current state.

Figure 4: Every a.V function call sends an update to the server about what function it was sent from and the current state of different flags

Figure 5: An example of multiple traffic logs, sent within a few seconds of the script running

The script relies on receiving a specific response from the server, which determines the type of injection it should execute, if any. This type of communication greatly enhances the resilience of the web injection.

For instance, it enables the injection to patiently wait for a particular element to load, provide the server with updates regarding the presence of the injected OTP field, retry specific steps (such as injecting an SMS submission overlay) or redirect to the login page before displaying an alert indicating that the bank is temporarily unavailable.

The server keeps identifying the device by the bot ID, so even if the client tries to refresh or load the page again, the injection can continue from its previously executed step.

If the server does not respond, the injection process will not proceed. Hence, for this injection to be effective, the server must remain online.

Script flow

The script is executed within an anonymous function, creating an object that encompasses various fields and helper functions for its usage. Within the object, the injection holds the initial configuration with fields such as bot ID, phone number and password. These fields are initially empty but are populated with relevant values as the run progresses.

Additionally, the object includes details such as the C2 server’s domain and requests path, default values for query parameters and default settings for various flags such as “send SMS” and “send token.” These default values can be modified later based on the server’s response, allowing for dynamic adjustments during runtime.

Following the initial configuration, the script sends a request to the server providing initial details, and assigns a callback to handle the response, allowing the execution to proceed.

Subsequently, the script proceeds to remove itself from the DOM tree, enhancing its ability to conceal its actions. From that stage onward, all subsequent script actions are asynchronous, saved inside event handlers and dependent on the responses received from the server.

The steps the script should perform are mostly based on an “mlink” flag received from the server on the initial request. The next step of the injection is to check for the specific login button of the targeted bank. The results of the element query are sent, and the “mlink” state changes accordingly.

Following that, a new function runs asynchronously on an interval, looking for the login button and assigning a malicious event listener if found. The listener waits for a click event, collects the login credentials and handles it based on the current configuration.

For example, if the “collect token” flag is on, but the script can’t find the two-factor authentication (2FA) token input field, it just stops the current run and does nothing. If the token is found or wasn’t looked for in the first place, the script sends all the gathered information to the server.

After that, it can inject a “loading” bar to the page (opengif function), cancel the original login action or allow the client to continue with the actions by removing the handler and “clicking” it again on behalf of the user (by dispatching another “click” event).

Figure 6: The event listener prevents the default action of the login button or deletes itself and dispatches another click event based on the outcome of function G

Figure 7: This section of function G reads credentials and tries to read the injected token field value, depending on the current state of the page and flags

Potential operational states

Returning to the “synchronous” part of the callback, let’s examine some potential operational states and the corresponding actions taken.

When the “mlink” value is 2, the script injects a div that prompts the user to choose a phone number for 2FA. Once the user selects a phone number, a login attempt can be executed using the stolen credentials, and a valid token is sent to the victim from the bank.

Figure 8: Prompting a phone number for two-factor authentication

The following state is when “mlink” is equal to three, where the input field for the OTP token is injected. In this manner, DanaBot deceives the victim into providing the token, effectively bypassing the 2FA protection mechanism.

Figure 9: Prompting for the received token

When the “mlink” value is four, the script introduces an error message on the login page, indicating that online banking services will be unavailable for a duration of 12 hours. This tactic aims to discourage the victim from attempting to access their account, providing the threat actor with an opportunity to perform uninterrupted actions.

Figure 10: An error message that banking services are unavailable for 12 hours, giving the threat actor ample time to work

When the “mlink” value is 5, the script injects a page loading overlay that mimics the appearance of the original website’s loading animation. A timeout is set before transitioning to a different state, effectively “completing” the page load process.

Figure 11: An injected loading screen, an exact duplicate of the original loading screen

When the value of “mlink” is six, a “clean up” flow is initiated, removing any injected content from the page. This value serves as the default assignment for the flag in case no specific instruction is received from the server.

In total, there are nine distinct potential values for the “mlink” variable, each corresponding to different states and behaviors. Additionally, multiple flags activate various actions and result in different data being sent back to the server. Combining these “mlink” values and flags allows for a diverse range of actions and data exchanges between the script and the server.

Urging vigilance

IBM has observed widespread activity from this malware campaign affecting banking applications of numerous financial institutions across North America, South America, Europe and Japan. This sophisticated threat showcases advanced capabilities, particularly in executing man-in-the-browser attacks with its dynamic communication, web injection methods and the ability to adapt based on server instructions and current page state. The malware represents a significant danger to the security of financial institutions and their customers.

Users should practice vigilance when using banking apps. This includes contacting their bank to report potentially suspicious activity on their accounts, not downloading software from unknown sources and following best practices for password hygiene and email security hygiene.

Individuals and organizations must also remain vigilant, implement robust security measures and stay informed about emerging malware to effectively counteract these threats.

IBM Security Trusteer helps you to detect fraud, authenticate users and establish identity trust across the omnichannel customer journey. More than 500 leading organizations rely on Trusteer to help secure their customers’ digital journeys and support business growth.

The post Web injections are back on the rise: 40+ banks affected by new malware campaign appeared first on Security Intelligence.

In today’s rapidly evolving financial landscape, as banks continue to broaden their range of services and embrace innovative technologies, they find themselves at the forefront of a dual-edged sword. While these advancements promise greater convenience and accessibility for customers, they also inadvertently expose the financial industry to an ever-shifting spectrum of emerging fraud trends. This delicate balance between new offerings and security controls is a key part of the modern banking challenges. In this blog, we explore such an example.

IBM Security Trusteer recently observed a new trend in a Spanish retail bank with the creation of virtual credit cards for fraudulent purposes, which turned out to be a little-protected service of the offering bank. Fraudsters exploited it to defraud victims of their entire account balance, reinventing a known and effective scam.

The fraud, step by step

Each security attack has a unique anatomy and flow. We will examine the flow of this specific fraud here.

1. Fraudsters initiate the attack by sending an SMS to the victim. The SMS will appear under the same section as previous messages from the bank. This is done using a tactic called SMS spoofing. The topic of SMS spoofing is outside the scope of this blog but is indeed a facilitator of this fraud flow.
2. The fraudsters, appearing to be the bank, inform the victim via SMS of a security issue with their banking account. They further explain that a bank representative will call the victim soon and provide a numeric code to identify themselves. The code is provided in the message as well.
3. Next, a fraudster calls the victim, providing the code from the SMS sent earlier to “identify” themselves and elaborate on the security issue: they often claim that the victim’s banking account was compromised and that to protect the money, they will need to move it to a new banking account that was created for them.
4. Note that the fraudster established reliability via the SMS and by providing the code at this point. The stressed victim provides the fraudster(s) with their credentials, allowing them to log into the banking account.
5. At this point, fraudsters have two options. They can try to empty the banking account using traditional wire transfers. However, these are often capped at a specific daily limit, are monitored for fraudulent activity by the bank, and require a fraudulent destination account (otherwise known as a mule account). The second option is to create virtual credit cards, which is a convenient alternative for the following reasons:
6. • No daily limit: The virtual cards’ limit is several thousand euros, but the fraudster can create as many virtual cards as the victim’s account balance allows. For example, if the victim has 10,000 euros in the account, the fraudster could create multiple virtual cards with a limit of several thousand euros each. This action requires authentication, but the victims provide the 2FA under pressure.
   • No need for a mule account: Once the credit card is created, fraudsters use it to buy cryptocurrency and disappear from the traditional banking system.

This MO surfaced in early 2023 and slowly grew in popularity. It now compromises 41-48% of the fraudulent “transaction” attempts.

Discover the ROI of fraud detection

Trusteer’s solution

The virtual credit card creation is, for now, exclusively available via the browser (and not the banking app). As such, we addressed this fraud by analyzing the user flow data (URLs) and transactional data.

In general, user flow data can provide valuable insights into potentially risky and unauthorized actions in the account. This includes, but is not limited to:

• Reset passwords — an action that occurs before the actual login
• Change of contact details, such as phone numbers
• Change of transaction limits
• Enrolling a new device to receive soft tokens (2FAs)

The prerequisite for user flow analysis is complete visibility into all flows of the banking application and a risk assessment at the correct time during the session (pre-login or post-login).

Once the data is available in Trusteer’s systems, our fraud prevention solutions can incorporate the data into the security policy.

In this specific case, Trusteer alerts the bank to suspicious virtual credit card creations, allowing them to take action.

What banks must keep in mind

As banks continuously innovate and introduce new services to meet their clients’ expectations, they simultaneously open new opportunities for fraud. End-to-end visibility and robust data collection are key to creating security controls for new offerings.

By using Trusteer’s risk assessment, banks have the essential resources to stay ahead of the curve and promptly identify and prevent developing fraud trends. This approach safeguards both the banks and the trust of their valued clients.

The post Virtual credit card fraud: An old scam reinvented appeared first on Security Intelligence.

According to the IBM Cost of a Data Breach Report 2023, the global average cost of a data breach in 2023 was $4.45 million, 15% more than in 2020. In response, 51% of organizations plan to increase cybersecurity spending this year.

For the financial industry, however, global statistics don’t tell the whole story. Finance firms lose approximately $5.9 million per data breach, 28% higher than the global average. In addition, evolving regulatory concerns play a role in how financial companies respond to cyberattacks and where they’re investing to reduce total risk.

By the numbers: The true cost of a data breach for financial companies

When it comes to calculating the true cost of a data breach for financial firms, monetary loss is just the beginning.

Consider common threat vectors. While 48% of financial attacks start with malicious actors, human error accounts for 33%. Phishing and compromised credentials take the top spots for initial attack vectors at 16% and 15%, respectively. If attackers are successful, they often have access to millions of transaction and client records — the average cost for breaches of 50 million records or more now tops $300 million.

It’s not all bad news, however. In terms of detecting and containing data breaches, finance organizations are ahead of the curve. Globally, companies take 204 days to identify and 73 days to contain a breach. In the financial industry, breaches are identified in 177 days and contained in 56 days on average.

Where are financial firms investing in cybersecurity?

More than half of organizations will increase their cybersecurity investments this year.

For financial firms, top areas of investment include security AI, automation and incident response (IR). In 2023, 39% of financial organizations reported “extensive use” of security AI and automation, which led to $850,000 in savings compared to the global average cost of a breach. When it comes to IR teams and testing, meanwhile, firms with robust incident response frameworks saved an average of $2 million.

Read the full report

How can the financial industry defend critical data?

The financial industry faces unique challenges when it comes to effective data protection. One of the most prevalent is the need to identify and incorporate global regulations into everyday banking practices. This could include client data privacy obligations under legislation such as CCPA in California and GDPR in Europe, along with fraud reduction efforts governed by FINRA and FinTECH. In addition, new regulations, such as the EU’s Digital Finance Strategy, are emerging to govern growing cryptocurrency markets.

It’s also worth noting that financial firms face steep fines for failing to meet regulatory requirements. Consider that in 2022, the U.S. Securities and Exchange Commission (SEC) fined more than a dozen banks almost $2 billion for cybersecurity shortcomings.

To help combat emerging threats and ensure compliance with evolving legislation, finance firms can benefit from a multi-pronged approach that includes the following elements.

DevSecOps integration

A DevSecOps approach to security makes it possible for firms to integrate protection at application, tool and platform levels for increased control. Here, success depends on both comprehensive integration and regular testing.

Robust data discovery

82% of data breaches include data in cloud environments. By implementing robust data discovery tools, financial organizations can identify where they’re at risk — and what they can do about it.

Security AI and automation deployment

AI and automation can reduce IT staff workloads and streamline data-intensive processes. Deploying AI tools can also lower total security costs and deliver faster data breach identification.

Attacker perspective adoption

Knowledge is power — and knowing what attackers will do before they do it offers a decisive advantage for financial organizations. By using attack surface management tools and adversary simulation techniques, companies can better understand the attack perspective to pinpoint likely avenues of compromise.

When it comes to financial industry cybersecurity, it’s not just about the up-front costs of a data breach. Instead, it’s about creating reliable and repeatable processes capable of addressing current threats, incorporating new regulatory expectations and laying the groundwork for ongoing defense.

Get the full IBM Cost of a Data Breach Report 2023 here.

The post Cost of a data breach 2023: Financial industry impacts appeared first on Security Intelligence.

In the world of cybercrime, malware plays a prominent role. One such malware, Gozi, emerged in 2006 as Gozi CRM, also known as CRM or Papras. Initially offered as a crime-as-a-service (CaaS) platform called 76Service, Gozi quickly gained notoriety for its advanced capabilities. Over time, Gozi underwent a significant transformation and became associated with other malware strains, such as Ursnif (Snifula) and Vawtrak/Neverquest.

Now, in a recent campaign, Gozi has set its sights on banks, financial services and cryptocurrency platforms, recognizing the lucrative nature of these sectors.

The history of Gozi

In 2006, a Russian developer named Nikita Kurmin created the first version of Gozi CRM. While developing the malware, Kurmin borrowed code from another spyware called Ursnif, also known as Snifula, developed by Alexey Ivanov around 2000. As a result, Gozi v1.0 featured a formgrabber module and was often classified as Ursnif/Snifula due to the shared codebase. With these capabilities, Gozi CRM quickly gained attention in the cybercriminal community.

In September 2010, a significant event occurred that would shape the future of Gozi. The source code of a specific Gozi CRM dynamic link library (DLL) version was leaked, exposing its inner workings to the wider world. This leak had far-reaching consequences, as it enabled the creation of new malware strains that leveraged Gozi’s codebase.

In June 2023, Mihai Ionut Paunescu, a Romanian hacker, was sentenced to three years in U.S. federal prison for his role in running a “bulletproof hosting” service called PowerHost[.]ro. This service aided cybercriminals in distributing various malware strains, including Gozi Virus, Zeus Trojan, SpyEye Trojan and BlackEnergy malware.

New Gozi campaigns aim high

Cryptocurrency companies are an attractive target, and the latest iteration of Gozi has brought new elements to its modus operandi. Notably, it is now spreading across Asia, broadening its reach beyond its previous target regions.

A key weapon in Gozi’s arsenal is the use of web injects. These malicious code injections are designed to modify the content of legitimate websites, making them appear genuine to unsuspecting users. By mimicking legitimate login pages or transaction forms, Gozi tricks users into entering their credentials and financial information, unknowingly providing them directly to the attackers.

Figure 1 — Targeted list from Gozi configuration

We covered Gozi’s recent campaign targeted at Italian banks in this report.

Figure 2 — Gozi attacker asking the victim to generate a security code from a mobile application

Additionally, Gozi has targeted various companies associated with cryptocurrency, such as cryptocurrency exchanges, wallets and blockchain service providers, aiming to exploit the lucrative nature of the digital currency industry. These developments mark a significant expansion in the geographical and sectoral scope of Gozi’s cyberattacks.

Asia has been a significant hub for cryptocurrency trading and exchanges. The cryptocurrency exchange platforms based there may be attractive targets due to the potential for financial gain and the high value of digital assets.

Gozi malware can target the login credentials of cryptocurrency exchange platforms. By stealing usernames, passwords and two-factor authentication codes, cybercriminals can gain unauthorized access to user accounts, facilitating unauthorized trading or funds withdrawal.

How to avoid Gozi malware

Here are some recommendations to avoid Gozi malware and protect yourself from similar threats:

• Be wary of email links. Exercise caution when opening email attachments or clicking on links, especially if they come from unknown or suspicious sources. Be particularly vigilant for phishing emails that may attempt to trick you into downloading malware.
• Increase your password security. Create strong and unique passwords for all your online accounts, including cryptocurrency exchanges and wallets. Avoid using easily guessable information and consider using a reliable password manager to securely store and manage your passwords.
• Remain vigilant online. Pay attention to any unusual behavior or unexpected requests when accessing websites, especially financial or cryptocurrency-related platforms. If you encounter unexpected pop-ups, requests for additional personal information, or changes in website appearance, it could be a sign of a web inject attempting to deceive you.
• Stay informed about the latest cybersecurity threats and best practices. Familiarize yourself with common techniques used by cybercriminals, such as phishing scams and social engineering, to avoid falling victim to their tactics.

One of the best tools to detect Gozi malware and protect your organization is IBM Security Trusteer Pinpoint Detect. The tool uses artificial intelligence and machine learning to protect digital channels against account takeover and fraudulent transactions and detect user devices infected with high-risk malware. Learn more here.

Indicators of compromise

C&C

hxxps://gestorbancasrl.com

hxxps://gestorbancosrl.com

hxxps://avas1ta.com/in

hxxps://avas1t.de/in

hxxps://njamma.com

hxxps://itgjmfgdzxcv.com

MD5

471d596dad7ca027a44b21f3c3a2a0d9

The post Gozi strikes again, targeting banks, cryptocurrency and more appeared first on Security Intelligence.

This post was made possible through the research contributions provided by Amir Gendler and Michael  Gal.

In its latest research, IBM Security Lab has observed a noticeable increase in campaigns related to malicious Chrome extensions, targeting  Latin America with a focus on financial institutions, booking sites, and instant messaging. This trend is particularly concerning considering Chrome is one of the most widely used web browsers globally, with a market share of over 80% using the Chromium engine. As such, malicious actors can easily reach a large number of potential victims by distributing their malware through malicious extensions.

IBM Security Lab uncovered a new malware, “Predasus,” which is designed to inject malicious code through a Chrome extension. We’ve observed this mechanism being used to target various websites, including the web version of WhatsApp. Attackers accessed and used the target sites through legitimate means in order to deploy Predasus malware, which provided them the ability to steal users’ financial and other sensitive information.

This blog will provide an analysis of the Predasus malware and its mechanisms and detail how attackers are able to exploit the WhatsApp web to steal victims’ information.

Targeted browser extensions can infect a device through various methods, including social engineering tactics, exploiting vulnerabilities in the browser or operating system, or tricking users into downloading and installing them. Just like other methods of malware distribution, attackers may administer the extension through phishing emails, malvertising, fake software updates, or by exploiting browser or operating system vulnerabilities.

According to IBM Security Lab, Predasus has been observed engaging in a range of malicious activities, including stealing sensitive data such as login credentials, financial information, and personal details.  In this specific attack, Predasus is designed to terminate the active process of the Chrome browser while concurrently modifying the Chrome Browser Ink. This action occurs each time the browser initializes, facilitating the loading of the malevolent “extension_chrome” from a specific directory.

The attacker can then steal sensitive information, modify browser behavior, or perform phishing attacks. This attack vector is different from past methods in several ways. Firstly, it uses a sophisticated technique to terminate the active process of the Chrome browser, which is likely to evade detection by traditional antivirus or security software. Secondly, the attacker modifies the Chrome Browser Ink, which could allow the installation of the malicious extension without the user’s knowledge or consent.

Finally, because the attack appears to be specifically targeted, it could indicate the attacker may be seeking to compromise a specific set of users or organizations. Each of these steps is explained in more detail in the following section.

More from Trusteer

The operation of the attack

Exploiting browser extensions is just another way attackers can latch onto a user’s online financial transactions. They change methods from process injection or MITM to malicious Chrome extensions, which can steal users’ bank credentials and other personal information.

The scenario typically starts with a user opening an email attachment, which could be a PDF, Word, or Excel file. Unbeknownst to the user, the attachment contains malware that infects their machine, and, once downloaded, the malware is automatically deployed. Once the machine is infected, the malware connects to a first command and control (C&C) server and downloads several files that are written to a folder named “extension_chrome” under %APPDATA%. It terminates any process related to Google Chrome and creates malicious .LNK files in several locations, replacing legitimate ones.

Predasus uses the following commands in order to replace the old Chrome browser with a new one with the malicious extension:

• TASKKILL  /IM chrome.exe /F
• C:\Program Files\Google\Chrome\Application\chrome.exe”  –load-extension=”C:\Users\user\AppData\Roaming\extension_chrome
• “C:\Program Files\Google\Chrome\Application\chrome.exe” –no-startup-window /prefetch:5

It then executes one of these .LNK files to launch Google Chrome while automatically loading malicious .JS files. The malware also connects to a second C&C server (vialikedin[.]org) and downloads another JS file (px.js) that detects Adblockers. The malicious extension is constantly loaded onto the browser.

The malicious Chrome extension is designed to wait until the user accesses a targeted website – the targets of which are viewable in the javascript. At this point, it will steal their login credentials and other sensitive information, such as account numbers, PINs, and security questions. This information is then forwarded to a C&C server managed by the attackers.

Because the malicious Chrome extension operates silently in the background, many users may not even be aware their information has been stolen until stolen information is used to initiate unauthorized transactions or transfer funds.

In summary, the attack involves the following steps:

Attackers leverage WhatsApp Web’s popularity for malicious extension attacks

Our team has observed this mechanism being used specifically to target the web version of WhatsApp. It is worth noting that the emergence of these malicious extensions does not come as a surprise, as WhatsApp’s popularity has made it an attractive target for cyber criminals seeking to exploit its user base for nefarious purposes.

With WhatsApp’s ease of use, cross-platform compatibility, and ability to connect people across borders, it has become a staple for many individuals and businesses. However, with its popularity, comes a risk — it has become a prime target for cyber criminals looking to steal personal data and money.

Recently, we have seen a new malicious extension targeting WhatsApp’s web application.

Figure 1 – Malware targeting Whatsapp and injecting external malicious script

But why is this the case?

Firstly, WhatsApp’s web application is easy to access and use. With just a QR code scan, users can easily connect their phones to their computers and start messaging. This convenience, however, also makes a malicious actor’s job easier.

Secondly, WhatsApp is particularly popular in countries such as India, Brazil, and Mexico, with many people relying on it for daily communication,  giving attackers a wider pool of potential targets.

Behind the scenes of the malicious extension

Upon successful changes of the Chrome browser with the new malicious extension, we detected a series of anomalous activities executed by the malicious extension.

Figure 2 – manifest.json file of the malicious extension

manifest.json file contains various settings and configurations for the extension.

From the configuration, we can see the name of the extension is misspelled: “Secuirty Update”.

The extension has the following permission:

• “alarms”: Allows the extension to schedule tasks or reminders at specific times.
• “background”: Allows the extension to run in the background, even when the extension’s popup window is closed.
• “cookies”: Allows the extension to access and modify cookies for any website the user visits.
• “idle”: Allows the extension to detect when the user’s system is idle (i.e., not being actively used).
• “system.display”: Allows the extension to detect and adjust display settings on the user’s system.
• “tabs”: Allows the extension to access and modify browser tabs and their content.
• “storage”: Allows the extension to store and retrieve data from the browser’s local storage.
• “webRequest”: Allows the extension to monitor, block, or modify network requests made by the browser.
• “webRequestBlocking”: Allows the extension to block network requests made by the browser.
• “browsingData”: Allows the extension to clear the user’s browsing data (such as history and cache) for specific websites.
• “http://*/*”: Allows the extension to access any HTTP website.
• “https://*/*”: Allows the extension to access any HTTPS website.

Some of these permissions pose a risk, as they allow the extension to access or modify sensitive user data. As such, it’s important to be careful when granting permissions to browser extensions and to only install extensions from trusted sources.

Inside the “manifest.json” there’s “content_scripts” which specifies the extension should inject “main.js” into all frames of all URLs.

Figure 3 – main.js inject external JavaScript

The new script’s source is set to “hxxps://techcosupportservice.com/ext/ok.js”, which means when the script is executed, it will load and execute the JavaScript code from that URL.

This technique is commonly used to load external JavaScript files into a web page dynamically. By doing so, the web page can load additional functionality or libraries on-demand, rather than having to include all the JavaScript code in the page’s HTML source directly.

Figure 4 – external script ok.js

The script called “ok.js” contains configuration information and is designed to check whether the victim is visiting a website that is included in a targeted list.

Upon the victim navigating to the web.whatsapp.com website, a script called “main.js” is injected into the user’s browser. This script is malicious in nature and could be used for various nefarious purposes, such as monitoring the users’ browsing behavior or stealing sensitive information entered by the user on the webpage.

Figure 5 – WhatsApp malicious injection

The attacker loads a scam website from the malicious injection and presents the victim with a message requesting they need to renew their subscription to continue using WhatsApp web. This fraudulent message is designed to trick the victim into providing sensitive information, such as their payment details or login credentials.

Figure 6 – Fake payment request for WhatsApp

After the victim has entered their personal information, the attacker then prompts the victim to enter a One-Time Password (OTP) via SMS. The victim may believe this is a legitimate step in the authentication process, but the attacker is trying to steal the victim’s OTP. Additionally, now the attacker can establish an unauthorized session with the bank, which they could potentially use to transfer money or carry out other fraudulent activities.

Figure 7 – Fake OTP page

Figure 8 – Transaction confirmed

Once the victim has entered their OTP, the attacker’s website or application sends all of the victim’s personal information, including the credit card number and OTP, to the attacker’s C&C server. The attacker can then use this information for fraudulent purposes, such as making unauthorized purchases or identity theft.

Figure 9 – C&C uAdmin panel

Darknet selling uAdmin panel

There has been a noticeable increase in the demand for C&C panels on the darknet, with a particular emphasis on the highly versatile uAdmin panel.

The management panel of this tool can be customized to collect user login credentials, credit card information, and cookies. Moreover, it can redirect traffic and facilitate various other malicious activities.

Figure 10 – uAdmin capabilities taken from Darknet

Once acquired by a cyber criminal, the uAdmin Panel can become a tool for carrying out various attacks. The customization options available through uAdmin Panel can enable the attacker to carry out different types of malicious activities, such as:

• Stealing User Data: uAdmin Panel can be used to steal user data, including login credentials, personal information, and financial data. This information can then be used for a range of malicious purposes, such as identity theft or financial fraud.
• Redirection of Attacks: uAdmin Panel can also be configured to redirect attacks to different servers or websites. This can be used to evade detection or to target specific victims.
• Web-Injects: uAdmin Panel can be used to configure JavaScript Web injections in order to steal victim-sensitive information.
• Harvesting Cookies: uAdmin Panel can also be used to harvest cookies, which can be used to gain unauthorized access to user accounts or to track user activity.

Figure 11 – Darknet selling uAdmin Panel & Webinjects

The screenshot displays a list of financial institutions, and it appears to be associated with a “uadmin panel.” The prices listed indicate that some of these financial institutions are selling either just the management panel or the panel along with webinject kits.

Targeted list

IOCs

MD5:
50e9958bb2a5b6ae6ed8da1b1d97a5bb
d2183968f9080b37babfeba3ccf10df2

Domains

hxxps://techcosupportservice.com

hxxps://techcosupportservice.com/panel_m/conn.php

hxxp://62.204.41.88/lend/rc.exe

hxxps://contestofskillonline.com/uadmin/gate.php

hxxps://techcosupportservice.com/ext/vvv1.js

hxxps://techcosupportservice.com/ext/ok.js

hxxps://techcosupportservice.com/ext/main.js

hxxps://techcosupportservice.com/ext/background.js

hxxps://techcosupportservice.com/ext/manifest.json

hxxps://techcosupportservice.com/jquery.js

hxxp:// vialikedin.org

How to stay safe from malicious Chrome extensions

To protect against these malicious extensions, it’s important to be vigilant when installing any new browser extensions. Users should only download extensions from trusted sources and carefully review the permissions requested by the extension before installation. Additionally, they should use two-factor authentication and regularly update their browser and extensions.

The rise of malicious Chrome extensions is a worrying trend that highlights the need for users to be vigilant when browsing the web.

It is suspected this malware campaign may potentially spread to the North American and European regions.

To learn how to authenticate customers, detect fraud and protect against malicious users across all channels, explore IBM Security Trusteer solutions.

The post The rise of malicious Chrome extensions targeting Latin America appeared first on Security Intelligence.

Fraudsters are constantly finding new ways to exploit vulnerabilities in the banking system, and one of the latest tactics involves stealing credit card information via mobile banking apps.

This type of attack has been seen in different variations in Spain and North America and was reported for the first time at the beginning of 2023. As fraudsters use stolen credentials to commit e-commerce fraud, here’s what banks and customers must keep in mind to stay safe.

The modus operandi

Step 1: Stealing credentials

Fraudsters start by stealing the login credentials and the phone number of banking customers. They typically accomplish this through phishing or smishing.

Step 2: Enrolling a phone

Equipped with the stolen credentials and the victim’s phone number, fraudsters enroll their own phone to receive future one-time passwords (OTPs) and push notifications. This is done by logging into the mobile banking app and following the enrollment process. To authenticate this action, they impersonate a banking employee and call the victim under a pretext to receive the OTP.

Step 3: Opening a neobank account

Next, fraudsters open an account with a neobank, where they automatically receive a prepaid card. This can be done quickly and easily because of lax controls in identity verification and background checks.

Step 4: Charging the prepaid card

Fraudsters then charge the prepaid card with a simple credit card transaction. They can access the victim’s credit card details via the banking app and generate a dynamic CVV. To approve this transaction, they receive a push notification to the phone that they enrolled in earlier.

Case study: Spanish retail bank

In February 2023, a Spanish retail bank reported that approximately 20 of their accounts had been compromised using this type of attack.

The bank turned to IBM Security Trusteer for help. IBM Security Trusteer’s Pinpoint Detect can monitor for risky actions, such as changing passwords and phone numbers or enrolling a new device by analyzing the user journey (URL data). It can integrate this information as part of its transactional risk assessment on the online channel.

However, the fraudsters gained access to the accounts via the mobile banking application, where Pinpoint Detect (PPD) does not collect URL data. As such, PPD does not have visibility into the actions performed in the account, such as generating a dynamic CVV or other high-risk activities.

For this type of attack, IBM Security Trusteer requires visibility into the user journey and risk assessment at the right time to effectively and efficiently block the fraud.

To address this challenge, IBM presented two potential solutions to the customer.

The first solution involves the customer calling the Pinpoint Detect application programming interface for standard transactional assessment whenever the fraudster generates the dynamic CVV and sending extra information about the action to IBM as a custom data field. Custom data can be shared by any customer and integrated into the risk assessment.

The second solution implements a new policy assessment point that could be called whenever a user generates the dynamic CVV. This solution provides visibility into high-risk actions and granularity for risk assessment. It also allows high-risk actions to be flagged outside of transactional monitoring.

After evaluating the options, the customer and IBM Security Trusteer agreed to implement the second solution, which provided faster and more accurate fraud coverage.

In the following month, the IBM deployment team created the new invocation point, or “activity,” and integrated it with the risk assessment infrastructure. The customer then tested the activity, and the IBM Security Trusteer Fraud Analytics team tuned and monitored the relevant rules and deployed the policy to production.

Within a month of deployment, the customer confirmed over 45 accounts had been compromised. This demonstrates the effectiveness of the IBM Security Trusteer solution in detecting and preventing account takeover fraud through the mobile SDK.

Taking steps to combat fraud

As banks have developed effective transactional monitoring strategies, fraudsters have evolved their tactics to perform e-commerce fraud instead of traditional transactional fraud. More and more banks allow their customers to fully manage credit cards via a mobile banking app, putting them at risk of e-commerce fraud. By working with IBM Security Trusteer and implementing additional technologies, banks can stay ahead of the curve and better protect themselves and their customers from fraud.

The post How fraudsters redefine mobile banking account takeovers appeared first on Security Intelligence.